[PATCH gnupg v12] Disable CPU speculation-related misfeatures

[Jacob Bachmeyer]

On 7/10/25 08:19, Werner Koch wrote:
> On Thu, 10 Jul 2025 12:41, Guido Trentalancia said:
> [...]
>> 2017, leaving the program vulnerable to data leaks for about 8 years !
> 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.

I will elaborate on this a bit and explain a few details of the GnuPG 
security model as it was explained to me:

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.

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.

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.

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.

> 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.

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.


-- Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250710/909217bd/attachment-0001.html>