Re: [Cfrg] Security proofs v DH backdoors

[Peter Gutmann <[e-mail]>]

Michael Scott <[e-mail]> writes:

>Its dead simple really (so surely must be a miscommunication). For example
>you said that "any fault of any kind inevitably ends up leaking the private
>key". This is a technical group, so I expected that this was not some
>rhetorical flourish, but you meant exactly what you said. In hindsight (and
>here is the miscommunication) it probably was meant as a rhetorical flourish.

Yeah, it was just general complaining about the brittleness of ECC (and some
of the other mechanisms it's used with).  At one end of the scale you've got
some pretty bulletproof/abuseproof modes, CBC with HMAC and -PSK, to which you
can do almost anything and mostly just end up with data corruption
(pathological worst-case with CBC, if you memset() the IV to all-zeroes on
each block, is degradation to ECB), while at the other end of the scale you
have ECC + AES-GCM, a simple fault in the RNG (so repeated k, repeated
counter) means you lose the ECC private key, confidentiality, and integrity-
protection, all in one go.

>A beginner reading that comment might assume that all they have to do is
>induce any fault at all anywhere in an ECC binary, and out will pop the
>private key. So no reverse engineering required to determine where to induce
>the fault, just whack it anywhere.

I think they're probably going to realise it's not as simple as that :-).

>In my experience the vast majority of "any faults" just cause the program to
>rather boringly crash, not revealing nothing to nobody.

If there's a fault and it's unhandled, the watchdog restarts the system.  In
fact that's a standard error-handling strategy, fail-fast, go into an endless
loop until the watchdog restarts the system and the error is cleared.

Peter.