On 26 February 2012 14:21, Ondrej Mikle <[email protected]> wrote: > I've just found an article about the OAEP padding oracle (that I couldn't > recall > before): > > http://ritter.vg/blog-mangers_oracle.html > > Reportedly there is no major implementation that would suffer from error > side-channel, although there is an interesting experiment with timing > side-channel.
Hey that's me! An error-based side channel does seem to prevented in all libraries, and I got a good timing side channel out of libgcrypt - but smaller timing side channels may be present in others. Pascal Junod shows that even OpenSSL that tried to prevent this attack specifically may be vulnerable to a timing side channel on local or embedded systems: http://crypto.junod.info/hashdays10_talk.pdf because it uses a very short branch (slide 59 abouts). On 26 February 2012 22:25, Peter Gutmann <[email protected]> wrote: > Ondrej Mikle <[email protected]> writes: > >>I've just found an article about the OAEP padding oracle (that I couldn't >>recall before): > > There's another one that was published about a year ago that looks at things > like side-channel attacks via the integer-to-octet-string conversion > primitives and other really low-bandwidth channels, I think it was "Manger's > Attack Revisited". At the time I was thinking of doing a writeup on > generalised > defences (via randomisation) against this sort of thing because as Revisited > points out, you're always going to get timing channels somewhere if you look > hard enough and a generalised defence would be better than the penetrate-and- > patch approah to stopping timing channels. Interesting, this appears to be it: http://www.cdc.informatik.tu-darmstadt.de/reports/reports/mangers_attack_revisited.pdf -tom _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
