Plan B - Who carries the torch?

[Ángel]

On 2021-01-03 at 15:35 +0100, karel-v_g--- via Gnupg-users wrote:
> > Yeah.  Less time worrying about how to make OpenPGP continue
> > for>another twenty years, more time spent about how to make a next-
> > >generation cryptographic tool that will occupy the same space
> > OpenPGP>did but will do it better and with more modern techniques.
> I totally agree with you on that. Though I have no idea how to do it,
> I think in the midterm we need something totally new with modern
> crypto-technology, easy to use and lean. Like WireGuard for VPN or
> the modern messengers.

Changing OpenPGP standard to use a Quantum-resistant algorithm would be
"easy".

With really big quote marks in bold typeface. But simple in theory.


First, you would need a new public key algorithm resistant to the new
attack e.g. Quantum-resistant.

I don't think a new simmetric cipher would be needed, current AES
options should stand even in Quantumcalypsis.

Then, you will need to assign an algo id for the new algorithm and set
the way the parameters will be stored in the key. You get all
implementations to add support for that new algorithm (well, at least
all implementations used by people you care about).

Finally, every user will need to discard their now-useless keys,
generate new ones and rebuild the chain of turst from the ground up.


Right now, we don't even have the candidate on what such algorithm will
be. Hopefully, it will appear long before that Quantumcalypsis.
Then, getting one or two implementations to support it may be simple,
but the OpenPGP ecosystem is a very fossilized environment. We still
haven't reached broad ECC support. There are some implementations which
still don't support it at all. And in other cases the program would
support it, but the user happens to use an ancient version that they
didn't update for many years.


As for the need of creating new keys and rebuilding the WoT, that's
sadly a consequence of the way openpgp keys are structured. There's no
clean way to progressively migrate into a new asymmetric algorithm.
For symmetric ciphers you do that with multiple subkeys, but not for
asymmetric keys. Well, you _could_ do that, but either the main key
uses the new algorithm (and thus old clients wouldn't be able to use
the key, so no reason for adding a classic subkey) or if the main key
used a classic algorithm, that would be the key being attacked, so
there is still no point for that.
At most, you could use two separate keys, one using "new" and other
"classic" crypto, and use them selectively (depending on who you
communicate with) or in parallel (i.e. always signing everything with
both keys).
It would be nice to have a way to attach a new, modern, key to a
backwards-compatible key, but that seems hard to construct (the
fingerprint would *not* cover the new key, or otherwise, you would need
to (ab)use an ignored portion of the public key block).


Regards

Ángel