> James Yonan wrote: > > > > Given that the EVP level is supposed to offer callers a cipher-independent > > interface, where the caller doesn't necessarily know the idiosyncracies of > > the underlying cipher, wouldn't it make sense for evp/e_des3.c to call > > des_set_key_checked() instead of des_set_key_unchecked() and return an error > > status in the case of a weak key? > > Makes sense to me!
Maybe EVP_CipherInit should silently mutate a bad key (such as DES weak, semi-weak, or bad parity) using some kind of deterministic transform that's guaranteed to generate a strong key (like des_set_odd_parity does for the DES case of bad parity). The transform would be done internally, the key passed to EVP_CipherInit wouldn't be touched. This way, apps can generate random keys and not have to worry about what cipher they're going to be used for. And it protects apps against future versions of OpenSSL that might contain new EVP ciphers that have their own particular class of weak keys. James Yonan ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
