Re: [Cfrg] Dual_EC_DRBG ... [was RE: Requesting removal of CFRG co-chair]

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Adam Back [mailto:[e-mail]]
> Sent: Friday, December 27, 2013 2:09 PM
> 
> Dan Brown wrote:
> > [...]
> > 8. All considered, I don't see how the ANSI and NIST standards for
> > Dual_EC_DRBG can be viewed as a subverted standard, per se.
> 
> Of course they're subverted.   

> We have Ferguson et al show how they could
> be backdoored.  
 
Repeating myself, nobody showed how the alternative P&Q could be backdoored.

 
In other words, even if subversion were attempted, it was effectively caught
and thwarted, at least in 800-90A and X9.82-3, by two things: (a) the
alternative points, and (b) the highly publicized potential backdoor.  Of
course, (b) is outside the standard, which is why I referred to naïve and
malicious implmenters.

Arguably, the specs do not do enough to warn naïve implementers of the
backdoor.  So, I went back to look at SP 800-90A.

Section 10.3.1, first paragraph states that Dual_EC_DRBG depends on it hard
to find a such that Q=aP.  On the same page, Figure 13 outlines the
Dual_EC_DRBG, using the same notation P and Q.

So, even if a naïve implementer hadn't heard of Ferguson et al., these two
parts of the spec together spell out to the implementer the need to ensure
that a is secret, no?

In other words, the specs are fairly clear to a thorough implementer.  

I admit that the specs could be made even clearer: they could have said that
there is a potential "backdoor".  

I would even want them to clearer. 

> We have internal NSA documents reported as talking about
> the subversion.  
 
Reported, yes.  But AFAIK, not published.

> We have confirmation of RSA (inadvertently or not)
> accepting money to put a EC_DRBG as a default.  

My conclusion was regarding the standards, per se, not about
implementations. I was not drawing any conclusions about implementations.

> You yourself just said the
> validation labs are demanding the backdoored P & Q be used (and rejecting
> the provably uncooked implemented chosen parameters presumably).  

 Yes, I should clarify, I was referring to the NIST SP 800 90A and ANSI
X9.82-4 as not being subverted.  I am only vaguely familiar with CAVP and
CMVP, and was not drawing any conclusions about them.  Aside: I do not deals
with labs personally, so have nothing to say about them.

> NIST
> put the standard forward (inadvertently or not) from NSA input.

Hmm, I'm biased towards to mainly looking at documents in a context-free
manner: i.e. what they say, not who is saying it.  The way I read the specs,
nothing is being is hidden.  
 
> I am non-plussed at what you could be trying to say with the above
> statement.
 
Hope my response helps you.  

I am anticipating it is too narrow.

I am a bit perplexed too: I see many statements about Dual_EC_DRBG that seem
too broad.  

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.