<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>Dear GPG/PGP designers.</tt><br>
<tt><br>
</tt><tt>Note that besides the highly advanced post-quantum
algorithms promoted in <br>
recent years, there is also Merkle's hash tree signing algorithm,
which <br>
uses solid security arguments from the properties of good hash
algorithms. <br>
Two variants of this have been published as RFCs differing mostly
in <br>
padding details.<br>
<br>
While this is purely a signature algorithm and each signature is
several <br>
kilobytes big (hashbits**2 / w / 8 plus the extra hash values for
carry <br>
bits, plus the hashbits * log2(sigcount) / 8 path to the tree
root), <br>
the public key is just a single hash value and the private key is
either <br>
a large one-time-pad or a symmetric key for a strong enough stream
<br>
cipher. Given the theory that quantum attacks halve the strength
of <br>
hash functions and other symmetric algorithms, and the theory that
hash <br>
algorithms have the equivalent symmetric strength of hashbits / 2,
<br>
Merkle-tree algorithms should be hash algorithm agile and use a
hash <br>
algorithm with hashbits >= 4 * desired-strength. Thus 128-bit
<br>
equivalent strength would need a 512 bit hash algorithm and a 256
bit <br>
stream cipher; Double for 256-bit strength.</tt><tt><br>
</tt><tt><br>
</tt><tt>For example an addition to OpenPGP can reference one of the
2 RFCs, <br>
specify w=8 </tt><tt>and make the hash algorithm a separate part
of the algorithm <br>
indication in public </tt><tt>keys, while a corresponding GPG
implementation can <br>
then be parameterized by a </tt><tt>reference to the entire list
of implemented <br>
hash algorithms >= 256 bits (to verify </tt><tt>all
spec-compliant signatures) <br>
while using one or two very strong stream ciphers </tt><tt>for
the private key <br>
storage format (making stream and hash algs user choices </tt><tt>during
key <br>
generation). Tree height would be dictated by a need to leave one
</tt><br>
<tt>signing invocation available to sign a new public key, one to
sign <br>
self revocation </tt><tt>and a few others for similar tasks, then
at least 1 <br>
usable signing invocation for </tt><tt>signing an actual mail or
software <br>
release.</tt><tt><br>
</tt><tt><br>
</tt>
<div class="moz-cite-prefix"><tt>On 06/04/2026 21:54, Robert J.
Hansen via Gnupg-users wrote:</tt><br>
</div>
<blockquote type="cite"
cite="mid:9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org">As
many people on this list know, I have for a very long time been a
skeptic on the subject of quantum computing advances. I won't go
into details, but the bottom line is there are three pillars on
which I have set my projections and this week it looks as if two
of them are beginning to crack. <br>
<br>
It is probably wise to begin deploying post-quantum cryptography.
Are there any plans in GnuPG to make post-quantum algorithms the
default for new certificates? <br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gnupg-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnupg-users@gnupg.org">Gnupg-users@gnupg.org</a>
<a class="moz-txt-link-freetext" href="https://lists.gnupg.org/mailman/listinfo/gnupg-users">https://lists.gnupg.org/mailman/listinfo/gnupg-users</a>
</pre>
</blockquote>
<br>
<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>