Messages in this thread | | | From | (David Wagner) | Subject | Re: eCryptfs Design Document | Date | Mon, 10 Apr 2006 02:11:36 +0000 (UTC) |
| |
Michael Halcrow wrote: >eCryptfs v0.1 Design Document
A few comments:
- I don't understand why you are using MD5 in a new design. This seems unnecessarily risky. I do not recommend using MD5 in new systems. Why not use something safer, such as SHA1?
- Like many other disk encryption schemes, this scheme provides no integrity protection. That doesn't matter, if you're only worried about passive attackers who can only observe the encrypted content, but if the attacker can modify the contents of your encrypted disk (e.g., because the encrypted data is stored on a networked filesystem), then you need integrity protection. The threat model doesn't make it entirely clear which type of adversary eCryptfs is trying to defend against. Section 2 mentions the assumption that the attacker potentially has access to every intermediate state but doesn't state whether this is just read access, or whether it also includes write access. Section 4.4 suggests that the data on disk is outside the control of the trusted host environment, which sounds to me like a suggestion that the adversary might be able to modify the encrypted data on disk.
- It looks like the scheme has some minor issues with IV reuse. If I understood correctly, when an extent is modified, the IV is not changed, and the new data is re-encrypted using the same old data and stored on disk. The problem is that this can occasionally leak information about the plaintexts. For instance, if I encrypt plaintext P, and then encrypt modified plaintext P' under the same IV, and if P and P' agree in their first k blocks, then the two ciphertexts will also agree in their first k blocks. This allows an adversary who can observe the encrypted data on disk both before and after a file write operation to tell how many blocks of data at the front of the extent remain unchanged by the write operation. I don't know whether this property is acceptable. It is probably a minor issue at worst.
- The document didn't explain what security advantages this scheme has over dmcrypt (if any).
- As you're probably already aware, the use of passphrases to generate encryption keys is a potential weak spot in the scheme, because many users will probably choose weak passphrases. This is common to all disk encryption schemes I have seen. The use of iterated hashing is a good idea and is about the best you can do. I'm raising this not to suggest that you should do anything different -- I don't have any better solutions to this problem -- but just as a reminder that it is a potential weak spot.
- I couldn't find any clear specification of the file encryption format. This makes it hard to review the security of the scheme. Presumably if I were feeling patient to spend a lot of time on this I could have pieced together most or all of the relevant details, but currently the document wasn't organized in a way that I could understand. Is there any chance of re-writing this in a way to it easier for cryptographers to review? What would help would be a section that fully specifies how to compute the encrypted data as a function of user-visible quantities. It would help to have a description that fully specifies all details that are cryptographically relevant (such as what modes of operation you are using) at a level that can be understood by someone who doesn't know anything about Linux kernel internals, but that omits implementation details irrelevant to cryptographic analysis (such as the name of the data structures in the Linux kernel that you are using). What I want to see is the mathematical algorithm, but I don't care how it is implemented internally. Also, the key management is of particular interest.
- Once the specification is clarified, I'd encourage you to post this where cryptographers hang out. Sci.crypt and Perry Metzger's cryptography mailing list would be two good choices. There is a chance you might get some helpful comments. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |