[botan-devel] PEM_encode and ECDH_PrivateKey

Sean Cassidy sean.a.cassidy at gmail.com
Thu Feb 2 15:07:30 EST 2012


On Wed, Feb 1, 2012 at 3:11 PM, Jack Lloyd <lloyd at randombit.net> wrote:
> On Wed, Feb 01, 2012 at 02:11:52PM -0800, Sean Cassidy wrote:
>> Hello,
>>
>> I don't think the OID for ECDH is properly configured.
>> OIDS::lookup("ECDH"), the algorithm name given in ecdh.h, results in
>> an exception. Here is some code that exhibits this problem in v1.10.1
>> on Ubuntu:
>
> This is kind of a bug but also somewhat intentional. The issue is that
> ANSI X9.62 in its infinite wisdom decided that the same format *and
> the same OID* would be used to identify both ECDSA and ECDH keys. So
> serializing an ECDH key is easy, just set the OID. The problem comes
> when loading a key. There is no way to distinguish if it should be an
> ECDSA or ECDH key. Lacking any good approach I punted and defined the
> OID for ECDSA only on the theory that ECDH is rare.

It definitely is not common, that's for sure. I was using it mainly
for the novelty.

> There are a few solutions possible, none particularly appealing
>
>  - Define a new OID for ECDH. The optimal solution if you only care
>   about interoperating with botan, not so great if you need to
>   interact with a system that can't be configured with new OIDs.
>   Actually checking further it seems that this has already been
>   done: 1.3.132.1.12 is defined specifically for ECDH. However
>   a quick check shows virtually nobody uses/supports it :(

This is easily my favorite solution. While no one uses the OID, it's
standard and shouldn't conflict. I think the current behavior (being
unable to serialize ECDH keys) is worse than using a
standards-compliant but unused-in-production OID.

> Either of the first two cases you can do in your application code
> right now. For instance to use the ECDSA OID, add this to your main
> right after LibraryInitializer runs:
>
>   Library_State& botan_state = global_state();
>   const std::string ecdh_oid = "1.2.840.10045.2.1";
>
>   if(!botan_state.is_set("oid2str", ecdh_oid))
>      botan_state.set("oid2str", ecdh_oid, "ECDH");
>
>   if(!botan_state.is_set("str2oid", "ECDH"))
>      botan_state.set("str2oid", "ECDH", ecdh_oid);
>
> The same approach could be used for the 1.3.132.1.12 OID.

Thanks! I'll do this for now.

> You're apparently the first person who has come up against this (or at
> least the first to mention it), so any comments about what you're
> trying to do in the larger sense, what systems you want to interop
> with, etc would act as increasing my ECDH user sample set from 0 to 1,
> a substantial improvement.

I'm making a secure group chat program using Botan. I thought
supporting ECDH keys would be an interesting addition, and I don't
need to interop with any other systems. Does anyone who is actually
using ECDH keys, which are, as you said, rare, actually need to
interop? I think you may be a little too cautious in supporting the
new OID. But, of course, that's your call.

Thanks for your help!
Sean



More information about the botan-devel mailing list