Jeff Garzik linked to this article suggesting older (18.04) Ubuntu encrypted disks might be vulnerable to brute-force attacks:
In general you shouldn't trust on disk encryption schemes for data at rest as it uses a new IV per block, and the IVs have to be deterministic, when the AES candidates expect randomized IVs (iirc). In this case the "vulnerability" was PBKDF2, which does not actually enforce a hash function nor a number of iteration. I don't expect the first instance of LUKS is using SHA512 nor 512k passes, which is the more common use of PBKDF2 you encounter these days.
Still, even with those parameters, I believe PBKDF2 can be brute forced by a state actor nowadays. It is a bit unsettling Ubuntu would use such a weak KDF when you need to unlock your key only at system start (meaning it's ok if it takes a few seconds, it won't degrade user experience).
A fresh install of a later distro (22.04?) would seem to plug the possible vulnerability.
The recommendation is to set the KDF manually, which likely can be changed after that fact. Disk encryption schemes do not typically encrypt the all the data on disk with your password. Rather, they encrypt a master key entry, and that master key is used to encrypt the actual data. This allows you to change the encryption key (or parameters in this case) on the cheap. If you really want to be sure of your encryption strength, this is what you need to do. Just updating your OS does no guarantee the default LUKS settings offered by the GUI installer (what most people use unless your an Arch nut) will fit your security needs.
Does Armory offline run on Ubuntu 22.04?
The dev branch does, but it's not user friendly yet. If you want to run 96.5 on Ubuntu 22.04, you'll need to install both py2 and qt4, or setup a 18.04 VM.
In passing, this made me wonder if the Armory transaction-signing / key-exposing password has any anti brute-forcing mitigations? Could a 20+ mixed character password still survive today's attacks?
Funny you ask, I looked at the KDF code last week. Armory uses Scrypt, which is a memory intensive KDF. The current parameters allow up to 32MB per pass and target a between 0,25 to 2 seconds long unlock based (this is something you can set to its upper bound at wallet creation/password change). I was considering removing the hardcoded limits.
Of the top of my head, to crack a 20 characters password, you would need something like 10^20 attempts per seconds to be able get a solution within a lifetime. If it takes anywhere near 0.1s to perform a single attempt, I don't think there's enough hardware on the planet to handle that.
