On 4/15/07, Satyam Sharma <satyam.sharma@xxxxxxxxx> wrote:
On 4/15/07, Michael Halcrow <mike@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
