Re: Regarding ideas to replace gpgv with sqv
On Sat, Feb 06, 2021 at 11:59:52AM +0100, Justus Winter wrote:
> Julian Andres Klode <jak@debian.org> writes:
>
> > On Tue, Feb 02, 2021 at 04:12:19PM +0100, Julian Andres Klode wrote:
> >
> >> [...] issues like the inability to deprecate MD5 or SHA1 for ages.
>
> Are you absolutely sure that this is the metric by which you want to
> judge protocols?
The ability to deprecate unsafe algorithms is one of the key defining
metrics of a signature scheme. OpenPGP, having to work with a lot of
clients and not having the ability to just require a particular version
of a client, has completely different needs, and the WG is substantially
too slow at deprecating unsafe stuff.
The other metric is signature complexity, which clearsigned OpenPGP is a
huge giant freaking mess. It was designed for email, not for arbitrary
content and has all sorts of complex issues related to quoting and other
shit which caused issues before.
My trust level in the main implementation, GnuPG is like 1 on a scale of
0 (bad) to 10 (good). I wanted to get rid of it in like forever.
Other implementations still have to deal with all the email complexity,
and apt has to deal with all that email complexity in its own
clearsigned file splitting code, which is why there seems to be great
excitement for going for a signature scheme that tightly integrates with
the stuff we want to sign and does not require all that complexity.
And then we have to also deal with other dependencies and cannot move at
our own pace based on latest cryptography research, and will lack far
more behind than we want to (given that we need to commit to algorithms
for roughly 8 years, see third section below discussing the algorithm
questions).
In an ideal world, minisign would just work, but due to unique
challenges of signing deb822, it does not. I also want to make some
different choices like potentially having subkeys with expiry dates to
allow for key rotation, and including entire public keys in the
signature rather than keyids to ensure I can validate (lint) the file
without having to acquire keys out of band. And of course, the ability
to move to a new signing scheme at our own pace rather than having to
wait for a third party to approve one is most welcome too.
I suggested switching to X.509 for the past half decade, which clearly
is a superior solution to GPG, as it had a ton of libraries already
and they have far more interesting targets to attack than apt repositories.
but it too lacks the simplicity of the proposed new format.
The simplicity comes at the cost of having to write our own signing
code, and arguably deal with PKCS#11 smartcards, which sucks, but it's
probably a good idea. (sure you could also sign with minisign and
convert the signature once we're compatible enough, but those tools do
not offer smartcard support).
Our goal should be to ask how we can make the verification as easily to
analyse as possible, and I think this is probably the way to go, and I
appreciate being able to make super specific demands on third party
repository signatures :-)
>
> > and a proof of concept at
> >
> > https://gist.github.com/julian-klode/4514ce39d3dc62647b502e5a8cf6a3ef
>
> https://gist.github.com/julian-klode/4514ce39d3dc62647b502e5a8cf6a3ef#file-inrelease-L10
> https://gist.github.com/julian-klode/4514ce39d3dc62647b502e5a8cf6a3ef#file-inrelease-L927
> https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/MD5SUMS.sign
> https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/SHA1SUMS.sign
> https://releases.ubuntu.com/bionic/MD5SUMS-metalink.gpg
There are several legacy users that use MD5 values. For example, jigdo
needs md5 values to be able to assemble iso images, because the jigdo
file format was not future proof.
In relevant things however, APT requires SHA2 since Mar 2016 ...
(continued)
>
> In all seriousness, of course OpenPGP has deprecated these hashes (MD5:
> [0], SHA1: [1]), and sane implementations reject signatures based on
> them (MD5: [2], SHA1: [3]).i
...
_Substantially_ too late, though. APT started rejecting MD5 in Sep 2015
and SHA1 in Mar 2016, but Ubuntu 16.04 is still vulnerable to SHA1
attacks until it's EOL (2024) because gpg only did it much later, and
our efforts are essentially in vain.
Even to this day we still accept DSA signatures, because we can only
block hash algorithms from gpg, but not key algorithms and sizes. What
we really want at the moment (since 2016, really) is to only allow RSA
keys larger than 2048 bytes or Curve25519 keys. But we still accept DSA
keys and 1024 bit RSA keys because we can't tell gpg to stop accepting
them.
Now it's true that a well designed OpenPGP library would also give us
the ability to narrow the choice of algorithms and key sizes down to
what we want (at least that's my hope), but then as mentioned before, if
we start doing this work, we might as well go for a scheme that does not
carry around all the OpenPGP baggage we don't actually need, and I
applaud OpenBSD to came up with the idea of signify(1).
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: