Lutz Behnke wrote:
>
>
> Hmm... I was planing to do away with the whole cipher for those contexts
> that do pkcs11. They would know whether they are 'native' or pkcs11
> ctx's
>
> And the methods would handle them accordingly. The pkcs11 ctxs are
> configured
> in terms of 'mechanisms' rather than ciphers.
Yes I know. I was wondering how you would handle the interface. You
could attempt something completely different or extend the EVP stuff. As
I said the current problem is that the EVP_CipherInit stuff:
void EVP_CipherInit(EVP_CIPHER_CTX *ctx,EVP_CIPHER *type,
unsigned char *key, unsigned char *iv,int enc);
is not very flexible. The key length and all the cipher parameters are
fixed by the passed EVP_CIPHER structure. Some kind of extended version
would be better all round:
e.g.
int EVP_CipherInitExt(EVP_CIPHER_CTX *ctx,EVP_CIPHER *type,
unsigned
char *key, int keylen, void *param, int enc);
Where 'param' contained cipher specific stuff. The EVP_CIPHER passed
would be a 'generic' cipher like EVP_rc2_cbc() and param in this case
would contain stuff like the effective number of bits and IV.
This might involve considerable surgery of individual ciphers and/or
addition of dynamically allocated stuff. Adding dynamic stuff would also
be broken by structure copying but that wouldn't matter because older
code wouldn't know about EVP_CipherInitExt().
Something like this is needed anyway because the cipher specific ASN1
stuff doesn't work properly at all for anything that passes more than
just the IV in the AlgorithmIdentifier.
Also EVP_Seal() and EVP_Open() mishandles RC2 (and any other variable
key length ciphers) when the wrapped key size doesn't match the hard
coded value: it bombs out with an error.
Hmm I wonder I could integrate password based encrytpion code in here
somewhere...
The current EVP_CipherUpdate() and EVP_CipherFinal() has inbuilt PKCS
padding and I'd guess that at least some points in the code assume that
arbitrary lengths of data can be passed through.
The EVP_Cipher() interface can be used to bypass the padding.
Or to summarise IMHO its a bit of a mess!
> >
> > Another problem is how you 'clone' a context, that is make an
> > independent copy. One way to do this is to just copy the context
> > structure. If you do that it will break PKCS#11 because the two would
> > not be independent. What is needed is some kind of EVPCipherClone and
> > EVPDigestClone functions and strong recommendations that that is the
> > *only* supported method and of course fixing broken older code that just
> > copies the structure.
>
> Where is this cloning used? Any particular lines in the openssl code
> or in applications?
I did a quick look. The bio stuff does this for digest and ciphers when
it dup's a BIO. The sign and verify also does something similar. There
may well be lots of other areas.
As to application code I'm not sure. Since the only way to clone a
context is to copy the structure anything needing this functionality
would have to do it.
I'd guess you'd need to save the current session state and restore it
in a new session with PKCS#11 but I suppose individual libraries could
either not support that or refuse to restore the session state because
the context already existed.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
