security model

[Jacob Bachmeyer]

On 7/12/25 10:09, Steffen Nurpmeso wrote:
> Jacob Bachmeyer via Gnupg-devel wrote in
>   <e2835c3e-f736-49e9-844b-ff78ad36ab5b at 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