3 ms·

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

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 10y ago
That's the default. Easy to override--and I did after this--but admittedly ew. Maybe we should email the OpenBSD list?
- cperciva 10y ago
  Please do. I'm not sure exactly which list would be appropriate, and I don't want to provoke a "FreeBSD guy coming in and trying to tell us what to do" reaction anyway.
zaroth 10y ago
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)
- cperciva 10y ago
  Sure, scrypt would be much better than pbkdf2 here. But that's still no reason to not take a 200x increase in cracking cost; no matter how fast your adversary's ASICs are, there's a range of passphrase complexity where it will matter.
jorangreef 10y ago
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?
- cperciva 10y ago
  What's the usage model here? When you boot up the server, someone sits down at the console and types in 100 unique passphrases?
  - jorangreef 10y ago
    It's a single process managing multiple disks with a fixed-size extent system on each. 1. The process has a single passphrase entered at startup. 2. This passphrase is then used to derive the master key encryption key for each disk using the disk's own parameters (KDF_SALT, KDF_ITERATIONS) which are generated and estimated when the disk is formatted and added to the array (disks may come and go). 3. The master key encryption key for each disk is then used to decrypt the AF-split master key for each disk, similar to LUKS.

FiloSottile 10y ago

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

cperciva 10y ago
Please do. I'm not sure exactly which list would be appropriate, and I don't want to provoke a "FreeBSD guy coming in and trying to tell us what to do" reaction anyway.

zaroth 10y ago

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)

cperciva 10y ago
Sure, scrypt would be much better than pbkdf2 here. But that's still no reason to not take a 200x increase in cracking cost; no matter how fast your adversary's ASICs are, there's a range of passphrase complexity where it will matter.

jorangreef 10y ago

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?

cperciva 10y ago
What's the usage model here? When you boot up the server, someone sits down at the console and types in 100 unique passphrases?
- jorangreef 10y ago
  It's a single process managing multiple disks with a fixed-size extent system on each. 1. The process has a single passphrase entered at startup. 2. This passphrase is then used to derive the master key encryption key for each disk using the disk's own parameters (KDF_SALT, KDF_ITERATIONS) which are generated and estimated when the disk is formatted and added to the array (disks may come and go). 3. The master key encryption key for each disk is then used to decrypt the AF-split master key for each disk, similar to LUKS.