Renaming AES to AES-128

Bernhard Reiter bernhard at
Fri Dec 10 18:11:38 CET 2010

Am Donnerstag, 2. Dezember 2010 12:40:24 schrieb Werner Koch:
> On Tue, 30 Nov 2010 14:40, bernhard at said:
> > Leaving the primary identifier like it was, is a source of confusion
> > which also has a cost. What is the cost and consequences of the ABI
> > change?
> Debian alone lists 225 packages depending on libgcrypt.  And there are
> for sure many more users.  All these packages would need a rebuild and
> the maintainers need to go over it to figure out whether the change may
> affect them.

Can you explain briefly to me, why they would need a rebuild
and why ABI usage is really broken?
I mean applications with use gcry_cipher_open(x,GCRY_CIPHER_AES,..) and this 
will just continue to work.

Okay gcry_cipher_algo_name(GCRY_CIPHER_AES) would return "AES-128"
instead of "AES", but does this really warrant a rebuild? The index number 
just stays the same.

> You don't change an ABI if there is not a serious reason to do that.
> Those who want to list "AES-128" instead of AES may easily use a wrapper
> like
>   const char *
>   cipher_algo_name (int algo)
>   {
>     if (algo == GCRY_CIPHER_AES)
>       return "AES-128";
>     else
>       return gcry_cipher_algo_name (algo);
>   }

So we could do this for gpg2 --version?

> > deprecated so it will go away after X years. Could there be software that
> > would still stumble then?
> We can't know.

The list of supported algos will evolve over time, 
why not change the behaviour here?

Managing Director - Owner:       (Free Software Company)
Deputy Coordinator Germany: Board member:
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20101210/6debc780/attachment.pgp>

More information about the Gnupg-devel mailing list