On Mon, 2017-05-22 at 13:18 +0200, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
- Fix the ABI problem (which unfortunately implies an abi
break). Some progress, but I don't think I've published my wip branch.
I'd recommend against breaking the ABI. It would mean that any new additions would take significant time to be propagated into distributions. Is there a way to fix the issue by introducing new safe APIs?
Problem is described at https://trofi.github.io/posts/195-dynamic-linking-ABI-is-hard.html. As I understand it, when I added SHA3 hashes to the nettle_hashes list in the nettle-3.3 release, that was intended to be binary compatible with earlier releases. But it wasn't, for traditional non-PIE executables linking dynamically with nettle, due to the way R_X86_64_COPY relocations work.
As far as I'm aware, the only fix which is going to be binary compatible with executables linked with all of nettle-3.1, -3.2 and -3.3 would be to drop sha3 from nettle_hashes. And that would clearly break compatibility with nettle-3.3 in a different way.
But my plan was to rename the symbol nettle_hashes to _nettle_hashes, add a function get_nettle_hashes to return its address, and define nettle_hashes as a macro expanding to get_nettle_hashes(). Which would be a compatible change to the API, but a break of the ABI.
Maybe it's possible to leave the old halfway broken symbols in place in some way. One could define the nettle_hashes symbol as an alias for _nettle_hashes, which would be left around in the .so file but unused when using updated header files.
Advice appreciated.
A backwards compatible approach is to leave the nettle_hashes accessible and provide the function as well. That will not be any more broken than 3.3 is, and would allow 3.3 programs to be linked with 3.4 without recompilation.
You can warn on use of nettle_hashes with the attached patch, most likely you can introduce a custom message as well with the replacement function.
While interesting to have, is there any practical use of it?
Unclear. May be of more interest if it turns out to be significantly faster than sha3.
I think we are moving to a setting where we have fewer and better studied/optimized options encryption/hashing in contrast with the pre- AES era on which we were including multiple ciphers in crypto libs, in the hope that few of them would be good. A new hash as such, I don't think has any use today as most of the use cases would be related to digital signatures or standard protocols, which have no reason to include a skein variant (for the majority of protocols sha3 isn't there yet either).
regards, Nikos