iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fscrypt: correct collision claim for digested names

Browse Source 
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: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This commit is contained in:
Eric Biggers 2017-05-01 11:43:32 -07:00 committed by Theodore Ts'o
parent 90fce086ed
commit 6f9d696f01
1 changed files with 9 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
include/linux/fscrypt_supp.h
View File

@ -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;