On Fri, 2019-08-09 at 13:26 +0200, François Kooman wrote:
On 09.08.19 12:19, Petr Pisar wrote:
An algorithm that will be obsoleted by another modern algorithm in ten years. No this is not how cryptographical tools should be designed. The tool and the singature format must be agnostic to a concrete algorithm.
Actually. It is not designed like this, see [1] for the signature/key format.
This is an invalid argument. You can always found an arbitrarily old distribution that does not support a feature of your choice.
Fair enough, it is not an argument against using OpenSSL, just against using it on RHEL/CentOS 7 assuming one wants to use Ed25519 for signatures and not RSA or ECDSA.
There is no explanation why. Only a "don’t use a low-level crypto library like OpenSSL or BouncyCastle" statement. Do you have any explanation?
Okay, we are getting a bit off-topic here :-)
Using a low level crypto library like OpenSSL is a bad idea for developers. It gives them a huge foot gun. I know enough not to want to use the OpenSSL API as a developer. I will screw it up. I'm confident I can write an application using libsodium without the crypto implementation being the weak part. I'm sure that's true for most (all?) developers that are not also OpenSSL developers...
Unless you are a crypographer you will screw it up anyway :-) And if you are targeting Fedora/RHEL libsodium is a no-go for now.
Moreover, I cannot see how TLS is relevant to a code signing.
It is not. OpenSSL is (according to the blog post linked) only the best tool for doing TLS. For all other purposes it is not the best tool.
This is sophism, what you need, if you are really writing a signing tool, is someone expert in cryptography to check your code *anyway*, because there are many, many aspects of signing you may get catastrophically wrong otherwise. And an expert will know how you should use OpenSSL correctly anyway.
TL;DR: Do not think that using some new crypto library automagically makes you write correct code when cryptography is involved, always consult and use tools provided/vetted by your experts.
So introducing something like libsodium for non-TLS purposes seems like a good thing to do! Especially if this means dropping the OpenSSL/GnuPG dependency...
No it is not a good thing for the reasons you are providing. There may be good reasons, but writing a signing tool is not one of them for sure.
And using wellknown and maintained libraries (by your distribution experts) is a better reason to use what is available than introducing a new crypto-library on the promise that it is somehow "better".
I don't know what the reasons are for arguing against libsodium for non-TLS crypto use cases, maybe the foreseen (long term) potential costs in case libsodium would be added to RHEL, next to OpenSSL and GnuPG?
There is added maintenance cost for any new package, and crypto- libraries have a steep cost because they are more critical indeed (and fewer people can properly maintain them, I hate to cite it, but I'd like to remind you the Debian maintenance snafu a few years ago with OpenSSL that was catastrophic indeed).
We already have 4 crypto-libraries in the distro, I am not against a new one if you can drop another in the process (and the process is strictly: drop before adding)
Simo.