I lost my OpenBSD full-disk encryption password

[0xmohit]

Enlightenment always takes a while :)

  I later found a nice article documenting the entire system. It
  also includes references to JohnTheRipper having a module for
  this. Well, this was more fun.

--

Wonder how many times are the same items posted: https://news.ycombinator.com/from?site=filippo.io

[f-]

Off-topic, but my personal work sometimes ends up on the front page, and I'm always amazed how much reposting there is on HN - probably more than on Reddit and similar sites. Say, here's my stuff:

https://news.ycombinator.com/from?site=lcamtuf.blogspot.com

https://news.ycombinator.com/from?site=coredump.cx

The process seems quite random; sometimes, the same link is submitted four times and lingers at score 1, and then some random dude's fifth attempt goes to #1. May be an interesting thing to graph (and get a #1 story on HN out of =).

[morecoffee]

Doing something for the sake of learning doesn't ever feel like wasted time. When I was first getting into networking I wanted to connect two computers directly without have a router or a switch between them. I carefully researched how to cut and crimp an ethernet cable into be a crossover cable, and successfully connected the two.

Feeling proud of myself, I scrolled farther down the page that described it only to read that most NICs will automatically do it for you and you don't need to make crossover cables any more. I'm still glad I took the time.

[jl6]

Well there's a reason they say 70% of programming is done in the library...

[0xmohit]

BTW, I wonder which category of users need to supply passwords. Until now it seemed that captchas were inevitable.

[camtarn]

The previous article, about a lost password for a NAS, is hilarious and well worth a read as well:

https://blog.filippo.io/so-i-lost-the-password-of-my-nas/

[bcook]

He's lost two VITAL passwords? This seems like a false premise then (which is fine, but the fictional premise seems unneeded and disrespectful).

[moyix]

Quick question for the more cryptographically inclined: apparently after decryption the code does an HMAC validation:

    /* Check that the key decrypted properly. */
    sr_crypto_calculate_check_hmac_sha1(sd->mds.mdd_crypto.scr_maskkey,

Does this mean it's using Mac-Then-Encrypt? And if so, is it likely doomed [1]?

[1] https://moxie.org/blog/the-cryptographic-doom-principle/

[FiloSottile]

That is a good principle, but the context here is different.

FDE doesn't have space for and can't afford (because of the random read patterns) authentication tags, so it uses modes like AES-XTS instead.

What that HMAC does is just confirming that the passphrase is the right one. Think of it as a checksum, not as authentication.

[JoachimSchipper]

OpenBSD uses XTS, which is what you should do for disk crypto (only). For more background, see http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/.

[dfox]

It checks the key against some kind of authenticator in the superblock, which is what one would expect from any kind of offline crypto.

The real problem is that FDE in the usual sense is (from the strict cryptological sense) very weak encryption, because it cannot afford to expand the encrypted data and has to allow random access (so no random IVs, no authentication tags...). It's relatively trivial to design FDE scheme that is fully secure, but it has 2x block io-op amplification for both read and write, which means unusable performance (certainly on rotating disks, probably even on SSD). Various wide-block encryption modes (AES-XTS etc.) attempt to mitigate attack vectors caused by this, but are secure only under certain FDE-specific attack models.

[Edit: formatting and last sentence]

[Dylan16807]

It's not doing very much before validating, which would reduce the risk. But more importantly it doesn't have any information to leak. The whole block of data is public.

[Drdrdrq]

If he wanted to know the value of the salt for his disk, wouldn't it be easier if he just modified the sources so it would be printed it out?

[FiloSottile]

I... Actually didn't think of that, to be honest. But it would have involved rebuilding the OpenBSD kernel, so it probably wasn't easier. Also, the tool wouldn't have been reusable. But yeah, good thinking.

[cperciva]

the rounds number 0x2000

Does anyone know if this is the default? If I'm understanding this correctly, it's around 10 ms of key derivation time; on FreeBSD we default to 2 s, which should make cracking disk encryption 200x more expensive.

[FiloSottile]

That's the default. Easy to override--and I did after this--but admittedly ew. Maybe we should email the OpenBSD list?

[zaroth]

Well its SHA-1 after all, so you're up against a GTX 980 GPU pushing about 4GH/s. (so I think 0x2000 is about 2ns in that case)

[_urga]

What key derivation time would you advise targeting for a server with 20-100 disks, where each disk has a unique KDF salt?

How many times stronger would scrypt targeting 2s be compared to PBKDF2 targeting 2s? If using scrypt for many disks would it then be safe to target 10-100ms so as not to impact on reboot times?

[zakk]

While reading I had the feeling that the author was reverse-engineering open source software...

[notaplumber]

In essence, that's precisely what he's doing. The exact on-disk metadata layout may not be documented anywhere, so he pieced it together using the structure definitions in the source code.

For those reading along at home, what is being done here is a run-of-the-mill bruteforce, this article could be about any FDE implementation.

So now the real question .. what was the password? :-)

[clarry]

I've had to do a similar thing with OpenBSD's softraid. In an unfortunate incident with a problematic hard drive that mostly works but sometimes gets stuck reading / clicking for a while. That while once took too long and resulted in a timeout, softraid flagged the disk as being offline. I started a rebuild, but later on got a bit paranoid and ran smart checks on both of the mirrored disks. Well, the other disk didn't respond well to smart and got itself flagged offline. Now my softraid mirror was down with one disk halfway through a rebuild and the other disk just fine but flagged bad.

Recovery was a matter of finding the right metadata bit on the disk that tells softraid about the disk's status. That was the hardest part (and not that hard, but it certainly felt like reverse-engineering the system). I flipped a byte with dd and my brought the raid up again.

[z3t4]

When deciding to encrypt, lets say a backup, you need to ask yourself, is the data better lost then in the hands of the wrong people.

[pacaro]

Another way to look at this, is to ask yourself what your threat model is. For example, if your primary concern is losing your laptop while traveling, then writing down your pass phrase and keeping it with other important paperwork (tax returns, property deeds, birth certificate etc) in a home safe or a bank safety deposit box seems totally reasonable. If you have concerns about Protecting your data from law enforcement, then the pass phrase needs to be stored out of the reach of a warrant - a trickier proposition.

[userbinator]

Indeed. Good data encryption is also far stronger than the things like locks that people make analogies to in the real world. There is essentially no locksmith. If you lose the key, your data is gone forever. As illustrated by this article, if you have weak passphrases there are ways around it, so I suppose it is possible to "tune" the strength of your encryption that way.

[SwellJoe]

I briefly went all-in on security, cryptocurrency, tor, etc., and had a locked down desktop machine encrypted with LUKS. Then, I moved, and it took me a few weeks to get the computer set back up. In that time, I'd forgotten my passphrase. So, I have a desktop machine containing (at least) a couple hundred bucks worth of cryptocurrencies that I can't open. I still think I remember the passphrase I used, but it doesn't work, so I'm obviously missing a word or a punctuation addition (I used the CorrectHorseBatteryStaple method of making a memorable passphrase in this case).

I've been known to do dumb things, and going down the rabbit hole of cryptocurrencies and how to securely use said currencies was one of them. These days I put everything of importance into Google drive, Dropbox, and/or git (not github...a privately hosted git that I access via ssh and runs on a VM on hardware I own in a data center I trust). If it is sensitive, it is encrypted with a passphrase I've been using for a couple decades, and so it unlikely to be forgotten. A high capability attacker could thwart my protections, I'm sure, but I don't have any reason to believe a high capability attacker has any interest in me.

And, I don't hold much cryptocurrency, and what I do hold is at Coinbase, just sitting there on the off chance Bitcoin really does take over the world and a small amount turns into a big value.

[wglb]

but I don't have any reason to believe a high capability attacker has any interest in me

Note what George Smiley is known to reply: "There was every reason":

Peter Guillam: Well, at the time there was no reason to suppose the phone was tapped... George Smiley: There was every reason.

(from http://www.imdb.com/character/ch0030043/quotes as well as the book)

[witty_username]

Shouldn't bruteforce work?

[_ph_]

So, for the layman, does this mean, the encryption can be practically cracked or not?

[ww520]

He probably just misremembered a few characters of his password, like mypass1234, mypass1235, mypass4321, etc. It would be time consuming for human to try all the 4 digits but trivial for computer to try out the 9999 enumeration.

The complication is finding out the algorithm used and the parameters applied to the algorithm. Once figured out, he wrote the small program to brute force the small enumeration.

This is a very good illustration of the need for long and non-trivial password; otherwise, it can be easily guessed.

[Tuna-Fish]

If you almost know the right passphrase, it can be. If you don't, and the passphrase is good, it can't.

[lima]

No. He just made a brute forcing tool.

[ams6110]

Hm, if it were me and I had just set up the new system and then promptly forgot the password, I'd just reinstall.

[EGreg]

Why not have your passwords be hashes of passphrases?

[rwallace]

Because that would add little entropy at the cost of much inconvenience, which is the opposite of what you want.

[AWildDHHAppears]

That's why I keep them written down in my safe!

[yuja_wang]

I do that too! I have the same "suffix" that's on all of them that I leave off the written version for a tiny bit of extra security. It's just a few characters that I've been using consistently for years on written-down passwords.

[imaginenore]

That's why you always

1) store passwords in the password manager, even the ones you think aren't important.

2) backup your data

[koolba]

> 1) store passwords in the password manager, even the ones you think aren't important.

Losing the password that unlocks full disk encryption (FDE) is like losing the password that unlocks your password manager. At some point you have to have something stored only in your mind.

Now sure you could have your FDE password stored in a password manager as well but that's probably not a good idea. Also, compared to just about everything else saved in a password manager, you'd have to manually type the FDE password at boot. You can't copy/paste it as if anything your password manager would be running on a different computer.

[colejohnson66]

How would backing up help? If you back up the encrypted data, then your backup is still useless because you don't have your password. If you back up an unencrypted copy, that defeats the purpose of encryption.

[rwmj]

Scribbling the passwords in a notebook isn't a bad idea (although don't write "My Passwords" on the front cover). The security of physical things is well understood by most humans.

[manigandham]

Or just remember TWO passwords... it's not that hard.