Suggestions of standards added to openpgp/Gnupg/LibrePgp

Hakun_the_eril hakuntheeril at gmail.com
Tue Mar 31 22:18:01 CEST 2026


Problems and pitfalls can be solved.


tir. 31. mars 2026, 18:36 skrev Andrew Gallagher via Gnupg-users <
gnupg-users at gnupg.org>:

> 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
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260331/e107a504/attachment-0001.html>


More information about the Gnupg-users mailing list