[botan-devel] PEM_encode and ECDH_PrivateKey
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:
>> 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: 220.127.116.11.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 18.104.22.168.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!
More information about the botan-devel