On Tue, 2014-11-25 at 07:28 +0100, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Can you give some example of what you're doing?
I provide an API such as: ctx=cipher_init(cipherno, key) cipher_encrypt(ctx, data) cipher_decrypt(ctx, data) cipher_deinit()
And what does cipherno represent here? Just "AES", or does it imply a key size and/or a mode of operation too?
Yes, something like AES-128-CBC.
Does it really matter to differentiate? I mean in my code I wrap stream aead, and block ciphers equally,
With "block ciphers", I imagine you include ECB mode, not just CBC and CTR and the like?
I don't have ecb mode at all since it is not used by TLS (or any other protocol). Just cbc, and gcm for now.
And the way I recommend (but maybe that doesn't work for you?) is to use an array of constant structs, similar in spirit to struct nettle_cipher and struct nettle_aead, rather than a big switch.
That looks like a nice approach. I may even be able to re-use some of the structures already in nettle to save some memory.
As far as I understand, the versions symbols thing should help. I guess sonames have to be bumped again when version symbols are introduced?
Not needed. But the version with the symbols will be binary incompatible with the previous one, so it may make sense to bump the soversion again to make that clear that they are incompatible.
Can a program linked with nettle-3.0 use a nettle-3.1 library with versioned symbols at runtime? If not, we must have another soname bump.
No it will not.
Symbol versioning would save the day there too though :)
If we introduce symbol versioning, it seems good to do it for both libraries at the same time.
I think my patch addresses that for both. What I now realize is that that mini-gmp mpz_*, gmp_* and mpn_* symbols are not exported in the script that I sent. They could be put unconditionally there, or via a configure variable.
regards, Nikos