Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

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

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

include/linux/fscrypt_supp.h

+9 −13
Original line number Diff line number Diff line
@@ -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

 * use of the CBC-CTS encryption mode, the second-to-last ciphertext block

 * depends on the full plaintext.  (Note that ciphertext stealing causes the

 * last two blocks to appear "flipped".)  This makes collisions very unlikely:

 * just a 1 in 2^128 chance for two filenames to collide even if they share the

 * same filesystem-specific hashes.

 * last two blocks to appear "flipped".)  This makes accidental collisions very

 * unlikely: just a 1 in 2^128 chance for two filenames to collide even if they

 * share the same filesystem-specific hashes.

 *

 * This scheme isn't strictly immune to intentional collisions because it's

 * basically like a CBC-MAC, which isn't secure on variable-length inputs.

 * However, generating a CBC-MAC collision requires the ability to choose

 * arbitrary ciphertext, which won't normally be possible with filename

 * encryption since it would require write access to the raw disk.

 *

 * 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.

 * However, this scheme isn't immune to intentional collisions, which can be

 * created by anyone able to create arbitrary plaintext filenames and view them

 * without the key.  Making the "digest" be a real cryptographic hash like

 * SHA-256 over the full ciphertext would prevent this, although it would be

 * less efficient and harder to implement, especially since the filesystem would

 * need to calculate it for each directory entry examined during a search.

 */

struct fscrypt_digested_name {

	u32 hash;