On 7/12/25 10:09, Steffen Nurpmeso wrote:
Jacob Bachmeyer via Gnupg-devel wrote in
<e2835c3e-f736-49e9-844b-ff78ad36a...@gmail.com>:
|On 7/11/25 04:34, Robert J. Hansen via Gnupg-devel wrote:
|>> But many side channels, such as those arising from speculative
|>> execution, are observable by an unpriviliged third party user of a VM
|>> host (and not just cloud, on-prem is no different in principle).
|>
|> Sorry to jump in here, but for 25 years I've told people "only run GnuPG
|> on hardware you control." That also applies if your underlying hardware
|> is a virtualized environment.
|>
|> I side with Jacob here. Once Mallory has access to your hardware, it's
|> game over.
|
|Thank you.
...
|The catch is that the "juicy" stuff is typically *in* the user's account
|on a single-user box... and therefore accessible without elevation if
|Mallory is hitting the client.
...
I have no idea of further gnupg internals, but OpenSSH since some
time "shield"s data in memory; ie the stuff gets encrypted -- only
short time decrypted -- when actually needed. Iirc this was
implemented as a countermeasure against side-channel exposures.
(Ie random key->checksum->used as key to encrypt key data; random
key and encrypted key ptrs stored side-by-side in memory.)
For RSA at least, (and I think other public key cryptosystems) it is
possible to "blind" the calculation such that side channels will leak a
value dependent on both the private key and the random blinding factor;
the latter changes with each operation, thus rendering any side channel
that fails to leak the entire key in a single operation useless to an
attacker.
Efforts to implement blinding for all supported cryptosystems would
probably be far better uses of available resources than playing side
channel whack-a-mole.
-- Jacob
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
