On Fri, Apr 27, 2007, Brent Casavant wrote:

> Hello,
> 
> I'm developing an engine to support hardware acceleration of a number
> of different block ciphers, some of which OpenSSL does not (yet) have
> native support for (e.g. AES 128 CTR, TEA, etc).
> 
> One of the problems I'm trying to solve is registering these new
> ciphers with OpenSSL.  My understanding, reading snippets of -dev
> and the source code, is that I must create a new nid using
> OBJ_create(), and then use EVP_add_cipher() with the resulting
> NID.  Then I'll add the cipher to the list made available by the
> function I register with ENGINE_set_ciphers().
> 
> Does that sound correct?
> 

You create an EVP_CIPHER structure using the NID and pass the EVP_CIPHER to
EVP_add_cipher().

> If so, is there a standard naming scheme to pass for the oid and
> sn arguments to OBJ_create()?  I'd like, if possible, to end up
> with the same names that OpenSSL would use, if these ciphers are
> ever supported in the mainline OpenSSL software.
> 

The OBJ_create() function creates an ASN1 OID. Often when a cipher is
documented an appropriate OID is included in the definition.

The only real guarantee is that the OID will be identical if it is used by
OpenSSL and the OID is a standard one as opposed to one that is made up.

> Second, I'd like to make this cipher registration as robust as
> possible given that future versions of OpenSSL may have native
> support for these ciphers.  Do you see any problems with the
> following pseudo-code (lack of error handling aside)?
> 
>       if (NULL == EVP_get_cipherbyname(cipher_name)) {
>               nid = OBJ_create(cipher_oid, cipher_sn, cipher_ln);
>               EVP_add_cipher(new_cipher);
>       }
> 
> This would, hopefully, allow run-time detection of the built-in ciphers,
> and install the new cipher if it is not built-in.  EVP_get_cipherbyname()
> doesn't take any functional/structural references that I need to free,
> does it?  (I don't think so, as I can't find any release functions.)
> 

Given that the OID is the only thing that is guaranteed to be identical (with
the conditions above) the best option is to first check to see if the OID is
registered using:

nid = OBJ_txt2nid("1.2.3.4");

if (nid == NID_undef)
        nid = OBJ_create(...);

Then using the nid you can use EVP_get_cipherbynid() to see if the cipher
exists.

> Finally, is there a clear illustration of what sort of information
> I need to add with regards to ASN.1 and the newly registered cipher?
> I've looked through the code, Wikipedia, and done some Google searches,
> and think I understand the general concept, but not exactly what I'm
> expected to provide within an OpenSSL engine.
> 

The ASN.1 depends on what the cipher will be used for. If it will never be
used with ASN1 structures then you don't need any ASN1 handling.

If it will be used with ASN.1 structures you need to handle any defined
functionality, for example setting cipher parameters such as the IV. Again the
cipher documentation should define the appropriate AlgorithmIdenifier
structure.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to