Commit 6f9d696f authored by Eric Biggers's avatar Eric Biggers Committed by Theodore Ts'o

fscrypt: correct collision claim for digested names

As I noted on the mailing list, it's easier than I originally thought to
create intentional collisions in the digested names.  Unfortunately it's
not too easy to solve this, so for now just fix the comment to not lie.
Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
parent 90fce086
...@@ -81,20 +81,16 @@ extern int fscrypt_fname_usr_to_disk(struct inode *, const struct qstr *, ...@@ -81,20 +81,16 @@ extern int fscrypt_fname_usr_to_disk(struct inode *, const struct qstr *,
* followed by the second-to-last ciphertext block of the filename. Due to the * followed by the second-to-last ciphertext block of the filename. Due to the
* use of the CBC-CTS encryption mode, the second-to-last ciphertext block * use of the CBC-CTS encryption mode, the second-to-last ciphertext block
* depends on the full plaintext. (Note that ciphertext stealing causes the * depends on the full plaintext. (Note that ciphertext stealing causes the
* last two blocks to appear "flipped".) This makes collisions very unlikely: * last two blocks to appear "flipped".) This makes accidental collisions very
* just a 1 in 2^128 chance for two filenames to collide even if they share the * unlikely: just a 1 in 2^128 chance for two filenames to collide even if they
* same filesystem-specific hashes. * share the same filesystem-specific hashes.
* *
* This scheme isn't strictly immune to intentional collisions because it's * However, this scheme isn't immune to intentional collisions, which can be
* basically like a CBC-MAC, which isn't secure on variable-length inputs. * created by anyone able to create arbitrary plaintext filenames and view them
* However, generating a CBC-MAC collision requires the ability to choose * without the key. Making the "digest" be a real cryptographic hash like
* arbitrary ciphertext, which won't normally be possible with filename * SHA-256 over the full ciphertext would prevent this, although it would be
* encryption since it would require write access to the raw disk. * less efficient and harder to implement, especially since the filesystem would
* * need to calculate it for each directory entry examined during a search.
* Taking a real cryptographic hash like SHA-256 over the full ciphertext would
* be better in theory but would be less efficient and more complicated to
* implement, especially since the filesystem would need to calculate it for
* each directory entry examined during a search.
*/ */
struct fscrypt_digested_name { struct fscrypt_digested_name {
u32 hash; u32 hash;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment