On 4/15/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 4/15/07, Michael Halcrow <[EMAIL PROTECTED]> wrote: > Note that eCryptfs whitelists the cipher name (see > fs/ecryptfs/crypto.c::ecryptfs_cipher_code_str_map[] and associated > functions). This is because eCryptfs needs to pick a cipher code > (RFC2440-ish) to identify the cipher in the encrypted file > metadata. Shall I go ahead with a patch to add support for the '-' > qualifier?Whitelisting the possible ciphers (and associated parameters) would make sense if eCryptfs wants to support only a specific subset of the available ciphers (which is how it ends up, presently). This seems to be an unfortunate relic of the fact that eCryptfs is based too tightly on PGP and hence only supports those ciphers that were mentioned in RFC2440 (minus IDEA and SAFER-SK128, which do not exist in the kernel CryptoAPI as of now). The downside is that as and when new ciphers come into the CryptoAPI, you'll need to keep maintaining / adding on to that ecryptfs_cipher_code_str_map[] list (or not support them). The IPsec code (net/xfrm/xfrm_algo.c:{a,e}alg_list[]) does some similar whitelisting, but then they *have* to be conformant to the IPsec RFCs. I don't see why eCryptfs is limiting itself by restricting itself to the decade-old RFC2440. The absence of CAST6 and Twofish from that list is particularly sad. A better idea would be a patch that gets rid of whitelisting itself?
On second reading, I didn't make myself completely clear that time. As you said, you do require the whitelist to read the cipher tag in the metadata, which is what is a relic of the eCryptfs design's tight dependence on PGP (effectively considering every file to be an independent PGP message). If the key management scheme weren't simply a port of PGP to filesystems, it should have been possible to configure the cipher specs once per encrypted volume, in such a way that gets rid of the per-file-cipher-specs-tag-reading code itself. That way, you could've simplified that code to just read and use a per-volume cipher as long as it's included in the compiled-in cryptoapi ... so there goes the whitelist / tag business. (In any case, I really don't see a usage scenario in which a user would ever want to keep /ecryptfs/foo AES-256-encrypted and /ecryptfs/bar Blowfish-128-encrypted and so on -- the per-file PGP-message analogy is *overkill*). I might be answering myself here, but clearly, removing the whitelist does not seem possible given the PGP-message-framework eCryptfs was designed in. - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
