On Wed, Dec 20, 2017 at 03:37:46PM +0000, Peter Gutmann wrote:
> The reason I ask is a combination of two things, firstly I've done timing
> measurements on my own code to try and detect differences in behaviour and
> couldn't find anything among the general noise of code execution, and secondly
> any constant-time code is a tradeoff between readability/auditability and
> (near) constant-time operation ("near" because you have no control over what a
> compiler will do to optimise your code, so it may not be anywhere near
> constant-time once it's in binary form). Something like
> s2n_constant_time_copy_or_dont() is barely passable, but I've seen constant-
> time PKCS #1 decoding and similar that's essentially incomprehensible, there's
> no way to look at it and see that it's correct.
Just for fun I tried to implement decoding raw decrypted PKCS#1 encoded
RSA premaster secret and then checking the finished MAC. In way not
vulernable to ROBOT.
I started with code already implementing (EC)DHE key derivation and
finished check. It was like 25-30 (depends on how one counts) lines of
(not very hairy) code to implement, including modifications to existing
code. And this was without any fancy libraries (including random number
generation). Of course, just removing static RSA is much easier way
of eliminate ROBOT.
I never hooked it up to TLS proper, because that would have been
hundreds of lines of code at the very least. Plus, the code is not
up to my quality standards to publish, even as a hack (ocassionally
absolutely incredible things make to "production").
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
