Side-channel vulnerability in libgcrypt - the Marvin Attack

NIIBE Yutaka gniibe at fsij.org
Fri Mar 22 00:51:06 CET 2024


Hello,

Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
> Otherwise, a non-standard malicious host could "bend" the slot timing
> enough that the fixed response delay is not always sufficient for the
> operation to complete.

True.  Thank you for showing this possibility.  I didn't consider this
point.


Well, in general, I suggest not keeping a USB token inserted into a host.

There are possibilities (in theory, or in history) that a decryption
service by a USB token might be providing a decryption oracle to an
attacker by some channel(s).

When a user has a practice of only powering the device when needed,
bandwidth to an attacker could be small, hopefully small enough.  Slower
service is better too, for smaller bandwidth.

It is a bit off-topic (from the original report).  Sorry, It was me who
addressed USB communication.

And... yes, it's true that it's hard for programming to estimate
worst-case running time, it's also hard to guarantee constant-time
running time, in a given situation of programming environment and
hardware architecture.

For me, the question is how we can live with that.
-- 



More information about the Gcrypt-devel mailing list