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.