3 ms·

Quick question for the more cryptographically inclined: apparently after decryption the code does an HMAC validation: /* Check that the key decrypted prope

by moyix 10y ago

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/ https://moxie.org/blog/the-cryptographic-doom-principle/

FiloSottile 10y ago
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.
Dylan16807 10y ago
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.
JoachimSchipper 10y ago
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/ http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/.
- koverstreet 10y ago
  Awesome article, thanks for posting. This explains better than I could the whole point of doing encryption in bcachefs: https://bcache.evilpiepirate.org/Encryption/ https://bcache.evilpiepirate.org/Encryption/ https://news.ycombinator.com/item?id=12410798 https://news.ycombinator.com/item?id=12410798
dfox 10y ago
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]

by moyix 10y ago

FiloSottile 10y ago

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.

Dylan16807 10y ago

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.

JoachimSchipper 10y ago

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/ http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/.

koverstreet 10y ago
Awesome article, thanks for posting. This explains better than I could the whole point of doing encryption in bcachefs: https://bcache.evilpiepirate.org/Encryption/ https://bcache.evilpiepirate.org/Encryption/ https://news.ycombinator.com/item?id=12410798 https://news.ycombinator.com/item?id=12410798

dfox 10y ago

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]