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