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

Dan Brown <dbrown@certicom.com> Fri, 27 December 2013 23:35 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35C31AE90F for <cfrg@ietfa.amsl.com>; Fri, 27 Dec 2013 15:35:01 -0800 (PST)
X-Quarantine-ID: <o6gT0EZb5ZD4>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6gT0EZb5ZD4 for <cfrg@ietfa.amsl.com>; Fri, 27 Dec 2013 15:35:00 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF831AE90D for <cfrg@irtf.org>; Fri, 27 Dec 2013 15:34:58 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============1285762031=="
MIME-Version: 1.0
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Dec 2013 18:34:48 -0500
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Dec 2013 18:34:48 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0158.001; Fri, 27 Dec 2013 18:34:48 -0500
From: Dan Brown <dbrown@certicom.com>
To: "'dharkins@lounge.org'" <dharkins@lounge.org>, "'mcgrew@cisco.com'" <mcgrew@cisco.com>
Thread-Topic: [Cfrg] Dual_EC_DRBG ... [was RE: Requesting removal of CFRG co-chair]
Thread-Index: AQHPA00Ch315veUHX0690/db6dPF85poqTpQ
Date: Fri, 27 Dec 2013 23:34:46 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5C18883@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5C18718@XMB116CNC.rim.net> <52BDF443.6080304@cisco.com> <3c96bfce5622182ffcad22267d37aaa4.squirrel@www.trepanning.net>
In-Reply-To: <3c96bfce5622182ffcad22267d37aaa4.squirrel@www.trepanning.net>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
MIME-Version: 1.0
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: Re: [Cfrg] Dual_EC_DRBG ... [was RE: Requesting removal of CFRG co-chair]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Dec 2013 23:35:02 -0000


> -----Original Message-----
> From: Dan Harkins
> Sent: Friday, December 27, 2013 4:46 PM
>
> On Fri, December 27, 2013 1:42 pm, David McGrew wrote:
> > I understand that these topics deserve discussion, but in the long
> > term it might be more fruitful to consider what recommendations should
> > be given to implementers and standards group on the subject of PRNGs.

Yes, I just wanted to clarify.   

Now, since you asked about recommendations ...

PRNGs are not needed for interoperability, but the some of the core
"schemes" standards that I am familiar with, such as ANSI X9.62 and SEC1,
make normative requirements about the PRNGs and entropy used to generate
keys.  I think that's reasonable for the sake of security.  In theory, if
IETF "protocols" specs reference these core "schemes" standards, then they
would inherit the PRNG requirements.  I'd recommend IETF "schemes" specs
similarly follow suit, although an alternative is just to require a (secure)
randomly generated key, but that could be little risky to ask implementers
to do this without sufficient guidance.

Maybe I'm biased, but for a PRNG, I'd recommend Dual_EC_DRBG with
alternative P&Q, at least on systems that can afford the extra latency, e.g.
high-end user equipment, if only because of the refereed security analysis.
Also, considerable attention, because of the potential backdoor, has been
paid to Dual_EC_DRBG, yet no major attack since that security analysis has
been uncovered.

The three other DRBG algorithms now in SP 800-90 should be much faster, if
such speed is needed, and should also be secure, since no major attacks have
been published, despite their high profile in NIST specs.  The HMAC_DRBG
also has a proof.

I'm also aware of other research into comparable alternatives:

http://eprint.iacr.org/2013/338
http://eprint.iacr.org/2005/029

but I'm not sure if these have been standardized anywhere.  If I had to
summarize these in a few words, I would hazard to say that they provide
constructions to build a PRNG from a PRF (where for a PRF, think RC4, or
AES-CTR).

There's also lots of research into "randomness extractors", but that's
something slight different.


> 
>   Indeed! And might this discussion move to dsfjdssdfsd@ietf.org, the
mailing
> list formed to discuss just this very subject?
> 

Thanks. I completely forgot about that mailing list, I saw the announcement
but never looked into it.  Is there a WG site?

Best regards,

Dan
---------------------------------------------------------------------
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.