<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 7/10/25 08:19, Werner Koch wrote:<br>
</div>
<blockquote type="cite" cite="mid:87v7o0yyih.fsf@jacob.g10code.de">
<pre wrap="" class="moz-quote-pre">On Thu, 10 Jul 2025 12:41, Guido Trentalancia said:
</pre>
<pre wrap="" class="moz-quote-pre">[...]
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">2017, leaving the program vulnerable to data leaks for about 8 years !
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">It is not the gpg or actually gpg-agent process which leaks the data but
it is a properly of the CPU. If you can mount such an attack on highly
sensitive data, that CPU might not be the right rig for you. In
particular I would strongly advise not to process such secrets on a VM.</pre>
</blockquote>
<span style="white-space: pre-wrap">
</span>
<p><span style="white-space: pre-wrap">I will elaborate on this a bit and explain a few details of the GnuPG security model as it was explained to me:</span></p>
<p><span style="white-space: pre-wrap">GnuPG is designed to run on general-purpose computers. These machines are known to have a wide variety of side channels, some (such as timing) which can potentially leak information remotely, and others (such as speculative execution screw-ups or power analysis) that can only be received locally or with physical access.</span></p>
<p><span style="white-space: pre-wrap">Generally, GnuPG does not consider local side channels to be in-scope for its security model, as there are countless ways for Mallory to make off with your key if he can get that close in the first place. Note that Mallory, in the cryptographic sense, may be an otherwise trusted party, such as the administration of a cloud VM hosting service.</span></p>
<p><span style="white-space: pre-wrap">A potential leak to another program on the user's own computer is not really a concern, since running malware on the user's computer is expected to permit Mallory to simply steal the key file and keylog the passphrase, or equivalently, abuse the user's token while it is connected for the user to use, having keylogged the token PIN.</span></p>
<p><span style="white-space: pre-wrap">Either way, the outcome is the same: Mallory is able to decrypt or sign a message using the user's key, which is catastrophic failure whether Mallory actually gets a copy of the private key to further abuse later or not.
</span></p>
<blockquote type="cite" cite="mid:87v7o0yyih.fsf@jacob.g10code.de">
<pre wrap="" class="moz-quote-pre">I would suggest to implement the whole stuff in the run-time loader and
provide a way to configure which processes should do this. This way
users can decide whether it is worth to disable these CPU-(mis)features
mitigations.</pre>
</blockquote>
<p>Werner Koch is describing a way to solve this system-wide that
would have the likely side-effect of motivating developers to
minimize the scope of processes that handle sensitive keys, since
those processes would have reduced performance.</p>
<p><br>
</p>
<p>-- Jacob</p>
<br>
</body>
</html>