Comment by Osmium | Hacker News Reader

Comment by Osmium | Hacker News Reader

I am not a cryptographer but:

"We’re talking even 6 characters or longer, some upper and lower case, and maybe toss in a digit and special character."

6 characters? for 256-bit AES? That seems woefully inadequate. Imagine, say, 72 possible characters (52 a-Z, 10 digits, 10 special characters). This gives a password length for "full" 256-bit security as at least 128*log(2)/log(72) = 42 characters. If I'm wrong about this, please someone correct me! Either way, "6 or longer" seems far too short. Have I missed something here?

As for this particular person's predicament:

I, too, have been in this situation. I couldn't recite my password to someone; I can only touch-type it. It's a bizarre situation to be in and I've very nearly forgotten it myself in the past. I find it's easier to stop trying in case you accidentally "overwrite" your muscle memory and just go back to it later. Most recently, it happened due to my keyboard being detected incorrectly on boot and it almost drove me mad until I realised it wasn't my own error but the keyboard. I suspect if I hadn't have realised I might've been in the same situation as the OP.

In any case, Apple's implementation of FileVault is closed-source (to my knowledge) so it should always be assumed that someone who wants access to your data badly enough can get at it. I don't think it's worth being this paranoid about (e.g. the OP storing passwords as flat-files in a 256-bit AES encrypted disk image instead of just using the system keychain which manages all that for you).

Edit: I did find this interesting:

"The reason it’s so slow is because your AES256-encrypted DMG uses 250,000 rounds of PBKDF2-HMAC-SHA-1 to generate the encryption key. The ludicrous round count makes it extremely computationally expensive, slowing down the HMAC-SHA1 process by a factor of 250,000."

It doesn't seem so ludicrous if it works. Does anyone know if this is standard behaviour for encrypted DMGs?

Usually encryption schemes use a key derivation function like PBKDF2 to "stretch" a user's password to generate 128/256 bits for the symmetric cipher. In this case, the attacker cannot bruteforce aes directly because the generated key is "randomly" selected from the impossibly large 256 bit key space. The attacker now must feed his password guesses through the key derivation function, which hopefully will slow the attacker enough that even the smaller space of memorable user passwords is too large to bruteforce.

It doesn't seem so ludicrous if it works.

No key derivation function will protect from very short passwords, which is effectively the scenario here as the author is helping the attacker narrow number of possible passwords to 22472.

As a side note, my interpretation is that the author's password is longer than 6 characters, and he cannot remember 6 of the characters.

> I, too, have been in this situation. I couldn't recite my password to someone; I can only touch-type it.

Reminded me of this; making password type authentication using a game. The person can authenticate, but don't have explicit memory of the password that they can vocalise or write down.

http://bojinov.org/professional/usenixsec2012-rubberhose.pdf

It's a great system. And easier than you'd think. It really takes only two days of logging-in to learn a random password; even a long one. After all, how often do you think about your password when you type it in? I imagine you only consciously think about it the first dozen times you type it, and after that it becomes muscle memory, regardless of whether it's a random password or a memorable one. If that's the case, why not just use a random password to start with?

Still, it's never good to encrypt everything with the same password otherwise you end up in the same mess as the OP. What's the point of a backup if it shares a common point of failure?

I wasn't able to find a proof of concept of the password system, is there one available publicly?

Keepass

That is standard behavior for encrypted DMG's. It's standard behavior for almost all crypto to use a key derivation function when using a user supplied password as the "key".

Noticed the PBKDF2 in there, that is a key derivation function, given a password it will then spit out a 256 bit key to actually use for the encryption/decryption of the content.

42 charcters with 72 possible characters makes out: 748081489394439783757309593473860564114284655771100962350023529282082095306929075084411791515994615131061055794446336 combinations... that's 7.48... x 10^116 and with 6 characters it's 1.06... x 10^56

Both are ridiculous for brute force, aren't they?

the correct calculations are 72^42 (1.0e78) and 72^6 (1.4e11)

Right, my bad. The other way around - M^n, not n^M. Combinations vs permutations, depends what you want.

We're not even talking about 6 characters - the article says they reduced the search space to 22472 combinations, which is barely 3 characters. Yes, 3 char passwords are easy to crack, what else is new?..

Reply on news.ycombinator.com