<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 31/03/2026 17:09, Hakun_the_eril via Gnupg-users wrote:<br>
<blockquote type="cite"
cite="mid:CACnSDUtE6gJ_FjfbUY=FHkEz-5K4dYfKWLJzdNUZCPe4T5WiVw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">
<div>
<div>Oh I was not aware of that. <br>
<br>
</div>
<div>My arguments are:</div>
Shamirs secret has been around since 1979,- I find it odd that
it is not included in Openpgp.<br>
</div>
</div>
</blockquote>
<tt>You mean "secret sharing scheme", not any of the other things he
made that <br>
deals with secrets?</tt><br>
<br>
<blockquote type="cite"
cite="mid:CACnSDUtE6gJ_FjfbUY=FHkEz-5K4dYfKWLJzdNUZCPe4T5WiVw@mail.gmail.com">
<div dir="ltr">
<div>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. <br>
</div>
<div>That would cause issues for any organization. It could
also fix the plausible "only one person knows the password" to
a " K of N can cooperate" situation. <br>
</div>
<div>That would also work for a encrypted file system,- split
into parts. <br>
</div>
<div>If a hardware token has , say 256 GB space.. Then it can be
a part of a Shamirs secret scheme. 4 out of 6 keys could be
used to recreate the shared encrypted file system on a empty
drive.</div>
</div>
</blockquote>
<tt>Copying the deeply protected secret stuff to a plaintext copy on
a device with <br>
unknown deletion abilities is a clear security risk that should
not be taken. <br>
Instead create an intermediary layer that extracts the secret key
from the <br>
sharing scheme and keeps it in memory just long enough to access
the actual <br>
secret data (such as PGP private keys) on the fly.</tt><tt><br>
</tt>
<blockquote type="cite"
cite="mid:CACnSDUtE6gJ_FjfbUY=FHkEz-5K4dYfKWLJzdNUZCPe4T5WiVw@mail.gmail.com">
<div dir="ltr">
<div><br>
<br>
</div>
<div>Ephemeral signed elliptic curve diffie hellman is usable,
because it will solve a forward security issue.<br>
</div>
<div>If you encrypt say radio transmissions with the same key
over long periods anyone who gets hold of that key can decrypt
old transmissions. <br>
</div>
<div>TLS 1.3 , the signal protocol and versions of openssh that
is never than 5.7 supports this.</div>
</div>
</blockquote>
<tt>Ephemeral DH (classic or ECC) only works if the recipient can
send you <br>
an ephemeral public key, thus not on any one-way channel such as <br>
broadcast radio, e-mail, messages for the future etc. etc.<br>
<br>
Signing the keys makes sense only if there is a risk that an
attacker <br>
sends you a different key, which there often is, but it is not a
given,<br>
since some means will eventually be needed to establish trust in
the <br>
party whose key you need to trust.<br>
<br>
</tt>
<blockquote type="cite"
cite="mid:CACnSDUtE6gJ_FjfbUY=FHkEz-5K4dYfKWLJzdNUZCPe4T5WiVw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
I have no business relations with Baochip,- I just think its
interesting and neat.<br>
<br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">tir. 31. mars 2026 kl. 16:27
skrev Robert J. Hansen via Gnupg-users <<a
href="mailto:gnupg-users@gnupg.org" moz-do-not-send="true">gnupg-users@gnupg.org</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hakun,
this list overwhelmingly prefers plain text, not HTML. Some
list <br>
members (including Werner!) simply don't read HTML-composed
emails. And <br>
sometimes, HTML emails render in a format that makes it
impossible to read.<br>
<br>
> As the Baochip-x1 has the hardware to do a lot of
cryptographic <br>
> functions like active zeroisation, Ed25519 signed boot,
Glitch sensors, <br>
> security mesh, PV sensor, ECC-protected
RAM,Algorithm-agnostic engine <br>
> etc I think that these could be added to standards.<br>
<br>
Why?<br>
<br>
That's the basic question here. What is the use case for
LibrePGP that <br>
isn't being adequately addressed by the spec, and how would
these <br>
changes mitigate that shortcoming?<br>
<br>
If you can give a good and terse answer to that question I'll
be happy <br>
to consider this proposal.<br>
<br>
> The baochips specs can be found here: <a
href="https://www.baochip.com/" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://www.baochip.com/</a><br>
<br>
Do you have any business relationship to this vendor?</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded</pre>
</body>
</html>