New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identical filenames leak #128

Closed
rfjakob opened this Issue Jan 4, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@rfjakob

rfjakob commented Jan 4, 2016

Dear crypto colleagues, I am writing a comparison page for open-source file encryption solutions. I have noticed this:

A directory structure that looks like this

.
├── 1
│   └── foo.txt
└── 2
    └── foo.txt

is encrypted into this

.
├── 2W
│   └── QRJZGTBPW7534DP3JSM3DOJ4WD7HIJVJQJRSAJ3YJW4PGSC4TQ====
│       └── KDWJRAUM3MD4EOSAYFAVIZWCC3H2B2KKHZEW6===.file
├── 37
│   └── 4G4D7YD32UCC35JOMQHX6AOBCLJSMVTIEHEYMJNDYLQXHOFMSA====
│       ├── 7G44WJRXNDOZVWFYDPDK6EOQUWFQ====.dir
│       └── GOJZIS7FFNO2QRALU7ZA3GTTGQVA====.dir
├── N7
│   └── ETFMK3SSIUTDHGYOO3HLTZSABJXAZEU6ZNW6W5WQ6RV36VYVAQ====
│       └── KDWJRAUM3MD4EOSAYFAVIZWCC3H2B2KKHZEW6===.file
└── root

In other words, foo.txt is always encrypted into KDWJRAUM3MD4EOSAYFAVIZWCC3H2B2KKHZEW6===.file. This allows an attacker to identify identically-named files.

In EncFS, this problem is solved by including the full path into the IV, in gocryptfs there is a gocryptfs.diriv file for each directory with a random per-directory IV. eCryptFS, on the other hand, does nothing about it, hence has the same problem.

PS: Great project, keep going :)

@overheadhunter

This comment has been minimized.

Show comment
Hide comment
@overheadhunter

overheadhunter Jan 4, 2016

Member

Hey rfjakob, thanks for reporting. This will be solved by #119. We plan to pass the path (in our case the unique directory id) as "additional data" to SIV encryption, which will then have an impact on the IV.

The new encryption scheme is planned asap but we need to finish our current refactoring in the layered-io branch

Member

overheadhunter commented Jan 4, 2016

Hey rfjakob, thanks for reporting. This will be solved by #119. We plan to pass the path (in our case the unique directory id) as "additional data" to SIV encryption, which will then have an impact on the IV.

The new encryption scheme is planned asap but we need to finish our current refactoring in the layered-io branch

@rfjakob

This comment has been minimized.

Show comment
Hide comment
@rfjakob

rfjakob Jan 5, 2016

Sounds good! Just FYI, I have now published the comparison at https://nuetzlich.net/gocryptfs/comparison/ . Feel free to contact me if I misrepresent cryptomator somewhere.

rfjakob commented Jan 5, 2016

Sounds good! Just FYI, I have now published the comparison at https://nuetzlich.net/gocryptfs/comparison/ . Feel free to contact me if I misrepresent cryptomator somewhere.

@overheadhunter

This comment has been minimized.

Show comment
Hide comment
@overheadhunter

overheadhunter Jan 5, 2016

Member

Nice work, just three remarks: Cryptomator itself is solely MIT-licensed, the other license files are redistributed to comply with licenses of embedded libraries.Command line version is already planned, but it will still take a while (see #43) until we can start developing it. In the final release we will no longer use a random IV for content encryption but rather a per-key-unique 128 bit counter.

PS: And I think that the lower and upper bound for the encrypted size of a 1MB file should be 1,047,656 - 1,134,479

Member

overheadhunter commented Jan 5, 2016

Nice work, just three remarks: Cryptomator itself is solely MIT-licensed, the other license files are redistributed to comply with licenses of embedded libraries.Command line version is already planned, but it will still take a while (see #43) until we can start developing it. In the final release we will no longer use a random IV for content encryption but rather a per-key-unique 128 bit counter.

PS: And I think that the lower and upper bound for the encrypted size of a 1MB file should be 1,047,656 - 1,134,479

@rfjakob

This comment has been minimized.

Show comment
Hide comment
@rfjakob

rfjakob Jan 5, 2016

Updated, thanks. The bounds seem to high, though - note that I have used 1,000,000 bytes, not 1MiB.

rfjakob commented Jan 5, 2016

Updated, thanks. The bounds seem to high, though - note that I have used 1,000,000 bytes, not 1MiB.

@overheadhunter

This comment has been minimized.

Show comment
Hide comment
@overheadhunter

overheadhunter Jan 5, 2016

Member

Ok, you're right. Let's do the math ;)

Min: 0 byte padding:

// 1MB / 32kiB = 30 full blocks and 16,960 leftover bytes
30 * (32768 + 32) // full 32kiB blocks + mac
+ 16,960 + 32 // last block + mac
+ 104 // header
= 1,001,096 bytes

Max: 100,000 byte padding:

// 1,1MB / 32kiB = 33 full blocks and 18,656 leftover bytes
33 * (32768 + 32) // full 32kiB blocks + mac
+ 18,656 + 32 // last block + mac
+ 104 // header
= 1,101,192 bytes
Member

overheadhunter commented Jan 5, 2016

Ok, you're right. Let's do the math ;)

Min: 0 byte padding:

// 1MB / 32kiB = 30 full blocks and 16,960 leftover bytes
30 * (32768 + 32) // full 32kiB blocks + mac
+ 16,960 + 32 // last block + mac
+ 104 // header
= 1,001,096 bytes

Max: 100,000 byte padding:

// 1,1MB / 32kiB = 33 full blocks and 18,656 leftover bytes
33 * (32768 + 32) // full 32kiB blocks + mac
+ 18,656 + 32 // last block + mac
+ 104 // header
= 1,101,192 bytes
@rfjakob

This comment has been minimized.

Show comment
Hide comment
@rfjakob

rfjakob Jan 5, 2016

Lower bound looks good, but I see files as big as 1100872 bytes in a directory with 1000 files:

/tmp/cm-big.cryptomator/d/AV/WYUDCHTYRZKSKXEMDTGUEL6MFOJ3NQK2WNIG3WINZXAHQNHHNQ====$ ls -lS
total 1029836
-rw-------. 1 jakob jakob 1100872  5. Jan 17:50 3PXIHZLS26GBXG3NAV5TMRHYUFJRFSQ=.file
-rw-------. 1 jakob jakob 1100770  5. Jan 17:50 NWMT5UBN4TRKIRJVGZNXLIAD6UZSF6Q=.file
-rw-------. 1 jakob jakob 1100750  5. Jan 17:50 M6YNBMMDCA5IWDKCBQRJZWXWEUIZXKQ=.file
[...]
-rw-------. 1 jakob jakob 1001454  5. Jan 17:50 6GVTHEFJ2IHQP4PKRNI2N463ERBYFZY=.file
-rw-------. 1 jakob jakob 1001328  5. Jan 17:50 FS5LZQWG3K3HVKW5FCQGBD2RFPLE7ZY=.file
-rw-------. 1 jakob jakob 1001110  5. Jan 17:49 HTUNTR3N3VIKXKEBFI5ZZVBRWVDGA3I=.file

rfjakob commented Jan 5, 2016

Lower bound looks good, but I see files as big as 1100872 bytes in a directory with 1000 files:

/tmp/cm-big.cryptomator/d/AV/WYUDCHTYRZKSKXEMDTGUEL6MFOJ3NQK2WNIG3WINZXAHQNHHNQ====$ ls -lS
total 1029836
-rw-------. 1 jakob jakob 1100872  5. Jan 17:50 3PXIHZLS26GBXG3NAV5TMRHYUFJRFSQ=.file
-rw-------. 1 jakob jakob 1100770  5. Jan 17:50 NWMT5UBN4TRKIRJVGZNXLIAD6UZSF6Q=.file
-rw-------. 1 jakob jakob 1100750  5. Jan 17:50 M6YNBMMDCA5IWDKCBQRJZWXWEUIZXKQ=.file
[...]
-rw-------. 1 jakob jakob 1001454  5. Jan 17:50 6GVTHEFJ2IHQP4PKRNI2N463ERBYFZY=.file
-rw-------. 1 jakob jakob 1001328  5. Jan 17:50 FS5LZQWG3K3HVKW5FCQGBD2RFPLE7ZY=.file
-rw-------. 1 jakob jakob 1001110  5. Jan 17:49 HTUNTR3N3VIKXKEBFI5ZZVBRWVDGA3I=.file
@rfjakob

This comment has been minimized.

Show comment
Hide comment
@rfjakob

rfjakob Jan 5, 2016

Must be just have been a typo when you summed it up. Your formula looks good:

>> 33*(32768+32)+18656+32+104
ans =  1101192

rfjakob commented Jan 5, 2016

Must be just have been a typo when you summed it up. Your formula looks good:

>> 33*(32768+32)+18656+32+104
ans =  1101192
@overheadhunter

This comment has been minimized.

Show comment
Hide comment
@overheadhunter

overheadhunter Jan 5, 2016

Member

Yes, confirmed. Makes no sense that 1,100,000 bytes end up smaller than 1,100,000 😆

Member

overheadhunter commented Jan 5, 2016

Yes, confirmed. Makes no sense that 1,100,000 bytes end up smaller than 1,100,000 😆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment