I'm not clear on a number of points. I think the easiest way to
handle this is to give some of the requirements of the EVP interface
(not all of which work properly at present) and you can see if that fits
in with your proposal.
Heres the first requirement...
The symmetric cipher code must have some cipher independency in fact it
should have a lot. The reason for this is so the EVP_Seal/EVP_Open stuff
can work properly. It doesn't currently work properly and can't work
properly under the current system which is one reason the EVP interface
needs an overhaul.
EVP_Open will typically decrypt an RSA block using a private key. Its
output will be a key and a key length. The key length is the current
sticking point.
The actual cipher to use will be determined by other means. One such
method is via an ASN.1 AlgorithmIdentifier defined as follows:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
The "algorithm" object defines the cipher type and the "parameters"
define any cipher specific info.
The "algorithm" object is the NID part of the cipher. In the examples
I'm aware of there is only one NID per cipher type. That is there is
only one RC2 and RC4 object. This immediately shows how the current code
is broken.
So what you have is this: a key, a key length, a NID giving the cipher
type and some ASN.1 parameters which give cipher specific info.
Now in the cases of some ciphers like DES-CBC and 3DES-CBC the
'parameters' only contain the IV. In the case of RC4 it doesn't contain
anything at all. In the case of RC2 it contains an indication of the
effective key length and the IV.
For ciphers with a fixed key length (DES, 3DES) if the key length is
anything other than that fixed value it is an error.
For variable key length ciphers this determines the actual key length,
for example RC2, RC4: this is not handled at present. In fact it can't
be handled at present because the current EVP stuff only provides a
small number of ciphers with fixed key lengths: if your key length isn't
one of the list your are out of luck.
Now what you should be able to do is have an interface where EVP_Open
contains no symmetric cipher specific code (it doesn't at present but it
doesn't work properly either).
The reverse side of things is that you should be able to generate
this ASN.1 stuff. EVP_Seal shouldn't have any cipher specific code
either but the user will obviously need to call some cipher specific
code with the relevant parameters and get the ASN.1 stuff out.
This is all much easier if you do allow EVP_Open to contain cipher
specific code.
However if you don't have EVP_Open contain cipher specific code then you
get some algorithm independency.
Suppose someone writes a brand new cipher, this cipher might be
implemented in hardware for example.
If the EVP_Open/EVP_Seal interface works properly this wont matter. As
soon as the new algorithm is added it will automatically be supported:
it would register a NID and contain some ASN.1 code.
What EVP_Open should be able to do is look up the new cipher by its NID
and then use its various functions to decode the ASN.1 stuff and set the
key and key length. It should then be able to give an error or a
properly initialised cipher context structure.
Now *every* cipher doesn't need to fit in this model, some might not
want anything to do with this ASN.1 stuff some might not have any ASN1
stuff registered.
How this fits in with PKCS#11 is a bit more ambiguous.
It can be handled directly where the key and key length come from
EVP_Open and the other object attributes come from the NID and algorithm
identifier: you'd need an "ASN.1 wrapper" round a PKCS#11 algorithm for
this to work. You'd typically decrypt the key block and then build up a
PKCS#11 object with all the bits.
Alternatively you could have a PKCS#11 mechanism partially override the
EVP_Open interface and call C_Unwrap. This has the advantage that the
unwrapped key never leaves the PKCS#11 library and is never directly
visible to the user, or more importantly an attacker. EVP_Seal could be
handled similarly.
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]
