10 ms·

I would probably think twice before using anything based on EncFS. See this audit for a lot of detail: https://defuse.ca/audits/encfs.htm https://defuse.ca/audi

I would probably think twice before using anything based on EncFS. See this audit for a lot of detail: https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm

rian 12y ago
we're actually in the process of updating encfs to use XTS. also, that particular audit was done quickly and some of the analyses weren't done considering the threat-model that encfs is designed for (so it makes encfs look worse than it really is).
- hf 12y ago
  I removed this sentence from my previous comment to parent: From a layman's perspective, I should think the encfs authors came away from that analysis with a feeling of achievement: to have been audited (however quickly) and yet to live. If the above (grand-parent) is the worst tptacek says about encfs, I would argue that you are in decent shape.
- tptacek 12y ago
  encfs encrypts a-file-at-a-time, right? That's not an XTS use case.
  - rian 12y ago
    It can be. We want to move away from IV-based encryption primitives to tweak-based primitives for each individual file. This is just so more people understand how it works, especially since now XTS is a recommended standard. Right now we use a custom solution, which made sense in 2004 but now that XTS exists we can switch over.
    - tptacek 12y ago
      Wait, XTS is a standard recommended for block-level disk encryption. It's not a recommendation for file encryption. The two problems are similar, but not identical; for instance, block encryption has strict requirements on ciphertext size, and requires the capability to modify ciphertexts instead of just re-encrypting. Are you sure XTS is a good idea for file encryption? Wouldn't a simple AEAD mode do the job just as well, and also provide for file integrity?
hf 12y ago
As this surfaced, I was chiefly impressed by the fact that encfs was amenable to such a by-and-by[0] audit: the code-base must be at least somewhat legible. This "auditability" seems to me a strength worth nurturing. [0] Where "by-and-by" refers to the usual superhuman app-sec standards in which "10 hours" translate into actual, meaningful work.
2bluesc 12y ago
Defuse has done quick audits on both EncFS and eCryptfs. Both store their encrypted files in another file system. eCryptfs did substantially better then EncFS https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/ecryptfs.htm https://defuse.ca/audits/ecryptfs.htm Truecrypt is a different beast (acts as the basis blob or blockdev for a file system) and has done significantly better on more rigorous audits: https://opencryptoaudit.org/reports/ https://opencryptoaudit.org/reports/

I would probably think twice before using anything based on EncFS. See this audit for a lot of detail: https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm

rian 12y ago

we're actually in the process of updating encfs to use XTS. also, that particular audit was done quickly and some of the analyses weren't done considering the threat-model that encfs is designed for (so it makes encfs look worse than it really is).

hf 12y ago
I removed this sentence from my previous comment to parent: From a layman's perspective, I should think the encfs authors came away from that analysis with a feeling of achievement: to have been audited (however quickly) and yet to live. If the above (grand-parent) is the worst tptacek says about encfs, I would argue that you are in decent shape.
tptacek 12y ago
encfs encrypts a-file-at-a-time, right? That's not an XTS use case.
- rian 12y ago
  It can be. We want to move away from IV-based encryption primitives to tweak-based primitives for each individual file. This is just so more people understand how it works, especially since now XTS is a recommended standard. Right now we use a custom solution, which made sense in 2004 but now that XTS exists we can switch over.
  - tptacek 12y ago
    Wait, XTS is a standard recommended for block-level disk encryption. It's not a recommendation for file encryption. The two problems are similar, but not identical; for instance, block encryption has strict requirements on ciphertext size, and requires the capability to modify ciphertexts instead of just re-encrypting. Are you sure XTS is a good idea for file encryption? Wouldn't a simple AEAD mode do the job just as well, and also provide for file integrity?

hf 12y ago

As this surfaced, I was chiefly impressed by the fact that encfs was amenable to such a by-and-by[0] audit: the code-base must be at least somewhat legible. This "auditability" seems to me a strength worth nurturing. [0] Where "by-and-by" refers to the usual superhuman app-sec standards in which "10 hours" translate into actual, meaningful work.

2bluesc 12y ago

Defuse has done quick audits on both EncFS and eCryptfs. Both store their encrypted files in another file system. eCryptfs did substantially better then EncFS https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/ecryptfs.htm https://defuse.ca/audits/ecryptfs.htm Truecrypt is a different beast (acts as the basis blob or blockdev for a file system) and has done significantly better on more rigorous audits: https://opencryptoaudit.org/reports/ https://opencryptoaudit.org/reports/