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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
