Side-channel vulnerability in libgcrypt - the Marvin Attack

Hubert Kario hkario at
Wed Mar 20 14:18:28 CET 2024

On Wednesday, 20 March 2024 02:44:51 CET, Jacob Bachmeyer wrote:
> Hubert Kario via Gcrypt-devel wrote:
>> On Saturday, 16 March 2024 00:43:58 CET, NIIBE Yutaka wrote: ...
> The method to harden a USB device against this type of attack 
> is to work out the worst-case computation time, and always hold 
> the response until that time (measured in USB time slots) has 
> elapsed.  To use numbers from your example, the device performs 
> the operation, completing it in 18 to 22 time slots, but holds 
> the response until 24 time slots have elapsed from the request.
> This of course requires actually knowing how your program works 
> and its worst-case running time, which sadly is probably rare in 
> modern commercial programming.
> The device also must guard against a malicious host by having 
> its own clock (which is needed for its processor and USB 
> interface anyway) and shutting down if the time slots it sees on 
> the bus do not align with the USB spec.  (If I remember 
> correctly, the USB spec requires each time slot to be some 
> number of milliseconds, but the USB host determines the precise 
> timing.)  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.

IIUC, there are ways to do polling more often... some gaming mice advertise
that as a feature.

But, yes, if there is no differentiation in the reply times, or they don't
depend on the secret data, then you will fix the timing side-channel.
It should be noted that this will protect only against timing

There are other side-channels, like sound:
or power related (using remote CCTV cameras):

Fixing it so that the timing of the actual operation is actually 
of secret data is a first step in fixing the power side channels.

Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

More information about the Gcrypt-devel mailing list