Re: Suggestions of standards added to openpgp/Gnupg/LibrePgp
Hakun_the_eril via Gnupg-users <[email protected]> Tue, 31 Mar 2026 22:18:01 +0200
| Newsgroups | gmane.comp.encryption.gpg.user |
|---|---|
| Message-ID | <CACnSDUtFiD1L=1KwSN+z+svZixfJ8zPux2Oe0HN5W1eCx81o8A@mail.gmail.com> |
Problems and pitfalls can be solved. tir. 31. mars 2026, 18:36 skrev Andrew Gallagher via Gnupg-users < [email protected]>: > Hi, Hakun. > > On 31/03/2026 16:09, Hakun_the_eril via Gnupg-users wrote: > > > > My arguments are: > > Shamirs secret has been around since 1979,- I find it odd that it is not > > included in Openpgp. > > It could add things like distributed key custody, hardware enforced > > split custody. Right now,- if someone with a key leaves or dies > > important encrypted data gets lost. > > It's relatively simple to combine Shamir with *PGP - for example, in > keys.openpgp.org, we have used Shamir to split a strong encryption > passphrase and used it to protect PGP secret key material using the > standard string-to-key mechanism. There are also tools available to > derive key material directly from a shared secret (e.g. > https://git.distrust.co/public/keyfork/). Since it is technically nobody > else's business what we do with those secret shares, it's not clear to > me what a new specification would add (but I am open to argument!) > > > Ephemeral signed elliptic curve diffie hellman is usable, because it > > will solve a forward security issue. > > If you encrypt say radio transmissions with the same key over long > > periods anyone who gets hold of that key can decrypt old transmissions. > > TLS 1.3 , the signal protocol and versions of openssh that is never > > than 5.7 supports this. > > There are many implementation pitfalls inherent in any forward secrecy > scheme, particularly when using a high-latency communications medium > such as email, and in multi-device scenarios. Most forward-secrecy > schemes rely on interactivity to ensure the stability of the ratchet; > and this can fail catastrophically even in supposedly low-latency > systems (google for "matrix unable to decrypt"). > > You may be interested in https://autocrypt2.org (work in progress), > which addresses a lot of these practical issues without requiring a > novel encryption algorithm. > > A > > > _______________________________________________ > Gnupg-users mailing list > [email protected] > https://lists.gnupg.org/mailman/listinfo/gnupg-users > _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users