Hello, Jacob Bachmeyer <jcb62...@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. -- _______________________________________________ Gcrypt-devel mailing list Gcrypt-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
