Yes this would help a lot, especially for videos though, a lot of times, I just give up and move on, or put up with finding the text in the middle and reading it with no formatting.

That shit doesn't happen to me because I run requestpolicy. When I load up site X.Y.Z and it says "Here load content from a.b.c" It....doesn't load unless I manually approve it. For all sites all the time, and google....almost NEVER gets the approval unless absolutely required.

Often I think it comes less down to the FDA and more to the interpretation. If you are a hospital using a device that comes with a certification from a vendor saying that you have to buy their drives to maintain certification, a few hundred bucks extra isn't worth the risk of it not being a bluff.

When I was working for a hospital we had a box running an ancient version of rhel (AS 2.1 if I remember) that the vendor swore could not be upgraded or security patched because of fda certs. What did we do? We made an exception.

Which is all the more reason why system designers really should consider themselves as having a duty to care for them. The vast majority of users are not experts and any risks they expose themselves to in using the product really are things they can't be expected to understand. So products intended for non-professional markets especially; should really be designs to not expose inexpert users to risks as much as possible.

> Which means you end up with, at least, a tiny LCD screen to show the pairing code. Which means
> you need enough logic to run the LCD screen and the pairing stuff.

oooh I have been thinking about this.... I think it can be done even easier and cheaper.

Wireless keyboards generally require a wireless dongle. Put a usb port on the kb, used for emergency power obviously.... but... easy pairing. Just plug the dongle into the device, and press a button, they can do a key negotiation over their local USB connection. No LCD needed, maybe.... an LED and a button.

That should put an easy end to easy sniffing. Course if someone is coming into your house and plugging shit into the wall, maybe they can just replace your whole keyboard too.... fake the dongle and keyboard into each pairing with his device and MiTM you? or wholesale replace yours with his lookalike.... but, its certainly not casual sniffing at that point.

In the future keyboard designers should make the protocol more configurable so that on casual observation it is not so easy to determine what packets are data

Thats a very common misconception, but the fact is that is pretty exactly what they should NOT do.

Specifically that is, they should not even attempt to design their own method of securing the data. They should use fairly standard, well tested, modules produced by professional cryptographers. Full stop. These are solved problems, and there are several very well researched and well designed techniques for solving these issues.

There is always room for more such techniques but, to think that some engineer working on a keyboard is going to design one that is even as good as what we have as just....a submodule of his project is just not realistic.

Choose a solution for authentication/key negotiation....choose a cipher. Go back to designing the keyboard itself. That really is the best part.... since its a solved problem.... it really isn't a huge level of effort to fix correctly.

Plus its a keyboard...a "pairing" could be as simple as flipping a switch into pairing mode, then typing some text that shows on the screen of the device pairing with it. Its not like its some headset with only 2 buttons.

DoD are not the only people who require FIPS 140-2. I have worked at shops with various mixes of FERPA, HPAA, and PCI requirements for various parts of their operation, and I have run into it a couple of times; though I can't tell you (because I don't know) whether any of them have been strictly due to a regulatory requirement or a place where local policy simply adopted the recommendations from it.

In short, if such a device existed, it might actually end up on several companies prefered purchasing lists for their employees, or even cause other competing products to get disqualified as just the existence of one could call the others into question.

The thing is, the cipher doesn't do the job alone, once you have a good cipher, you then need good key generation/negotiation, which pretty much requires some sort of authenticated pairing step which requires user interaction to complete.

Still pretty reasonable but, everyone wants "plug and play" and thats hard to reconcile with "safer play"

I would say this is pretty close to how I look at it now. I got a cheap wireless keyboard sure....but anyone sniffing the traffic is going to be bored to tears as I don't ever type anything the least bit confidential on it. Best you are getting is a bunch of youtube URLs and a whole bunch of wwwwwwwwwwwwwaaaaaaaaaaaaaaaasssssssssssssssddddddddddddddddddddddddfff

This is why I hate large swaths of consumer products.

If the keyboard is encrypting keystrokes and sending them to the system....and a third party device sitting in the corner with no configuration involving dumping and loading keys....then the data is NOT encrypted.

If you use the same static key, or one of a few easily derivable keys, I don't care how solid the encryption alcogrythem you use is.... I do not consider it encrypted, because the use case took "strong encryption" and turned it into "weak obfuscation".

So unless there is some esoteric trick they are using to exploit the system and get their hands on a key that should otherwise be secure.... then its a disservice to the public to even call it encryption, because unless that is the case and they were genuinely compromised from a use case that should have otherwise been secure.... then all they did was use a fancy obfuscator.

Perhaps he is confused by the fact that many small developers, especially of game mods, distribute directly from github, and indeed, github is not adding anything to those downloads.

A lot of people don't seem to realize that git is a thing quite aside from github

To arms netizens!
form your subject lines
type on
type on
until their impure posts are drowned in our flame

I have worked with some people who would consider this :)

Actually a while back I found someone was passing around instructions on how to setup some software that needed a random key for a symmetric cipher. It used a 256 bit block cipher so it needed a 256 bit key.

The instructions being passed around where clearly cut and pasted from a web site (they might have even had the url) but they remembered that we had key policies for other things and so they changed the dd command to make a 1024 bit key....because we use at least 1024 bit keys by policy right?

A little bit of knowledge can be such an amusing thing.

Lol its like some people never played Uplink. Even the game had the log deleter and the log modifier, which was used in the frame job contracts. Its almost kind of a no brainer. and hardly a new concept, what is a botnet really but a way to look like hundreds of other people instead of yourself?

> That seems like a huge tradeoff in usability for not much security benefit, IMHO, particularly if the box is running
> services that are far more likely to be probed than ssh. Nor do I much care for the notion of having to rely on Tor
> if I need to manage a critical system.

The thing is to a tor service, a "port" is just an identifier that allows multiple services to have the same name. There is no underlying "address" that you can use to further attack the host. It is a lot like being behind a very restrictive firewall where you have only 1 port exposed.

It also means you can't be found in random sweeps. In order to connect to a tor service, you need its name to look it up and connect to it with, you can't just scan random addresses/names looking for ssh servers.

Some people think they are clever moving ssh to another port, but port scanners have already found them on ports like 2222 (someone thought that was clever I guess).