Item — HN Reader

NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit. Also, Rijndael is the one cipher that intel have offloaded on their chips and even called it AES-NI vs. offloading several ciphers.

I agree with some comments here that size matters. It is trivial to put a series of characters in between 2 to {n} words you can easily remember.

____This____Is____Number____42!____ and I would remember it is 4 _'s around each word because there are 4 words/numbers.

More sensitive content should equate to more words; and therefore, more of the buffer characters.

You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected.

For those concerned about password managers and keyloggers, don't put your actual password in them. Leave off something, somewhere in your password. Maybe the start of your pw actually contains buffer characters that you know to type or paste.

A majority of folks won't be bothered to do any of this. I am just sayin', it's super easy once you train yourself.

6 comments

This is a weird comment.

First and most importantly, you have the chronology backwards --- obviously, Intel implemented AES-NI after NIST chose AES. If NIST had chosen Serpent, AES-NI would implement Serpent. That's the point of encryption standards.

Second, Serpent had a higher security margin, but was slower, and more complicated; among other issues, Serpent has a higher hardware footprint. None of the AES finalists have been meaningfully weakened since AES was selected.

There are obviously sketchy NIST crypto standards, and at least one very bad one. AES isn't either of those kinds of things.

> First and most importantly, you have the chronology backwards

No, you and I are saying the same thing. Perhaps I worded it poorly? My point is they are fixating on a specific cipher they believe everyone should and will use. As it turns out, most are because Intel backed their choice and gave people incentive to utilize it.

Again, that would be the point of an encryption standard.

If fixating on a specific cipher is considered to be a standard, then let's deprecate it. I believe that was done in error. The standard should be around how each cipher is implemented in a secure manor, not limiting options to one cipher.

By diversifying options, brute force attempts get exponentially more expensive. It would be easy enough to list in CPU capabilities which instructions are supported.

None of this makes sense, sorry.

I think what LinuxBender may be trying to say is that if everyone standardizes down to a single cipher, that's not a good thing when that one cipher is shown to be a poor choice. It might be nicer if people have a few choices, so we have freedom to disable some of them when one becomes a poor choice.

Ex: when TLS clients and servers commonly supported 3DES, RC4, and AES, it wasn't universally painful to disable 3DES and RC4 (although if you support(ed) embedded clients without AES support, it's still painful). I think ChaCha looks to be a second good option that's gaining support.

I like ChaCha. I like AES. Systems should choose one or the other. Part of the point of ChaCha is to exploit the capabilities of general-purpose processors to get fast encryption without special-purpose hardware acceleration.

What people should not do is cascade ciphers, or, even worse, build systems that allow for cipher negotiation. Every system that negotiates has been a disaster.

Algorithm agility was once considered best practice and all but mandatory.

20+ years of issues with SSL and SSH, both in the standards and implementations, has taught us that the costs of supporting algorithm agility is much more than the gains. Borderline intolerable, in fact. Moreover, our two-decade track record of cryptanalysis and predictions of future breakthroughs has been very good.

We're much better able to predict the costs+benefits of a particular cryptographic primitive than we are of the protocols and software we build. If a cryptographic primitive is assessed as good enough, it's no longer considered desirable or even reasonable to hedge that assessment and permit substitution of the primitive during the lifetime of the protocol. The resultant complexity is much more likely to be the source of future problems than the primitive.

Sorry.

> NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit.

Rijndael won because cryptography is first and foremost a discipline that makes tradeoffs between usability and security. A security measure is not helpful if no one uses it, either because it's a pain in the ass to configure or because it increases your own costs to implement and use. Serpent is technically more secure because it uses 32 rounds of encryption (among other things) while Rijndael uses 10, 12 or 14 (depending on key size). But they're both substitution-permutation networks, and Rijndael is secure enough while offering a significant speed increase. There hasn't been a meaningful cryptanalysis on Rijndael since it was published.

> You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected.

I don't really follow. If a keylogger has compromised your machine, you're already approaching worst-case scenario territory. More importantly, of course a keylogger can capture how many characters you select. Even if they didn't, they can just capture exactly what's in the browser form field before it's sent in the login request.

> For those concerned about password managers: Leave off something, somewhere in your password.

I like the idea. So what you suggest is to manually type, say, "7&>>", before or after every password entered by the password manager? Or to copy-paste the "7&>>" from somewhere.

A password manager is essential for good security (and I use one) but I'm concerned that it can be devastating point of failure. It can be worse for highly-organized people who keep absolutely everything in there.

It's a single, up-to-date database in a nice standardized format with known filenames and clearly labeled data that lends itself to automated malware that can seek it out when your password manager is open/mounted/decrypted.

As you said, a majority of folks won't be bothered, but a good extra step for someone highly security conscious.

If malware has compromised your device, there is nothing you can meaningfully do to improve the security that is already offered by a password manager. This scenario is right up there with physical access to the machine - you're already screwed.

To comment on this specific example - if you add the same set of characters to every item in a password manager, an attacker can deduce that it's a common obfuscation method.

Why even bother with these weird rules? just use a password manager, generate a secure (> 128bit entrop) password, and be done with it. Also, keepass has something like your keylogger foiling method, called "2 channel obfuscation".

Use whatever option you are comfortable with. I know people that can't bother to use more than 1 password everywhere and certainly can't use more than 6 characters.

Do you actually believe that keylogger programmers have never heard of GetClipboardData()?

> You can even use this to defeat keyloggers.

If you have a keylogger, your first order of business should be to clean out the keylogger.

The very presence of a keylogger makes the machine insecure for entry of any passwords, no matter how you do the entry.

> Keyloggers will capture cntr-v but they won't capture how many characters you selected.

Why would you think a keylogger could not recognize the ctrl-v and then ask for the contents of the clipboard itself so it can log what was pasted?

I've never run across one that does, but that is certainly a risk too.