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