Re: [Cfrg] Security proofs v DH backdoors

hi Peter,

On Oct 31, 2016, at 10:13 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

> Michael Scott <mike.scott@miracl.com> 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.

isn’t this a consequence of the reuse of GCM n-once rather than ECC fault?

regards

antonio

> 
>> 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.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg