From stephen.farrell@cs.tcd.ie Tue Nov 12 16:43:32 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F721E80AA for ; Tue, 12 Nov 2013 16:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.294 X-Spam-Level: X-Spam-Status: No, score=-101.294 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugCNVbFnB22p for ; Tue, 12 Nov 2013 16:43:26 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0A49621F9C00 for ; Tue, 12 Nov 2013 16:43:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91B98BE6E for ; Wed, 13 Nov 2013 00:42:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqKx69VPb9d2 for ; Wed, 13 Nov 2013 00:42:56 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.75.204]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B87CEBE2F for ; Wed, 13 Nov 2013 00:42:56 +0000 (GMT) Message-ID: <5282CB10.9010707@cs.tcd.ie> Date: Wed, 13 Nov 2013 00:42:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dsfjdssdfsd@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dsfjdssdfsd] test X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 00:43:32 -0000 test From d3e3e3@gmail.com Tue Nov 12 16:45:35 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28911E8155 for ; Tue, 12 Nov 2013 16:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3grfLPIcuxqR for ; Tue, 12 Nov 2013 16:45:34 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5121E80AA for ; Tue, 12 Nov 2013 16:45:34 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so6936488obc.34 for ; Tue, 12 Nov 2013 16:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=FRiZkELfvfPZNDb9F7IG/vA9Zc1UXXsUglSM8uaD0FA=; b=q+ad45z6wtiY38xuHpxnVGUCAp/h+VUYC4wep/iHU942b+/2EG4MbkpVxilCQKcv/Y RJ2lUgGN+qjoI0nbE3IfATNPYpVDZc4dCZet52mDYBgFydDJ6dadPW0durEyIHpp0MGK GQ45mmvGWp/s/7Xusewo9zI2iuaamChNywKjb9cBW1lpRwjhz5kABMPuz3CG5a6WdkMc mNL3mszCKE1GDVejQ9ssxSUW8kD4H1o9Z3ShvwoIZkrpccgbxgjrGTrXG9pjws10KFSY 5k7lt687WMM8wKjO0a5PaFdIEstq3udrcZtKMKrnEESAPZ/Yf/pr9UhNZq0XL4HrUJWh 6WPg== X-Received: by 10.60.56.42 with SMTP id x10mr3873674oep.95.1384303533613; Tue, 12 Nov 2013 16:45:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Tue, 12 Nov 2013 16:45:13 -0800 (PST) In-Reply-To: <5282CB10.9010707@cs.tcd.ie> References: <5282CB10.9010707@cs.tcd.ie> From: Donald Eastlake Date: Tue, 12 Nov 2013 19:45:13 -0500 Message-ID: To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dsfjdssdfsd] test X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 00:45:35 -0000 I got it. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Nov 12, 2013 at 7:42 PM, Stephen Farrell wrote: > > test > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From dharkins@lounge.org Tue Nov 12 17:41:06 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CD011E816D for ; Tue, 12 Nov 2013 17:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRcojhPq0JNb for ; Tue, 12 Nov 2013 17:41:02 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1710A11E8163 for ; Tue, 12 Nov 2013 17:41:02 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8BF57A888120; Tue, 12 Nov 2013 17:41:01 -0800 (PST) Received: from 216.1.225.2 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 12 Nov 2013 17:41:01 -0800 (PST) Message-ID: In-Reply-To: <5282CB10.9010707@cs.tcd.ie> References: <5282CB10.9010707@cs.tcd.ie> Date: Tue, 12 Nov 2013 17:41:01 -0800 (PST) From: "Dan Harkins" To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] test X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 01:41:06 -0000 aoi1svbnu50riyfgw8aew0h57av On Tue, November 12, 2013 4:42 pm, Stephen Farrell wrote: > > test > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > From ietf-secretariat@ietf.org Wed Nov 13 13:58:22 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF24021E811A; Wed, 13 Nov 2013 13:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bOEC62igaRQ; Wed, 13 Nov 2013 13:58:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BE011E8150; Wed, 13 Nov 2013 13:58:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> Date: Wed, 13 Nov 2013 13:58:22 -0800 Cc: dsfjdssdfsd@ietf.org, dharkins@lounge.org, paul.hoffman@vpnc.org Subject: [dsfjdssdfsd] New Non-WG Mailing List: dsfjdssdfsd X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:58:22 -0000 A new IETF non-working group email list has been created. List address: dsfjdssdfsd@ietf.org Archive: http://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/maillist.= html To subscribe: https://www.ietf.org/mailman/listinfo/dsfjdssdfsd Purpose: The dsfjdssdfsd list provides a venue for discussion of randomness= in IETF protocols, for example related to updating RFC 4086. For additional information, please contact the list administrators. From dharkins@lounge.org Thu Nov 14 21:55:37 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D617E11E810A for ; Thu, 14 Nov 2013 21:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwm4446a-T7d for ; Thu, 14 Nov 2013 21:55:32 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id CA3CA11E8109 for ; Thu, 14 Nov 2013 21:55:29 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B8E5B10224008 for ; Thu, 14 Nov 2013 21:55:28 -0800 (PST) Received: from 67.110.83.252 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 14 Nov 2013 21:55:28 -0800 (PST) Message-ID: Date: Thu, 14 Nov 2013 21:55:28 -0800 (PST) From: "Dan Harkins" To: dsfjdssdfsd@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 05:55:37 -0000 Hello, and welcome to the dsfjdssdfsd list! At the last IETF the question was asked, "what can we do to harden the Internet?" Given the recent news about Dual_EC_DBRG and the dopant attack against hardware RNGs one of the things that can be done is to have an open specification of a secure RNG. This would allow developers to have an alternative to relying solely on /dev/[u]random, a hardware RNG, an RNG specified by a large government-affiliated group to mix the uncorrelated sources of entropy they gather, or an RNG designed in an ad hoc manner by someone who thinks he knows what he's doing but probably doesn't. One of the things that would be nice to get out of this list is a specification on a strong RNG, in the form of a BCP or Informational RFC. This doesn't necessarily mean lets "roll our own" but perhaps there is best practice that can be specified. So, is there a model that defines what a "robust RNG" would look like? Is there a suitable candidate that exists already for such a thing? regards, Dan. From eburger@standardstrack.com Fri Nov 15 02:56:11 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8BE11E8189 for ; Fri, 15 Nov 2013 02:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaBuX9kiYztX for ; Fri, 15 Nov 2013 02:56:00 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id B387C11E8181 for ; Fri, 15 Nov 2013 02:55:53 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:54085 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VhH3u-0005TZ-FV for dsfjdssdfsd@ietf.org; Fri, 15 Nov 2013 02:55:46 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_2B314021-F047-4117-94EA-8704DB73B08A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Eric Burger X-Priority: 3 (Normal) In-Reply-To: Date: Fri, 15 Nov 2013 05:55:39 -0500 Message-Id: <49FF9BED-3844-4D15-8F84-6E7231FE0892@standardstrack.com> References: To: dsfjdssdfsd@ietf.org X-Mailer: Apple Mail (2.1822) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 10:56:11 -0000 --Apple-Mail=_2B314021-F047-4117-94EA-8704DB73B08A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 15, 2013, at 12:55 AM, Dan Harkins wrote: > Hello, and welcome to the dsfjdssdfsd list! >=20 > At the last IETF the question was asked, "what can we do to harden > the Internet?" Given the recent news about Dual_EC_DBRG and the > dopant attack against hardware RNGs one of the things that can be > done is to have an open specification of a secure RNG. I like this idea. > This would > allow developers to have an alternative to relying solely on > /dev/[u]random, a hardware RNG, an RNG specified by a large > government-affiliated group to mix the uncorrelated sources of > entropy they gather, or an RNG designed in an ad hoc manner by > someone who thinks he knows what he's doing but probably > doesn=92t. History is nice, but if we produce a *standard*, one would hope the = developer goes to /dev/IETFrandom. I.e., none of the issues listed above = are relevant. > One of the things that would be nice to get out of this list is a > specification on a strong RNG, in the form of a BCP or Informational > RFC. This doesn't necessarily mean lets "roll our own" but perhaps > there is best practice that can be specified. How is this any different than today=92s practice? Today we point to = NIST, FIPS, NSA, RSA, ISO, Government Committee of the Russia for = Standards, etc. > So, is there a model that defines what a "robust RNG" would look > like? Is there a suitable candidate that exists already for such a = thing? I am still having trouble understanding what would be different than = what we do today. If you are proposing something akin to the open source = codec work, then I am only just a bit skeptical, but I was proven wrong = by that effort (it seems to be succeeding). However, if all we are doing = is looking for a RNG to put into IETF standards, then are we not doing = that already? --Apple-Mail=_2B314021-F047-4117-94EA-8704DB73B08A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJShf2sAAoJEORoZaSQsc1IHWwP/RUYi0jA3SwxDEQbfbi23UPo XtI8UEP/0qB4WMIpJR6Rua/lrXTAPNMbrvWWblDuYykZQgSY/aXTXXp4wJKDuI+L dEyzDqEIrF3u+9iUMprWs2/2PmMDIDZGDGu1ukFxmzgvMl9w8qo69X1TZx08sf/A hs6uAx+cGMlyvZyCK1B6JPSMr71KMDkLNBj3757eumbZK5BBqTv2mYLwWTRG/vOy faIxjhlLg6ytYBUQAWx11FFyQ04kDwAqrEKismkF6KtG3Ns3yd+jovXgjuhJMc73 VNKslQkmo4MJ6JMXimpvCuLetXyXtQ5Fq2XIz0kdMF1hnkvXTgnGd3ZMNcMNdL/T a1p5/XIk5OmulKP4cnsHte8roeO+EixExekauz4GzA2oo1DxGydXCxMltgaPoWBO Y2+lx3r6fgi424iKiUdfLQItxxPC0EsFNfRswXvburxf1BoXl9ZsQNfBTkTz9wC7 UryCiYY2Ac6AXfpSY9WD6FtP7YYjtUYpvwf+bzzUHG0lmCHeeR25OiLk1+yCrTyC M92nLv3fiE91UWGDdYU5c6SmPjniRXRlF/BlInjOS2hDFGx/f8D/3WbwOrCBRrHO lx2LSFWZaFSkUSbfU/ikAO2cmGh8WhquuFZnFD/3s1WQbd6x6Y41zmLzvb+W8oTi 1o3K5Szm7fVsxpRu1Dem =9o1T -----END PGP SIGNATURE----- --Apple-Mail=_2B314021-F047-4117-94EA-8704DB73B08A-- From d3e3e3@gmail.com Fri Nov 15 07:11:35 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C950C11E81A5 for ; Fri, 15 Nov 2013 07:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG4n9fUJ1zyx for ; Fri, 15 Nov 2013 07:11:26 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CF54011E80F5 for ; Fri, 15 Nov 2013 07:11:25 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wn1so3990572obc.14 for ; Fri, 15 Nov 2013 07:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ueB9vcKjGGbZGKszYbL8+9EjDTwd+CxW6RYziop7knE=; b=W/H4bh7B7b745XrcQ7It1eesVWU/shJ3rVptzMPRs5lp0Ar24693tBOt8ZCpkK2Ddj IxAhBvV/LnO9jlutN6DzaXOlv1e3IaEWTbQUAv/xG0ZWr/KLVnqII7vo6R86x0sIhh6o 4+c91rovOmVThYUz+2MuJ1PCxE+ADjEjaIULBKDL4USlqhiUMkiaRpNZD3vf9HyOSZAE 6EVRYsoHZj41M5OUOYIXlENv6s4GCIJGwDE8u0X7SCqg/aqCcLv2sUgF2l1SGYo3tnCZ 3oBwDU9UaaMCW3eh++jiyrFBR5BdGldUym0YGmaEeruIikYAeHxey7wX4dcXSky1n3nM q/DA== X-Received: by 10.182.66.78 with SMTP id d14mr1003419obt.99.1384528281318; Fri, 15 Nov 2013 07:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Fri, 15 Nov 2013 07:11:01 -0800 (PST) In-Reply-To: <49FF9BED-3844-4D15-8F84-6E7231FE0892@standardstrack.com> References: <49FF9BED-3844-4D15-8F84-6E7231FE0892@standardstrack.com> From: Donald Eastlake Date: Fri, 15 Nov 2013 10:11:01 -0500 Message-ID: To: dsfjdssdfsd@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1fcac63bda404eb389c31 Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:11:35 -0000 --e89a8fb1fcac63bda404eb389c31 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 15, 2013 at 5:55 AM, Eric Burger wrote: > On Nov 15, 2013, at 12:55 AM, Dan Harkins wrote: >> Hello, and welcome to the dsfjdssdfsd list! >> >> At the last IETF the question was asked, "what can we do to harden >> the Internet?" Given the recent news about Dual_EC_DBRG and the >> dopant attack against hardware RNGs one of the things that can be >> done is to have an open specification of a secure RNG. > > I like this idea. > >> This would >> allow developers to have an alternative to relying solely on >> /dev/[u]random, a hardware RNG, an RNG specified by a large >> government-affiliated group to mix the uncorrelated sources of >> entropy they gather, or an RNG designed in an ad hoc manner by >> someone who thinks he knows what he's doing but probably >> doesn=92t. > > History is nice, but if we produce a *standard*, one would hope the developer goes to /dev/IETFrandom. I.e., none of the issues listed above are relevant. > >> One of the things that would be nice to get out of this list is a >> specification on a strong RNG, in the form of a BCP or Informational >> RFC. This doesn't necessarily mean lets "roll our own" but perhaps >> there is best practice that can be specified. RFC 4086, which is on this topic, is a BCP but is out of date and doesn't recommend a specific random number generator. https://datatracker.ietf.org/doc/draft-eastlake-randomness3/ is the start of an effort towards a replacement but needs a lot of work. By the way, not that I am arguing for or against it for this case, but it is quite possible for a BCP or IETF standard to consist of a set of RFCs=85 Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > How is this any different than today=92s practice? Today we point to NIST= , FIPS, NSA, RSA, ISO, Government Committee of the Russia for Standards, etc. > >> So, is there a model that defines what a "robust RNG" would look >> like? Is there a suitable candidate that exists already for such a thing= ? > > I am still having trouble understanding what would be different than what we do today. If you are proposing something akin to the open source codec work, then I am only just a bit skeptical, but I was proven wrong by that effort (it seems to be succeeding). However, if all we are doing is looking for a RNG to put into IETF standards, then are we not doing that already? --e89a8fb1fcac63bda404eb389c31 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

On Fri, Nov 15, 2013 at 5:55 AM, Eric Burger &l= t;eburger@standardstrack.com<= /a>> wrote:
> On Nov 15, 2013, at 12:55 AM, Dan Harkins <dharkins@lounge.org> wrote:
>> =A0Hello, and welcome to the dsfjdssdfsd list!
>>
>= > =A0At the last IETF the question was asked, "what can we do to ha= rden
>> the Internet?" Given the recent news about Dual_EC_DB= RG and the
>> dopant attack against hardware RNGs one of the things that can be<= br>>> done is to have an open specification of a secure RNG.
><= br>> I like this idea.
>
>> This would
>> allow = developers to have an alternative to relying solely on
>> /dev/[u]random, a hardware RNG, an RNG specified by a large
>= ;> government-affiliated group to mix the uncorrelated sources of
>= ;> entropy they gather, or an RNG designed in an ad hoc manner by
>> someone who thinks he knows what he's doing but probably
&g= t;> doesn=92t.
>
> History is nice, but if we produce a *sta= ndard*, one would hope the developer goes to /dev/IETFrandom. I.e., none of= the issues listed above are relevant.
>
>> =A0One of the things that would be nice to get out of this= list is a
>> specification on a strong RNG, in the form of a BCP = or Informational
>> RFC. This doesn't necessarily mean lets &q= uot;roll our own" but perhaps
>> there is best practice that can be specified.

RFC 4086, whi= ch is on this topic, is a BCP but is out of date and doesn't recommend = a specific random number generator.
https://datatracker.ietf.org/doc/draft= -eastlake-randomness3/
is the start of an effort towards a replacement but needs a lot of work.

By the way, not that I am arguing for or against it = for this case, but it is quite possible for a BCP or IETF standard to consi= st of a set of RFCs=85

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0Donald E. East= lake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford, M= A 01757 USA
=A0d3e= 3e3@gmail.com

> How is this any different than today=92s practice? Toda= y we point to NIST, FIPS, NSA, RSA, ISO, Government Committee of the Russia= for Standards, etc.
>
>> =A0So, is there a model that defin= es what a "robust RNG" would look
>> like? Is there a suitable candidate that exists already for such a= thing?
>
> I am still having trouble understanding what would = be different than what we do today. If you are proposing something akin to = the open source codec work, then I am only just a bit skeptical, but I was = proven wrong by that effort (it seems to be succeeding). However, if all we= are doing is looking for a RNG to put into IETF standards, then are we not= doing that already?

--e89a8fb1fcac63bda404eb389c31-- From nick.a.mathewson@gmail.com Fri Nov 15 08:36:42 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3621F9B4B for ; Fri, 15 Nov 2013 08:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0IFwt4PMtDx for ; Fri, 15 Nov 2013 08:36:38 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76521F9E3F for ; Fri, 15 Nov 2013 08:36:16 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id eh20so2959151lab.32 for ; Fri, 15 Nov 2013 08:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=2FfAXRCIY3OPkk0EbIy8WAxzIhtzwhhCYevzkTH6E1U=; b=Ih4hABs8IBoyZz68M2WYltKgURTjMoXMi2j4TAT5u8tLufHAdI9ojRwrp407fQUW4k gI2Rk3x0KOXiv5k7ad0OQ+493HWvMCw+TeYBS1J2kJUVdhwbGHLtVsoUT2tMAM2fK6M9 LLPxQyam0ARFfx3EnD/CU2FjLAhxc65Q7/+TTFYwj6yvCc48U313JBWgnth9JacaiMcx 5e1GBNNV9nzvRG/ex9+vIly7Uyh78Edt+q/xgRUvQKVhjoYvn+oun2hch2lPwpBal9OP 8+JNVjqZmEb3ICElRI4M8yK2BroDdTrRUV6j1fN+iTbuM0ifcAqgcQjMu43GxoaX4uDM iYrw== MIME-Version: 1.0 X-Received: by 10.152.88.67 with SMTP id be3mr318182lab.67.1384533374858; Fri, 15 Nov 2013 08:36:14 -0800 (PST) Sender: nick.a.mathewson@gmail.com Received: by 10.112.75.165 with HTTP; Fri, 15 Nov 2013 08:36:14 -0800 (PST) Date: Fri, 15 Nov 2013 11:36:14 -0500 X-Google-Sender-Auth: rs9Sb6I2TCTGCFJspTgZCpTt1oI Message-ID: From: Nick Mathewson To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:36:42 -0000 Hi! I thought it might be helpful to enumerate all the RNG failures I'm aware of. There are probably more, and my focus here has been on failures that have actually led to working attacks. See also CWE-330 [0]. Please let me know what I've missed. == What has gone wrong in practice and led to actual working attacks: A. Not actually using randomness at all for something that needs some or all of the properties of a random bitstring. Example: Sony's implementation of ECDSA failed to actually change the k value between signatures; they just had a constant.[1] Example: The SSL CBC weakness that enabled the BEAST attack where, instead of using a new IV for each record, SSL and older TLS versions would use the last record's last block as the IV for the next record. B. Relying on an RNG output for something that doesn't need to be random. Example: Most ECDSA implementations rely on having a strong RNG at signing time. In fact, there are more robust ways to generate an unpredictable value -- for example, by a cryptographic hash of the message, the public key, and a secret value generated at key generation time. See the references in the "Pseudorandom generation or r" section of the Ed25519 paper [2]. Arguably, this is what went wrong with the Android bitcoin problem. (See item G below.) C. The cryptographic function that is produces the RNG output or updates its state is periodic, predictable, or otherwise cryptologically inadequate. Example: Traditional arc4random() implementations: the original RC4 cipher is not only insecure versus modern cryptanalysis [3]; it has actual biases in its output. Example: The core function Dual_EC_DBRG is distinguishable from a random bitstring. Also, it has a backdoor that could not be more obvious if it were a drive-through car wash. D. Using a noncryptographic PRNG when a stronger function is required for security. Example: When reviewing an inexperienced hobbyist's first cryptography software, it's even money you'll find them using (say) Mersenne Twister to generate a keystream. Example: It has been well known for ages that initial TCP sequence numbers need to be unpredictable to prevent various spoofing attacks. Even so, people still used PRNGs with insufficient unpredictability, such as linear congruental generators. The summary at [4] has a list of CVEs for inadequate PRNGs. E. Using an RNG that has been exposed before it can be adequately seeded. Example: Various embedded hardware devices generate private keys on their initial startup. Unfortunately, they tend to do this before they've been able to collect any entropy from sources like HD timings (what's an HD?) network timings (what's a network?) and so forth. This has been one of the causes of a rash of predictable keys, as explored in [5]. F. Disabling some or all of the seed inputs to an RNG. Example: In the Debian OpenSSL PRNG bug [6], maintainers thought that they were disabling a feature that added uninitialized RAM to the PRNG state. Instead, they had accidentally disabled *all* inputs to the PRNG state. (Except for the PID.) Example: One of the reasons that Linux kernels entropy was sometimes low around startup was (If I understand correctly!) that important drivers or subsystems often avoided adding timing information to the kernel entropy pool, for fear it would slow them down. More recent Linux kernels, (again, IIUC) take the responsibility away from the drivers, and use clever implementation hacks to ensure that no performance penalty is felt. G. Using the same RNG state to generate two bitstreams. Example: The SecureRandom structure in Android was initialized once, and then used as the initial SecureRandom for multiple processes. This led to a large compromise in Android bitcoin wallets. [7] Example: Python had the same problem [8]: the same RNG state was used after fork. H. Falling back to insecure sources. Example: Too many supposedly strong RNG libraries have had a fallback to random() if /dev/urandom can't be read. See for example the discussion of Apache Harmony in [9]. I. Implementation errors. Example: Too many to list. See for example the discussion of Apache Harmony in [9], where the implementors thought they had a 128 bit seed, but they only had a 64-bit seed. == What has gone wrong, and is probably bad, but has not (AFAICT) led to any publicized attacks yet: These may well be getting exploited. If you've got documentation on that, please let me know. AA. Backtracking from compromised state BB. Prediction from compromised state It's not necessary that reading an RNG's current state should enable a attacker to learn all previous and future outputs of that RNG. Resisting backtracking attacks is easy. Resisting prediction attacks is a little harder, but permits a not too unattractive performance/security tradeoff. CC. Theoretically unsound pool constructions See for example the recent paper on the Linux /dev/*random devices' constructions [10]. DD. Exclusive reliance on hard-to-audit hardware or software EE. Bad entropy estimation Numerous RNGs rely on each entropy inputs being acccompanied by an estimate of how many bits of entropy each contains. Historically, these entropy estimates have been pretty bogus, but I'm not aware of any attack arising out of that. == Some antipaterns in randomness (Here I am being perhaps too opinionated.) * Exposing under-seeded RNGs. If people can forget to seed an RNG, somebody will. If an RNG can be drained before it has been seeded, it will be. * Strong, fast: pick one. In many cases, the programming environment has provided a strong RNG, but implementors have (erroneously) avoided it either on performance grounds. This is a shame, since there's no reason a strong userspace PRNG can't give performance on par with many of the weak userspace PRNGs people use today. (Shameless plug: [11]) * Strong, reliable: pick one. In some cases, programmers avoid the safer option because they can't rely on it being available, and so use one that might not be as well seeded. (For example, many programmers avoid /dev/random for fear that it might block, while using /dev/urandom, which is on some platforms more likely to return predictable bits near initial system startup.) * Underdocumented, underexplained randomness requirements. Before you sniff too loudly at Sony's mistake in [1]: Pretend that you are a programmer in a hurry looking at FIPS 186-2, or your favorite (early) standards-body description of DSA. How well does it explain the importance of making 'k' completely unpredictable for each message, and how well does it explain the consequences for failing to do so? * Falling back to insecure sources "I couldn't open /dev/urandom. I guess that srandom(getpid() + malloc()) is the best I can do." * Entropy purity taboos This is the converse of DD above. Some implementors refuse to incorporate entropy sources they don't trust into an entropy pool, under the apparent belief that combining a good entropy source with an evil entropy source will produce contaminated entropy. In reality, a good PRNG will survive hostile sources just fine, so long as a sufficient threshold of the entropy inputs are good. * Inadequate testing This is a tremendous problem. Unless the RNG is broken, black-box testing is usually inadequate: an unseeded RNG's output, or an underseeded RNG's output, or a broken RNG's output, will all look. Testing an RNG requires, at minimum; verification that it produces the correct expected outputs given an expected seed, and that it responds correctly to addition of more fixed seeds. [0] http://cwe.mitre.org/data/definitions/330.html [1] http://www.bbc.co.uk/news/technology-12116051 [2] http://ed25519.cr.yp.to/ed25519-20110926.pdf [3] http://www.isg.rhul.ac.uk/tls/ [4] http://www.cert.org/advisories/CA-2001-09.html [5] https://factorable.net/paper.html [6] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166 [7] http://bitcoin.org/en/alert/2013-08-11-android [8] http://bugs.python.org/issue18747 [9] http://hgi.rub.de/media/nds/veroeffentlichungen/2013/03/25/paper_2.pdf [10] http://eprint.iacr.org/2013/338.pdf [11] https://github.com/nmathewson/libottery hoping this was useful, -- Nick Mathewson From stephen.farrell@cs.tcd.ie Fri Nov 15 08:46:18 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87F921F9D5E for ; Fri, 15 Nov 2013 08:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCy59aI6flXs for ; Fri, 15 Nov 2013 08:46:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9E321F9EF4 for ; Fri, 15 Nov 2013 08:46:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 96314BE5B; Fri, 15 Nov 2013 16:46:11 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E1eMl2p9KFa; Fri, 15 Nov 2013 16:46:11 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 760DDBE55; Fri, 15 Nov 2013 16:46:11 +0000 (GMT) Message-ID: <52864FD4.2000104@cs.tcd.ie> Date: Fri, 15 Nov 2013 16:46:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nick Mathewson , dsfjdssdfsd@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:46:18 -0000 On 11/15/2013 04:36 PM, Nick Mathewson wrote: > > hoping this was useful, Very useful IMO, thanks. Its clear that lots of that is stuff that the IETF can't help make better, but I think its all relevant for discussion here. S. From yaronf.ietf@gmail.com Fri Nov 15 09:21:22 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B811E80E0 for ; Fri, 15 Nov 2013 09:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bya8V9XagFcL for ; Fri, 15 Nov 2013 09:21:22 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 373CA21F9D8E for ; Fri, 15 Nov 2013 09:21:22 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so2318567wgh.0 for ; Fri, 15 Nov 2013 09:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B0HRUPfoe9sJdAmycNoAH9OrxglRIMbkNIsjcia3Ag4=; b=LKCRSa36KJ/1AaYF34H4lllveZ1CjCDd55wYe526nPzzPBwm4ZnEh9rRGS/V6pQAqk +jTIFi89tbJTDkFS6Evfrr68uThDLBbWUoYPJ0NLHbBkn5L+NwuUQ7avwM1OJS0zS4K+ feS9UGuWrdCU2Nhdqj9ZAnzvLPUT+UC5KZC0sAUJyWpsEkHkE5JBQkVyNlZ1E3288zTZ 2MMp+Y3h7pH9TigKZ6+H8K0p5PYWyORqM1ZouzkPNVEXinPUW1bLAgegwG1JGL8Civkj pz3oloXSlOjdPE+QyPoBlsfAJMWMkr9EK7JZbuDYpTRa4QIJ7Fx1GltXWSYfE90NQDVB lFAg== X-Received: by 10.194.79.74 with SMTP id h10mr181645wjx.86.1384536081319; Fri, 15 Nov 2013 09:21:21 -0800 (PST) Received: from [10.0.0.9] (bzq-79-182-173-156.red.bezeqint.net. [79.182.173.156]) by mx.google.com with ESMTPSA id x19sm6881868wia.5.2013.11.15.09.21.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 09:21:20 -0800 (PST) Message-ID: <5286580F.3050105@gmail.com> Date: Fri, 15 Nov 2013 19:21:19 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dan Harkins , dsfjdssdfsd@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:21:22 -0000 Hi Dan, While I'm fully supportive of what you're out to achieve, I'm not clear on what it is :-) Option A: specify requirements for an RNG (must mix multiple sources of randomness, must survive state disclosure, the output must not reveal the internal state for a standard attacker model, etc.) Option B1: specify the deterministic part of an RNG, i.e. the crypto algorithm. Option B2: specify the deterministic part, as well as the randomness sources (I'm avoiding the E word...). Option A is important but most of us don't like requirements documents... Option B1 is certainly fun, but traditionally such work has not been done in the IETF. In most cases we have recommended or adopted work done by other standards bodies or even individual cryptographers. Option B2 is IMHO too OS-specific to be useful. So which is it? Thanks, Yaron From jsalowey@cisco.com Fri Nov 15 09:35:13 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409E611E81B5 for ; Fri, 15 Nov 2013 09:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.247 X-Spam-Level: X-Spam-Status: No, score=-110.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUaZActQpAGw for ; Fri, 15 Nov 2013 09:35:08 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BAA5411E81AD for ; Fri, 15 Nov 2013 09:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1574; q=dns/txt; s=iport; t=1384536885; x=1385746485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zgjDVjur6Tka/QoD6fODEOfPknUdQIhNPrc3hgYQ0ek=; b=GEI+PYEvMtBPPKdlFPFzUwVBhusPfU6EUNXWrTSlLJp1ryUEipRgFNSP gEwTiXarxG2v1hX/pjcjRdYvpTyINjqtd4xigAvgA+VZQ+Pfdkjfkkqso Mu5guEL8jc8+xNmsc2TMt+c9VexSyRgYbvuNrZuyqzmHgCMcDcAnPZv8c 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAOdZhlKtJV2Z/2dsb2JhbABZgwc4U75gS4EqFnSCJQEBAQMBAQEBNzQLBQsCAQg2ECEGCyUCBA4Fh28DCQYNtzoNiUQEjHOCQzMHgyCBEQOWJYFrjFWFOIMogio X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="scan'208";a="285371179" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2013 17:34:44 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFHYiUt004241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 17:34:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 11:34:44 -0600 From: "Joseph Salowey (jsalowey)" To: Yaron Sheffer Thread-Topic: [dsfjdssdfsd] specifying an RNG Thread-Index: AQHO4cdS9ucHDFeToUWhpJpE9AXeK5om7ziAgAADvoA= Date: Fri, 15 Nov 2013 17:34:44 +0000 Message-ID: <573A5C4A-290D-4942-A113-B7E4315E9198@cisco.com> References: <5286580F.3050105@gmail.com> In-Reply-To: <5286580F.3050105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E6C14434F56C8488AEEDC47D31F4F42@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Dan Harkins Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:35:13 -0000 On Nov 15, 2013, at 9:21 AM, Yaron Sheffer wrote: > Hi Dan, >=20 > While I'm fully supportive of what you're out to achieve, I'm not clear o= n what it is :-) >=20 > Option A: specify requirements for an RNG (must mix multiple sources of r= andomness, must survive state disclosure, the output must not reveal the in= ternal state for a standard attacker model, etc.) >=20 [Joe] Yes > Option B1: specify the deterministic part of an RNG, i.e. the crypto algo= rithm. >=20 [Joe] Yes, except choose an exiting RNG and describe how to use it to meet = requirements in A > Option B2: specify the deterministic part, as well as the randomness sour= ces (I'm avoiding the E word...). >=20 [Joe] While this is somewhat out of scope we ought to provide whatever guid= ance we can so folks can avoid common implementation errors. I think there= are useful recommendations we can make based on the list of issues posted = on a different thread.=20 > Option A is important but most of us don't like requirements documents... >=20 > Option B1 is certainly fun, but traditionally such work has not been done= in the IETF. In most cases we have recommended or adopted work done by oth= er standards bodies or even individual cryptographers. >=20 > Option B2 is IMHO too OS-specific to be useful. >=20 > So which is it? >=20 > Thanks, > Yaron >=20 > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From yaronf.ietf@gmail.com Fri Nov 15 09:47:47 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27811E8203 for ; Fri, 15 Nov 2013 09:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlX4iVFLMUoo for ; Fri, 15 Nov 2013 09:47:46 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5926021F9CE9 for ; Fri, 15 Nov 2013 09:47:01 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id f4so2785784wiw.3 for ; Fri, 15 Nov 2013 09:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=STLFzmdfo4JC+VtePqm+6RJxkqGxQoMn1kfYDrKGC/s=; b=GwfdeW9holaLf9Lcs8wWiq+P2I/4d87EPm/sd0onGbiKVbpSVrGpC2j2GBPt/oCR6o a8uFLimqyw7fNAu3reaO9ltSGAZWnjI1HnVatsmx5woxz5/s3eGJjXgUan0J3mSfPoTg i+5M78G0DXQVEezBZlnGC+mWL2ok+5v7RLV5MNIpgxhNsDOeU6Qf0gY1I+zVCRghJvfx uxfoFxMYXpALNRw8aH4k3P2LyLrA5mgpQYz9wuGOyreGB16r00tHMIv7i9y93U5o1Znz QI1QdOHhZ+B+hEuJUurOIfvb/YP3AvK6ICrGhiShx0XqftCD21V2Pkt0hwzxzsxJnolf anJQ== X-Received: by 10.194.23.8 with SMTP id i8mr1065827wjf.68.1384537609827; Fri, 15 Nov 2013 09:46:49 -0800 (PST) Received: from [10.0.0.9] (bzq-79-182-173-156.red.bezeqint.net. [79.182.173.156]) by mx.google.com with ESMTPSA id uc12sm7161162wib.3.2013.11.15.09.46.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 09:46:49 -0800 (PST) Message-ID: <52865E07.6020105@gmail.com> Date: Fri, 15 Nov 2013 19:46:47 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <5286580F.3050105@gmail.com> <573A5C4A-290D-4942-A113-B7E4315E9198@cisco.com> In-Reply-To: <573A5C4A-290D-4942-A113-B7E4315E9198@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , Dan Harkins Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:47:47 -0000 Works for me, including the caveat on adopting an already vetted RNG. Yaron On 11/15/2013 07:34 PM, Joseph Salowey (jsalowey) wrote: > > On Nov 15, 2013, at 9:21 AM, Yaron Sheffer > wrote: > >> Hi Dan, >> >> While I'm fully supportive of what you're out to achieve, I'm not clear on what it is :-) >> >> Option A: specify requirements for an RNG (must mix multiple sources of randomness, must survive state disclosure, the output must not reveal the internal state for a standard attacker model, etc.) >> > > [Joe] Yes > >> Option B1: specify the deterministic part of an RNG, i.e. the crypto algorithm. >> > > [Joe] Yes, except choose an exiting RNG and describe how to use it to meet requirements in A > >> Option B2: specify the deterministic part, as well as the randomness sources (I'm avoiding the E word...). >> > > [Joe] While this is somewhat out of scope we ought to provide whatever guidance we can so folks can avoid common implementation errors. I think there are useful recommendations we can make based on the list of issues posted on a different thread. > >> Option A is important but most of us don't like requirements documents... >> >> Option B1 is certainly fun, but traditionally such work has not been done in the IETF. In most cases we have recommended or adopted work done by other standards bodies or even individual cryptographers. >> >> Option B2 is IMHO too OS-specific to be useful. >> >> So which is it? >> >> Thanks, >> Yaron >> >> _______________________________________________ >> dsfjdssdfsd mailing list >> dsfjdssdfsd@ietf.org >> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > From michael.hammer@yaanatech.com Fri Nov 15 10:41:06 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05F11E80F5 for ; Fri, 15 Nov 2013 10:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poN0HGRIs2ZZ for ; Fri, 15 Nov 2013 10:41:02 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 23D6B21F9E4F for ; Fri, 15 Nov 2013 10:41:02 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Fri, 15 Nov 2013 10:41:01 -0800 From: Michael Hammer To: "yaronf.ietf@gmail.com" , "jsalowey@cisco.com" Thread-Topic: [dsfjdssdfsd] specifying an RNG Thread-Index: AQHO4cdQpAJwDq2KTky44PY2jRF3GJonEL+AgAADwACAAANegP//iEkg Date: Fri, 15 Nov 2013 18:40:59 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEFB27D@sc9-ex2k10mb1.corp.yaanatech.com> References: <5286580F.3050105@gmail.com> <573A5C4A-290D-4942-A113-B7E4315E9198@cisco.com> <52865E07.6020105@gmail.com> In-Reply-To: <52865E07.6020105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.231] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01CEE208.51358200" MIME-Version: 1.0 Cc: "dsfjdssdfsd@ietf.org" , "dharkins@lounge.org" Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:41:06 -0000 ------=_NextPart_000_0023_01CEE208.51358200 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I was wondering if the output would be a combination of a Ten Commandments and Roadmap. (Note, ten is not a magic number) The first part identifying the most common mistakes to avoid and what approaches help to avoid that. The second part pointing to organizations or bodies of work that can be referenced to dive deeper. Mike -----Original Message----- From: dsfjdssdfsd-bounces@ietf.org [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Friday, November 15, 2013 12:47 PM To: Joseph Salowey (jsalowey) Cc: ; Dan Harkins Subject: Re: [dsfjdssdfsd] specifying an RNG Works for me, including the caveat on adopting an already vetted RNG. Yaron On 11/15/2013 07:34 PM, Joseph Salowey (jsalowey) wrote: > > On Nov 15, 2013, at 9:21 AM, Yaron Sheffer > wrote: > >> Hi Dan, >> >> While I'm fully supportive of what you're out to achieve, I'm not clear on what it is :-) >> >> Option A: specify requirements for an RNG (must mix multiple sources of randomness, must survive state disclosure, the output must not reveal the internal state for a standard attacker model, etc.) >> > > [Joe] Yes > >> Option B1: specify the deterministic part of an RNG, i.e. the crypto algorithm. >> > > [Joe] Yes, except choose an exiting RNG and describe how to use it to meet requirements in A > >> Option B2: specify the deterministic part, as well as the randomness sources (I'm avoiding the E word...). >> > > [Joe] While this is somewhat out of scope we ought to provide whatever guidance we can so folks can avoid common implementation errors. I think there are useful recommendations we can make based on the list of issues posted on a different thread. > >> Option A is important but most of us don't like requirements documents... >> >> Option B1 is certainly fun, but traditionally such work has not been done in the IETF. In most cases we have recommended or adopted work done by other standards bodies or even individual cryptographers. >> >> Option B2 is IMHO too OS-specific to be useful. >> >> So which is it? >> >> Thanks, >> Yaron >> >> _______________________________________________ >> dsfjdssdfsd mailing list >> dsfjdssdfsd@ietf.org >> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > _______________________________________________ dsfjdssdfsd mailing list dsfjdssdfsd@ietf.org https://www.ietf.org/mailman/listinfo/dsfjdssdfsd ------=_NextPart_000_0023_01CEE208.51358200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEx NTE4NDA1OVowIwYJKoZIhvcNAQkEMRYEFFfvhMCialY+TXFGBmtyfq2EEZibMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAakVo/D2/SaSM5DMitubU5XFgyJ/7OWKvd9KUOGa4 6W99+hEZtKVJGwtRhGBacN+MXDHXz9js6gGotX7tTLEMlNWvLLA05pGVrPvFGwg12U+lRlEQgk1r Te/+goSkPIpWWn8+h+5qjskjZUoti4uoFQ/otNPxL2r5/XdzVDb0UZYqGcL9FlIObgi0dF/eBhbm Ry2sePpiavewqnoeIbytlgAyqCFpI1C2r7FQy2rsE7U0mmBN4Butuh1i6egS27rofghBLspLGCsu aX8ybJ4msSqWVbH/frlQ0zPFJ6CeKPOmJpIdG8lScIUQCE/oDT+wP2AHtX9NnrJzYrTW8GMu8AAA AAAAAA== ------=_NextPart_000_0023_01CEE208.51358200-- From dharkins@lounge.org Fri Nov 15 15:14:16 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7725D11E811B for ; Fri, 15 Nov 2013 15:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.789 X-Spam-Level: X-Spam-Status: No, score=-4.789 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1O3uIDm7l4R for ; Fri, 15 Nov 2013 15:14:10 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4211E80DC for ; Fri, 15 Nov 2013 15:14:06 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7D69C10224008; Fri, 15 Nov 2013 15:14:06 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 15 Nov 2013 15:14:06 -0800 (PST) Message-ID: <97a514da15d21bc407707dbae42e7972.squirrel@www.trepanning.net> In-Reply-To: <573A5C4A-290D-4942-A113-B7E4315E9198@cisco.com> References: <5286580F.3050105@gmail.com> <573A5C4A-290D-4942-A113-B7E4315E9198@cisco.com> Date: Fri, 15 Nov 2013 15:14:06 -0800 (PST) From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dsfjdssdfsd@ietf.org, Yaron Sheffer Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 23:14:16 -0000 Hello, On Fri, November 15, 2013 9:34 am, Joseph Salowey (jsalowey) wrote: > > On Nov 15, 2013, at 9:21 AM, Yaron Sheffer > wrote: > >> Hi Dan, >> >> While I'm fully supportive of what you're out to achieve, I'm not clear >> on what it is :-) >> >> Option A: specify requirements for an RNG (must mix multiple sources of >> randomness, must survive state disclosure, the output must not reveal >> the internal state for a standard attacker model, etc.) >> > > [Joe] Yes Actually I think should this be draft-eastlake-randomness3. RFC 4086 (which this will update) is a good but, as Donal noted, dated set of requirements for a good random number generator. >> Option B1: specify the deterministic part of an RNG, i.e. the crypto >> algorithm. >> > > [Joe] Yes, except choose an exiting RNG and describe how to use it to meet > requirements in A Yes, this is what I'm talking about. Something that someone can implement straightforwardly. I think the potential for subtle mistakes by someone who thinks he knows what he's doing after reading RFC 4086 (someone like me) is real and a specification that has been vetted by some people who do know what they're doing would be valuable. >> Option B2: specify the deterministic part, as well as the randomness >> sources (I'm avoiding the E word...). >> > > [Joe] While this is somewhat out of scope we ought to provide whatever > guidance we can so folks can avoid common implementation errors. I think > there are useful recommendations we can make based on the list of issues > posted on a different thread. I agree with Joe on this. >> Option A is important but most of us don't like requirements >> documents... >> >> Option B1 is certainly fun, but traditionally such work has not been >> done in the IETF. In most cases we have recommended or adopted work done >> by other standards bodies or even individual cryptographers. Which is fine! I'm not recommending we roll our own. We have RFCs on secure hash algorithms, on key derivation functions, we even have one on how to do the Diffie-Hellman key exchange. None of these are original IETF work. What we don't have, though, is one on a good RNG and that's something that should be rectified. regards, Dan. >> Option B2 is IMHO too OS-specific to be useful. >> >> So which is it? >> >> Thanks, >> Yaron >> >> _______________________________________________ >> dsfjdssdfsd mailing list >> dsfjdssdfsd@ietf.org >> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > From tytso@thunk.org Fri Nov 15 18:42:54 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50EC11E8146 for ; Fri, 15 Nov 2013 18:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z89uyRyRwpt6 for ; Fri, 15 Nov 2013 18:42:54 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 455A811E8223 for ; Fri, 15 Nov 2013 18:42:53 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1VhVqQ-0005AF-Uv; Sat, 16 Nov 2013 02:42:47 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 4754858087B; Fri, 15 Nov 2013 21:42:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1384569762; bh=ira7EZrPESjCrS8YSX+YGCiJdhUy2v10AhSd+ZWPb4U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vIExOYhkKpi1ClUYxG21EMlOr0VEg8y58DuHaOhhT2V7C7nznlXriCxfvHRvSBbvq idC9FD1w0258xFAcs01JP3+0GmQtRD5fI/iHSy5OPrguHIzcDUyRSYgtqBiaJfTsfB K5tfwYlVHqzmQpps9H79gOixrZZ8QkpxjTZ+vle0= Date: Fri, 15 Nov 2013 21:42:42 -0500 From: Theodore Ts'o To: Nick Mathewson Message-ID: <20131116024242.GE16722@thunk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 02:42:54 -0000 On Fri, Nov 15, 2013 at 11:36:14AM -0500, Nick Mathewson wrote: > CC. Theoretically unsound pool constructions > > See for example the recent paper on the Linux /dev/*random devices' > constructions [10]. CC is a bit vague, and is redundant with AA, BB, and EE in your list. The assertion made in [10] is that an attacker who can control all of the entropy inputs in such a way that defeats the entropy estimator (which is EE), could result in a failure of guarantees such as BB (recovery after compromised state). Whether or not an attacker could control all entropy inputs in such as way that it could defeat the entropy estimator was not actually shown in [10], and I'm not entirely sure that insisting on a theoretical model which requires that a design should be robust against by arbitrary control of the entropy sources (as opposed to auditing the entropy sources actually *used* by the RNG) is a all that useful --- but that's aside from the point I'm trying to make here, which is if you're going to have a list of potential RNG failures, they should be a specific set of things that you can look for, and not something vague and overarching such as "bad design of the RNG pools". Cheers, - Ted From agr@me.com Sat Nov 16 16:06:03 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9811E80E6 for ; Sat, 16 Nov 2013 16:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.725 X-Spam-Level: X-Spam-Status: No, score=-5.725 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKXNFe1BB2+k for ; Sat, 16 Nov 2013 16:05:56 -0800 (PST) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtp004.mac.com [17.172.204.239]) by ietfa.amsl.com (Postfix) with ESMTP id D618711E80E2 for ; Sat, 16 Nov 2013 16:05:56 -0800 (PST) Received: from new-host-3.home (pool-108-7-220-89.bstnma.fios.verizon.net [108.7.220.89]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MWD001PKS9FLO90@st11p01mm-asmtp001.mac.com> for dsfjdssdfsd@ietf.org; Sun, 17 Nov 2013 00:05:39 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.14,0.0.0000 definitions=2013-11-16_02:2013-11-15, 2013-11-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1311160224 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Arnold Reinhold In-reply-to: Date: Sat, 16 Nov 2013 19:05:37 -0500 Content-transfer-encoding: quoted-printable Message-id: <431FFC44-0520-48DF-8D64-62BB2753C934@me.com> References: To: Nick Mathewson X-Mailer: Apple Mail (2.1822) Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 00:06:03 -0000 On Nov 15, 2013, at 11:36 AM, Nick Mathewson = wrote: >=20 > =3D=3D What has gone wrong in practice and led to actual working = attacks: >=20 > A. Not actually using randomness at all for something that needs some > or all of the properties of a random bitstring. >=20 > Example: Sony's implementation of ECDSA failed to actually change the > k value between signatures; they just had a constant.[1] >=20 >=20 .... > * Underdocumented, underexplained randomness requirements. >=20 > Before you sniff too loudly at Sony's mistake in [1]: Pretend that you > are a programmer in a hurry looking at FIPS 186-2, or your favorite > (early) standards-body description of DSA. How well does it explain > the importance of making 'k' completely unpredictable for each > message, and how well does it explain the consequences for failing to > do so? >=20 I has also been suggested that Sony's failure to generate unique k's = could have been caused by a compiler that optimized the = k=3Dcrypto_random(); call out of a loop. Whether that happened or not = in the Sony case, the possibility should be dealt with in any RNG = standard, as the consequence of a repeated k is easy recovery of the = private key. Perhaps there should be a requirement that two (or more) = test signatures be generated at application startup to verify = independent k's are being generated, as code that worked initially could = later be recompiled with different optimization settings for a new = release..=20 Arnold Reinhold From housley@vigilsec.com Sat Nov 16 16:19:12 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C37011E80EA for ; Sat, 16 Nov 2013 16:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGhzRdNQZ2OO for ; Sat, 16 Nov 2013 16:19:07 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4F99F11E80E2 for ; Sat, 16 Nov 2013 16:19:07 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D133BF2408D; Sat, 16 Nov 2013 19:18:53 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id PVwlfO5KsNkg; Sat, 16 Nov 2013 19:18:32 -0500 (EST) Received: from [192.168.6.24] (ip-64-134-184-113.public.wayport.net [64.134.184.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 86BA0F2400F; Sat, 16 Nov 2013 19:18:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley X-Priority: 3 (Normal) In-Reply-To: Date: Sat, 16 Nov 2013 19:18:16 -0500 Content-Transfer-Encoding: 7bit Message-Id: <8AC26C38-F2E4-44DA-B731-B795258EF186@vigilsec.com> References: To: Dan Harkins X-Mailer: Apple Mail (2.1085) Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 00:19:12 -0000 Dan: Random or pseudorandom? Do you care? Russ On Nov 15, 2013, at 12:55 AM, Dan Harkins wrote: > > Hello, and welcome to the dsfjdssdfsd list! > > At the last IETF the question was asked, "what can we do to harden > the Internet?" Given the recent news about Dual_EC_DBRG and the > dopant attack against hardware RNGs one of the things that can be > done is to have an open specification of a secure RNG. This would > allow developers to have an alternative to relying solely on > /dev/[u]random, a hardware RNG, an RNG specified by a large > government-affiliated group to mix the uncorrelated sources of > entropy they gather, or an RNG designed in an ad hoc manner by > someone who thinks he knows what he's doing but probably > doesn't. > > One of the things that would be nice to get out of this list is a > specification on a strong RNG, in the form of a BCP or Informational > RFC. This doesn't necessarily mean lets "roll our own" but perhaps > there is best practice that can be specified. > > So, is there a model that defines what a "robust RNG" would look > like? Is there a suitable candidate that exists already for such a thing? > > regards, > > Dan. > > > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From housley@vigilsec.com Sat Nov 16 16:21:35 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC811E80EA for ; Sat, 16 Nov 2013 16:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMUn0q53HFO2 for ; Sat, 16 Nov 2013 16:21:30 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62D11E80E2 for ; Sat, 16 Nov 2013 16:21:30 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id B349BF2408E; Sat, 16 Nov 2013 19:21:19 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id cCJAUYb-4GVK; Sat, 16 Nov 2013 19:20:58 -0500 (EST) Received: from [192.168.6.24] (ip-64-134-184-113.public.wayport.net [64.134.184.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 443A9F2400F; Sat, 16 Nov 2013 19:20:58 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-164-466036223 From: Russ Housley In-Reply-To: Date: Sat, 16 Nov 2013 19:20:45 -0500 Message-Id: <7C7986F2-FDCE-4161-A7AB-D9D870E29BA5@vigilsec.com> References: <49FF9BED-3844-4D15-8F84-6E7231FE0892@standardstrack.com> To: Donald Eastlake X-Mailer: Apple Mail (2.1085) Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 00:21:35 -0000 --Apple-Mail-164-466036223 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Donald: > RFC 4086, which is on this topic, is a BCP but is out of date and = doesn't recommend a specific random number generator. > https://datatracker.ietf.org/doc/draft-eastlake-randomness3/ > is the start of an effort towards a replacement but needs a lot of = work. >=20 > By the way, not that I am arguing for or against it for this case, but = it is quite possible for a BCP or IETF standard to consist of a set of = RFCs=85 In my mind, we should update the BCP and provide an informational = document that specifies a mechanism. I do not think that there is going = to be the one true mechanism that applies to every case. Russ --Apple-Mail-164-466036223 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
RFC 4086, = which is on this topic, is a BCP but is out of date and doesn't = recommend a specific random number generator.
http= s://datatracker.ietf.org/doc/draft-eastlake-randomness3/
is the = start of an effort towards a replacement but needs a lot of = work.

By the way, not that I am arguing for or = against it for this case, but it is quite possible for a BCP or IETF = standard to consist of a set of = RFCs=85

In my mind, we should = update the BCP and provide an informational document that specifies a = mechanism.  I do not think that there is going to be the one true = mechanism that applies to every = case.

Russ

= --Apple-Mail-164-466036223-- From housley@vigilsec.com Sat Nov 16 16:33:22 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F38011E8143 for ; Sat, 16 Nov 2013 16:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX-FgKFYGx0n for ; Sat, 16 Nov 2013 16:33:16 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCA711E8105 for ; Sat, 16 Nov 2013 16:33:16 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9F0E2F24091; Sat, 16 Nov 2013 19:33:05 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id fsm1wmG1w-7Y; Sat, 16 Nov 2013 19:32:44 -0500 (EST) Received: from [192.168.6.24] (ip-64-134-184-113.public.wayport.net [64.134.184.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0870FF2400F; Sat, 16 Nov 2013 19:32:43 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <431FFC44-0520-48DF-8D64-62BB2753C934@me.com> Date: Sat, 16 Nov 2013 19:32:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <431FFC44-0520-48DF-8D64-62BB2753C934@me.com> To: Arnold Reinhold X-Mailer: Apple Mail (2.1085) Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 00:33:22 -0000 Arnold: >> =3D=3D What has gone wrong in practice and led to actual working = attacks: >>=20 >> A. Not actually using randomness at all for something that needs some >> or all of the properties of a random bitstring. >>=20 >> Example: Sony's implementation of ECDSA failed to actually change the >> k value between signatures; they just had a constant.[1] >>=20 >>=20 > .... >> * Underdocumented, underexplained randomness requirements. >>=20 >> Before you sniff too loudly at Sony's mistake in [1]: Pretend that = you >> are a programmer in a hurry looking at FIPS 186-2, or your favorite >> (early) standards-body description of DSA. How well does it explain >> the importance of making 'k' completely unpredictable for each >> message, and how well does it explain the consequences for failing to >> do so? >>=20 >=20 > I has also been suggested that Sony's failure to generate unique k's = could have been caused by a compiler that optimized the = k=3Dcrypto_random(); call out of a loop. Whether that happened or not = in the Sony case, the possibility should be dealt with in any RNG = standard, as the consequence of a repeated k is easy recovery of the = private key. Perhaps there should be a requirement that two (or more) = test signatures be generated at application startup to verify = independent k's are being generated, as code that worked initially could = later be recompiled with different optimization settings for a new = release..=20 There should be a self-test part of the specification that detects this = type of failure. It should not be hard to turn the FIPS 140 test suite = into a good-enough-to-continue / fail test. This would envolve = generating 10,000 random bits and doing some statistical checks. Russ From nick.a.mathewson@gmail.com Sat Nov 16 19:04:43 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A9411E8125 for ; Sat, 16 Nov 2013 19:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaqrvsFRE4lJ for ; Sat, 16 Nov 2013 19:04:43 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id ED30511E80E9 for ; Sat, 16 Nov 2013 19:04:42 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id ea20so3939108lab.12 for ; Sat, 16 Nov 2013 19:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=I9jRN9soYB13qfW3CyvuR+2bIo+8jTuV/5uRg4dYZ8M=; b=fQfnznCAwitmAVm5PLogblLyzHt6lcLAGvY0pYgRVjY3r5akWzuRqdBeb7daiWb5fS f7HI3Gk/QKA/eKOk1v2rh0F1rct3TpNC+s+OWIcZMrebHa1BM2zFow9N668L6PMQjlK8 MgagQ3Odr4oLFLfqQgqRgDGOOYL7SL5IZGz5IAWLx8iP38KR9hxFC7SZ4yqn6wCU6ab8 PnDvZKgdMsiTloHVmL0gPH6rn5JZp9SVk1Q9UaMHzv7d1+BSnfd28B65HMQybOuuQCDP zzWFMiHVFUE+VKM1T2DpR8Y7WBWdh5G6i27ph7dxKkIq1RZeWqOTsXhSJoHPKf/fz7Gp IB2g== MIME-Version: 1.0 X-Received: by 10.152.27.67 with SMTP id r3mr676445lag.50.1384657481511; Sat, 16 Nov 2013 19:04:41 -0800 (PST) Sender: nick.a.mathewson@gmail.com Received: by 10.112.75.165 with HTTP; Sat, 16 Nov 2013 19:04:41 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Nov 2013 22:04:41 -0500 X-Google-Sender-Auth: dO1YpzfOzsSSj07WHdPtRY1kFOk Message-ID: From: Nick Mathewson To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 03:04:43 -0000 On Fri, Nov 15, 2013 at 11:36 AM, Nick Mathewson wrote: > Hi! [....] > G. Using the same RNG state to generate two bitstreams. > > Example: The SecureRandom structure in Android was initialized once, > and then used as the initial SecureRandom for multiple processes. This > led to a large compromise in Android bitcoin wallets. [7] > > Example: Python had the same problem [8]: the same RNG state was used > after fork. I have received a correction for this one. The original reporter of the Python bug (Christian Heimes) informs me that the bug is not in the main Python secure RNG (which just reads /dev/urandom or the local equivalent), but in OpenSSL's RNG as used in Python, which ought to be reseeded or invalidated on fork() when Python is using OpenSSL, but which is difficult to reset from an at_fork() handler because of issues as discussed in [14]. Additionally, Tanja Lange mentioned [12] another category of real-world vulnerability as discussed in [13]. These might be called: J. Using unreliable hardware entropy sources directly rather than as inputs to a PRNG. (The cautious behavior is to design your PRNG such that it produces good outputs if its inputs have *ever* been random enough.) or K. Omitting run-time tests for hardware entropy sources While some failures are undetectable, it's just tempting fate to omit tests for detectable failures of hardware components. [12] https://twitter.com/hyperelliptic/status/401831967177461760 [13] http://smartfacts.cr.yp.to/analysis.html [14] http://bugs.python.org/issue19227 best wishes, -- Nick From nick.a.mathewson@gmail.com Sat Nov 16 19:24:20 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073EB11E821A for ; Sat, 16 Nov 2013 19:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.542 X-Spam-Level: X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQn-qC9boH9A for ; Sat, 16 Nov 2013 19:24:19 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBEF11E83DE for ; Sat, 16 Nov 2013 19:24:18 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id ep20so3932672lab.3 for ; Sat, 16 Nov 2013 19:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Z3acNPrHLp4ISFrUoKPYdv+MEtD9IiXzhS/ANdWt79I=; b=xKjRd96XAuw4xod5hWq+77m2SJLeP8Y41vEkxlJR42cB53GHfsPU0yb/8cTgyDvulc YD2DS4NFew9rQHwSRbOD9pHwuwXoC1v3hBIHLdzt6ixt3f9XyWmy9A6fb68AKXiNE7tJ 2W09Z19IHS47lR8/XayFInZ853XzaPpT2yHAL00NumTnu1O94MbbxZvfmeK9YlV6fbN9 9aGznQkkWUikZmOiO8qRRvUx5lEgAdc/Dnyj4ISGD/mQJmIMsxOEnsxJEChRmrtfIK1x OR985eRvU+QtbU7ivwj/JxYAOMb5uFuyvcGvmCT95ATuwRyyqytqZX6cEeQ5pqweE8Ft mt4Q== MIME-Version: 1.0 X-Received: by 10.152.19.74 with SMTP id c10mr698007lae.48.1384658658107; Sat, 16 Nov 2013 19:24:18 -0800 (PST) Sender: nick.a.mathewson@gmail.com Received: by 10.112.75.165 with HTTP; Sat, 16 Nov 2013 19:24:18 -0800 (PST) In-Reply-To: <20131116024242.GE16722@thunk.org> References: <20131116024242.GE16722@thunk.org> Date: Sat, 16 Nov 2013 22:24:18 -0500 X-Google-Sender-Auth: q23WUMqzyq-G9VI35NGZifpuTXA Message-ID: From: Nick Mathewson To: "Theodore Ts'o" Content-Type: text/plain; charset=ISO-8859-1 Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 03:24:20 -0000 On Fri, Nov 15, 2013 at 9:42 PM, Theodore Ts'o wrote: > On Fri, Nov 15, 2013 at 11:36:14AM -0500, Nick Mathewson wrote: >> CC. Theoretically unsound pool constructions >> >> See for example the recent paper on the Linux /dev/*random devices' >> constructions [10]. > > CC is a bit vague, and is redundant with AA, BB, and EE in your list. > > The assertion made in [10] is that an attacker who can control all of > the entropy inputs in such a way that defeats the entropy estimator > (which is EE), could result in a failure of guarantees such as BB > (recovery after compromised state). > > Whether or not an attacker could control all entropy inputs in such as > way that it could defeat the entropy estimator was not actually shown > in [10], and I'm not entirely sure that insisting on a theoretical > model which requires that a design should be robust against by > arbitrary control of the entropy sources (as opposed to auditing the > entropy sources actually *used* by the RNG) is a all that useful --- > but that's aside from the point I'm trying to make here, which is if > you're going to have a list of potential RNG failures, they should be > a specific set of things that you can look for, and not something > vague and overarching such as "bad design of the RNG pools". Let me try to clarify what I meant by CC. I agree that my original wording was sloppy, and even though I was listing issues which to my (limited!) knowledge have never actually led to a serious attack, that's no excuse for being vague. (To my further discredit, re-reading what I wrote, I don't think it actually *could* have meant what I meant it to mean, and the example I chose was a stupid one too. Whoops.) So here's what I should have said: == What has gone wrong, and is probably bad, but has not (AFAICT) led to any publicized attacks yet: [...] CC. Unproven cryptographic properties We have (and continue to come up with) several definitions of what it means for an RNG construction to be secure. We have some constructions which we can prove to meet these definitions (though they may have other issues), and some which don't seem to have security proofs but which many reasonable practitioners believe to be secure anyway. *All things being equal*, we would expect to have more confidence in constructions where we can prove something useful about their security properties. (However, I am not personally aware of any example ad-hoc cryptographic RNG constructions which lacked a security proof, survived close scrutiny by sensible practitioners, and then later turned out to be much more broken than expected in some cryptographic way. That' s why I'm classifying this as "probably problematic" rather than "actually leading to attacks." But if there's a counter example, I would be excited to learn about it so that I can strengthen my "you should probably make sure you have a proof" argument.) ((Further, I am aware that "all things" are never quite "equal", and I would personally sidle away from quite a few current proven constructions for other engineering reasons.)) best wishes, -- Nick Mathewson From dharkins@lounge.org Sun Nov 17 00:35:50 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B836E11E88C2 for ; Sun, 17 Nov 2013 00:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.351 X-Spam-Level: X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqtRCPWpUtmA for ; Sun, 17 Nov 2013 00:35:46 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 339DF11E88BF for ; Sun, 17 Nov 2013 00:35:46 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 610F310224008; Sun, 17 Nov 2013 00:35:45 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 17 Nov 2013 00:35:45 -0800 (PST) Message-ID: <525aec4425179480df24c5e275c0c9e7.squirrel@www.trepanning.net> In-Reply-To: <8AC26C38-F2E4-44DA-B731-B795258EF186@vigilsec.com> References: <8AC26C38-F2E4-44DA-B731-B795258EF186@vigilsec.com> Date: Sun, 17 Nov 2013 00:35:45 -0800 (PST) From: "Dan Harkins" To: "Russ Housley" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dsfjdssdfsd@ietf.org, Dan Harkins Subject: Re: [dsfjdssdfsd] specifying an RNG X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 08:35:51 -0000 Hi Russ, On Sat, November 16, 2013 4:18 pm, Russ Housley wrote: > Dan: > > Random or pseudorandom? Do you care? The output has to be suitable for doing a digital signature or a Diffie-Hellman key exchange. Dan. > Russ > > > On Nov 15, 2013, at 12:55 AM, Dan Harkins wrote: > >> >> Hello, and welcome to the dsfjdssdfsd list! >> >> At the last IETF the question was asked, "what can we do to harden >> the Internet?" Given the recent news about Dual_EC_DBRG and the >> dopant attack against hardware RNGs one of the things that can be >> done is to have an open specification of a secure RNG. This would >> allow developers to have an alternative to relying solely on >> /dev/[u]random, a hardware RNG, an RNG specified by a large >> government-affiliated group to mix the uncorrelated sources of >> entropy they gather, or an RNG designed in an ad hoc manner by >> someone who thinks he knows what he's doing but probably >> doesn't. >> >> One of the things that would be nice to get out of this list is a >> specification on a strong RNG, in the form of a BCP or Informational >> RFC. This doesn't necessarily mean lets "roll our own" but perhaps >> there is best practice that can be specified. >> >> So, is there a model that defines what a "robust RNG" would look >> like? Is there a suitable candidate that exists already for such a >> thing? >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> dsfjdssdfsd mailing list >> dsfjdssdfsd@ietf.org >> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd > From agr@me.com Mon Nov 18 04:42:56 2013 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91CB11E84DA for ; Mon, 18 Nov 2013 04:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.056 X-Spam-Level: X-Spam-Status: No, score=-5.056 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, SARE_SUB_11CONS_WORD=0.352] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cg-A9LguHZy for ; Mon, 18 Nov 2013 04:42:50 -0800 (PST) Received: from st11p01mm-asmtp005.mac.com (st11p01mm-asmtpout005.mac.com [17.172.204.240]) by ietfa.amsl.com (Postfix) with ESMTP id 078FB11E851A for ; Mon, 18 Nov 2013 04:42:20 -0800 (PST) Received: from new-host-3.home (pool-108-7-220-89.bstnma.fios.verizon.net [108.7.220.89]) by st11p01mm-asmtp005.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MWG00MLGLYI35A0@st11p01mm-asmtp005.mac.com> for dsfjdssdfsd@ietf.org; Mon, 18 Nov 2013 12:42:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.14,0.0.0000 definitions=2013-11-18_02:2013-11-18, 2013-11-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1311180054 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Arnold Reinhold In-reply-to: Date: Mon, 18 Nov 2013 07:42:18 -0500 Content-transfer-encoding: quoted-printable Message-id: <0551BB5B-60A8-4108-8B83-D14715F02C40@me.com> References: <431FFC44-0520-48DF-8D64-62BB2753C934@me.com> To: Russ Housley X-Mailer: Apple Mail (2.1822) Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 12:42:56 -0000 On Nov 16, 2013, at 7:32 PM, Russ Housley wrote: > Arnold: >=20 >>> =3D=3D What has gone wrong in practice and led to actual working = attacks: >>>=20 >>> A. Not actually using randomness at all for something that needs = some >>> or all of the properties of a random bitstring. >>>=20 >>> Example: Sony's implementation of ECDSA failed to actually change = the >>> k value between signatures; they just had a constant.[1] >>>=20 >>>=20 >> .... >>> * Underdocumented, underexplained randomness requirements. >>>=20 >>> Before you sniff too loudly at Sony's mistake in [1]: Pretend that = you >>> are a programmer in a hurry looking at FIPS 186-2, or your favorite >>> (early) standards-body description of DSA. How well does it explain >>> the importance of making 'k' completely unpredictable for each >>> message, and how well does it explain the consequences for failing = to >>> do so? >>>=20 >>=20 >> I has also been suggested that Sony's failure to generate unique k's = could have been caused by a compiler that optimized the = k=3Dcrypto_random(); call out of a loop. Whether that happened or not = in the Sony case, the possibility should be dealt with in any RNG = standard, as the consequence of a repeated k is easy recovery of the = private key. Perhaps there should be a requirement that two (or more) = test signatures be generated at application startup to verify = independent k's are being generated, as code that worked initially could = later be recompiled with different optimization settings for a new = release..=20 >=20 > There should be a self-test part of the specification that detects = this type of failure. It should not be hard to turn the FIPS 140 test = suite into a good-enough-to-continue / fail test. This would envolve = generating 10,000 random bits and doing some statistical checks. The FIPS 140 statistical test suite won't detect that a complier has = optimized a RNG call out of a loop. A special test is require here. Also = since any RNG likely to be recommended will either generate or whiten = bits using a crypto primitive such as SHAx or AES, statistical tests on = the output of such RNGs are of little worth. The output these primitives = is guaranteed pass any such test even if their input has be tampered = with to allow a small search space. The place where statistical tests would be very useful is in checking a = true random noise source. Here a trustworthy entropy source SHOULD = exhibit some deviation from pure randomness. Unfortunately many true = random bit generators have built in whitening circuits that prevent = downstream software from testing the underlying noise source. As I = understand it, this is the case with Intel's x86 hardware RNG = instructions. The lack of access to raw digitized noise makes such RNGs = impossible to audit. We are entering an era where many mission-critical internet devices use = solid state mass storage and lack other peripherals that can be used to = obtain entropy (such as audio inputs and cameras). There will be a = strong tendency to rely solely on random bit generators built into = billion-transistor CPUs or SoCs, which can have surreptitious back-doors = inserted during production by organizations with enough clout. Any standard that attempts to deliver real security must include some = guidance on choosing hardware that includes more than one independent, = auditable entropy source, each capable of delivering at least 128 bits = at start up when brand new, at first power up. Arnold Reinhold=