[Botan-devel] Major changes/app breaking in PK code in 1.9

Jack Lloyd lloyd at randombit.net
Fri Mar 5 17:08:23 EST 2010


An update on what's going on in 1.9:

I've finally gotten around to a refactoring that I have had in mind
for several years, which is splitting up the PK operations (eg,
signing or encryption) from the key objects. Now PK key objects, for
instance RSA_PrivateKey, have no facilities for actually performing
operations, instead you have to acquire an operation for
them. Previously this was handled internally by the key objects. Now
they simply represent key material.

If you are using the classes in pubkey.h (like PK_Encryptor) this
shouldn't affect you too much. However if you calling operations on
key objects directly, your code will no longer work. If you are
directly calling things like DSA_PublicKey::verify, your code will no
longer compile.

Somewhat obnoxiously, this will break even code that uses the pubkey.h
interfaces, because classes like PK_Signing_Key no longer exist at
all. This is because a key having the ability to sign or not is by
virtue of an engine having an operation for singing for that key, not
because of any interface the key material object itself provides. I
think this is worth it, because it fixes a lot of problems in the
engine code and allows much greater flexibility down the road; for
instance if you wanted ElGamal signatures (which are not supported in
the library), you can simply add an engine which implements signatures
for ElGamal keys with very little fuss. It also gives a path for
dealing with the certain oddities in the current standards for ECC,
like that ECDSA and ECDH keys are indistinguishable in an X.509 cert.

On the other hand I do feel somewhat uneasy about breaking code that
was written in exactly the way the API reference has recommended
forever. If you care about this, I would suggest checking out the
lastest code (either through monotone [1] or a snapshot [2]), maybe
there is a way to deal with this that does not break application code
that I have not thought of. I would welcome comments and suggestions.

-Jack

[1] http://botan.randombit.net/monotone.html
[2] http://botan.randombit.net/snapshot



More information about the botan-devel mailing list