From nobody Tue Apr 1 10:10:53 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36B11A0996 for ; Tue, 1 Apr 2014 10:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhonJO15sq2n for ; Tue, 1 Apr 2014 10:10:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AD97A1A088C for ; Tue, 1 Apr 2014 10:10:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E276EBE51 for ; Tue, 1 Apr 2014 18:10:46 +0100 (IST) 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 7tfhGFLZ4O4W for ; Tue, 1 Apr 2014 18:10:46 +0100 (IST) 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 C0E7BBE47 for ; Tue, 1 Apr 2014 18:10:46 +0100 (IST) Message-ID: <533AF317.5070901@cs.tcd.ie> Date: Tue, 01 Apr 2014 18:10:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/HCC0IiCH-ui0oOET-YzhR9Iya3U Subject: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Apr 2014 17:10:52 -0000 Hiya, Looking at the traffic on this list I wondered if it'd be an idea to try document the things implementers should not do with (P)RNGs or to generate random (sets of:-) numbers. It seems like there's a lot of knowledge on that spread about and if there was someone was willing and able maybe an informational RFC about mistakes that have been made and how implementers can avoid 'em might be useful. Whatcha think? Or maybe that'd just generate endless debate and offer no useful guidance? Or maybe there's a survey paper out there somewhere or thesis that already has a load of that material? Ta, S. From nobody Tue Apr 1 10:48:23 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CA01A098F for ; Tue, 1 Apr 2014 10:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWHMCk6UsDzH for ; Tue, 1 Apr 2014 10:48:21 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 353721A09A8 for ; Tue, 1 Apr 2014 10:48:21 -0700 (PDT) Received: (qmail 19996 invoked by uid 0); 1 Apr 2014 17:48:14 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy3.mail.unifiedlayer.com with SMTP; 1 Apr 2014 17:48:14 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id kho81n0112UhLwi01hoB0c; Tue, 01 Apr 2014 11:48:13 -0600 X-Authority-Analysis: v=2.1 cv=QsvNgzCd c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=RqnEE4ZEFZYA:10 a=3NT3xRclEPMA:10 a=N659UExz7-8A:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=1XWaLZrsAAAA:8 a=UFTA8MH_AAAA:8 a=yhGuWPCGAAAA:8 a=xEDnGs-QEFyvGJ_s3msA:9 a=Updc-xldkNicgAMX:21 a=j9M9n1rsvv-VUa6F:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=HB/8/fxIJDI+Q4nv0ERI4RX+JWrzHbolMxpvHg26d+U=; b=iXrm4wyG1I3WU49z0L364H101FUs8MJ34ExW2rx/LGJfMrhEveOSbUGsLIjsd4qQju4wpWzcgnc4k6qvnzW7KYtvsb6Vbn4EkhPscZM8gcSeFRw/j/yrP9l42/Bgd85Z; Received: from [216.113.168.128] (port=24971 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WV2nB-0005N3-LV for dsfjdssdfsd@ietf.org; Tue, 01 Apr 2014 11:48:09 -0600 Message-ID: <533AFBD6.5050609@KingsMountain.com> Date: Tue, 01 Apr 2014 10:48:06 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Pseudorandom Number Generator PRNG discussion list Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/_JH-jVRkM2tb8Nisgad2gaEgUhc Subject: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Apr 2014 17:48:22 -0000 > Looking at the traffic on this list I wondered if it'd > be an idea to try document the things implementers should > not do with (P)RNGs or to generate random (sets of:-) > numbers. > > It seems like there's a lot of knowledge on that spread > about and if there was someone was willing and able maybe > an informational RFC about mistakes that have been made > and how implementers can avoid 'em might be useful. > > Whatcha think? > > Or maybe that'd just generate endless debate and offer > no useful guidance? > > Or maybe there's a survey paper out there somewhere > or thesis that already has a load of that material? well, here's some searches... "prng random number generator secure implementation survey" http://scholar.google.com/scholar?start=3D20&q=3Dprng+random+number+gener= ator+secure+implementation+survey&hl=3Den&as_sdt=3D1,5 "prng random number generator survey" http://scholar.google.com/scholar?q=3Dprng+random+number+generator+survey= &btnG=3D&hl=3Den&as_sdt=3D1%2C5 =2E.some cherry-picked items from first few pages of results (I havent=20 examined them, ymmv)... Desai, Anand, Alejandro Hevia, and Yiqun Lisa Yin. "A practice-oriented=20 treatment of pseudorandom number generators." In Advances in=20 Cryptology=97EUROCRYPT 2002, pp. 368-383. Springer Berlin Heidelberg, 200= 2. http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.109.5819&rep=3D= rep1&type=3Dpdf Matsumoto, Makoto, Mutsuo Saito, Hiroshi Haramoto, and Takuji Nishimura. = "Pseudorandom Number Generation: Impossibility and Compromise." J. UCS 12= ,=20 no. 6 (2006): 672-690. http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.103.911&rep=3D= rep1&type=3Dpdf Schoo, Marcus, Krzysztof Pawlikowski, and Donald C. McNickle. A survey an= d=20 empirical comparison of modern pseudo-random number generators for=20 distributed stochastic simulations. Department of Computer Science and=20 Software Development, University of Canterbury, 2005. https://cosc.canterbury.ac.nz/research/reports/TechReps/2005/tr_0503.pdf hth, =3DJeffH From nobody Wed Apr 2 07:24:29 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C471A0225 for ; Wed, 2 Apr 2014 07:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9KXSGU6_CG4 for ; Wed, 2 Apr 2014 07:24:23 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9FE1A0241 for ; Wed, 2 Apr 2014 07:24:22 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so282762qcx.13 for ; Wed, 02 Apr 2014 07:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zYfOTiLw9skawNUbd6Svx8y4gqC6sl4GiSqjENlECuk=; b=CRwNN77SoHTWGzUu36TuKBYQSMRLyavwmMPf3lsvKXBkgUReAo1Y/are+Fc/ZV9K1q 1O0dqPjFaHdgkxHu4kNAW7okHSAlJZti2VYZhmBe1on3j1ejqbE6Rnda8CATuPUVF9H8 2Bq2BVrI9hzcBiKin+JrQ2m7iaGVA27ryDMb4FB3++d/UG5IDlW7CI7dQMKwAVqDCE+D OJYReSqsPEIgt4oMk9tXTvAapJhXoCEQyVIhY+L2XPBTTLqv63uhb6H8NSAmHJEkxV2H +mJjIMIdGj3JUJcZBYJUF5+KhiNyWilC4jo/KBxXw5uwkd47xDwfJb8vEC5ytvubzORw pHsw== MIME-Version: 1.0 X-Received: by 10.140.49.233 with SMTP id q96mr975160qga.76.1396448654815; Wed, 02 Apr 2014 07:24:14 -0700 (PDT) Received: by 10.140.21.197 with HTTP; Wed, 2 Apr 2014 07:24:14 -0700 (PDT) In-Reply-To: <533AF317.5070901@cs.tcd.ie> References: <533AF317.5070901@cs.tcd.ie> Date: Wed, 2 Apr 2014 10:24:14 -0400 Message-ID: From: Sandy Harris To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/TjpW6J0mgk1PLNrWfcaFtgIZ2eY Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 14:24:27 -0000 On Tue, Apr 1, 2014 at 1:10 PM, Stephen Farrell wrote: > It seems like there's a lot of knowledge on that spread > about and if there was someone was willing and able maybe > an informational RFC about mistakes that have been made > and how implementers can avoid 'em might be useful. I think the old RFC 1750 and current 4086 pretty much cover that. https://tools.ietf.org/html/rfc4086 There has been mailing list discussion of an update to 4086, but I do not know how that is progressing. > Or maybe there's a survey paper out there somewhere > or thesis that already has a load of that material? At least two reference pages have been mentioned on various lists. I have looked at two and found both quite good. Unfortunately, I only recall one URL: http://www.av8n.com/computer/htm/secure-random.htm From nobody Wed Apr 2 07:58:05 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87B01A0249 for ; Wed, 2 Apr 2014 07:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxEtOn0RXAsy for ; Wed, 2 Apr 2014 07:57:59 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6E1A0257 for ; Wed, 2 Apr 2014 07:57:58 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wm4so373651obc.3 for ; Wed, 02 Apr 2014 07:57:55 -0700 (PDT) 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 :cc:content-type; bh=CQCscKRTuChoZ6bIV2E5dLcmYKbd7PeKqKzgkJ6ipXM=; b=ixAY1kpjSoA0P/SanS889lTosbqxYiNlfY+VoMJroGfkJ/2p+gBY/gIUiB5NH7hI/y nNA71mdRfo2fpfAHTc2KmGyX+F+rbsKWUhgD2CCm8BURv843JAO+5gUAzwRzJqMLhQaN qFdSx+EQxQ6Zo4gdfgs8UXM2ucIHKFhUKhT1ydZTpB30I7pU1C1sS7yw8A9svfsQaNQs 8/ZS0P9CpL8tTGCoMEv3dy3C9PX6kPPzbBOcJ6IeWl1C6+Zc56sVAMXCk/Ph2CidWRzX shnmUEJJ1Q9s1xKAPKOtTcleBqyNWzNxTBdKa4fXTTN2PdMBb81Yo4SJTMWaO51nQ7V3 7d6g== X-Received: by 10.60.40.103 with SMTP id w7mr352118oek.57.1396450674928; Wed, 02 Apr 2014 07:57:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.41 with HTTP; Wed, 2 Apr 2014 07:57:34 -0700 (PDT) In-Reply-To: References: <533AF317.5070901@cs.tcd.ie> From: Donald Eastlake Date: Wed, 2 Apr 2014 10:57:34 -0400 Message-ID: To: Sandy Harris Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/lcbZH63PhcrpYla3F-a496rsQNo Cc: "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 14:58:02 -0000 Hi, Yes, the "bad ideas" section of RFC 4086bis (draft-eastlake-randomness3-00) seems like a good place to collect additional things not to do. I am planning to update that draft soon... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Apr 2, 2014 at 10:24 AM, Sandy Harris wrote: > On Tue, Apr 1, 2014 at 1:10 PM, Stephen Farrell > wrote: > >> It seems like there's a lot of knowledge on that spread >> about and if there was someone was willing and able maybe >> an informational RFC about mistakes that have been made >> and how implementers can avoid 'em might be useful. > > I think the old RFC 1750 and current 4086 pretty much cover that. > https://tools.ietf.org/html/rfc4086 > > There has been mailing list discussion of an update to 4086, but > I do not know how that is progressing. > >> Or maybe there's a survey paper out there somewhere >> or thesis that already has a load of that material? > > At least two reference pages have been mentioned on > various lists. I have looked at two and found both quite > good. Unfortunately, I only recall one URL: > http://www.av8n.com/computer/htm/secure-random.htm > > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From nobody Wed Apr 2 08:18:41 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9500A1A0290 for ; Wed, 2 Apr 2014 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HvlaMEcy8KB for ; Wed, 2 Apr 2014 08:18:24 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BB54A1A028E for ; Wed, 2 Apr 2014 08:18:11 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so352164yho.18 for ; Wed, 02 Apr 2014 08:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M0N5rgBnNEQzA4a9BAwv45b7BRgEbCTcsH/Mru1Aq7g=; b=Z8KXsxExKfMu4oc6c6XpAqS4soV9q84njJe1bMr/8vHRMoo7ILqDn4HzUWOK7ToddV L+nHJWeC0YXFlxwjIfw/d4wBcEn55Cee0YNdc0nQf89PXPA9fu21ftGJTAwzJY7It+Tl lrQQ6IOf+RuCYdTF1odHW4Cit4O3Oxnw8Re7gz4qnmc12cCGISsSbEjK3pxKv4LFer9+ obdmHL7FLOV6EQsh+mHxR/CpPulrfHmicqzUGnm6Q3xcd/iXSIToxZ5NooESZtkObPJK MsezEgSRHaPeOEtogPhg4GvhGwf9Y51B04AW70xj1+rvEv/Vc1wtQhO9pHjAEu7wpfVf TFaA== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr1579590yhh.66.1396451887809; Wed, 02 Apr 2014 08:18:07 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 2 Apr 2014 08:18:07 -0700 (PDT) In-Reply-To: References: <533AF317.5070901@cs.tcd.ie> Date: Wed, 2 Apr 2014 08:18:07 -0700 Message-ID: From: Watson Ladd To: Donald Eastlake Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/x70SXfCnSKxBhhkIkuU0gXdLqhs Cc: "dsfjdssdfsd@ietf.org" , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 15:18:27 -0000 On Wed, Apr 2, 2014 at 7:57 AM, Donald Eastlake wrote: > Hi, > > Yes, the "bad ideas" section of RFC 4086bis > (draft-eastlake-randomness3-00) seems like a good place to collect > additional things not to do. > No. Do not enumerate badness. Instead model correct behavior. You will not be able to list all the ways someone can make a mistake, but you can explain a way to do things right. The current draft is also missing a discussion of the impact of fork and threading on random number generators, which can turn a perfectly working one into something utterly broken. Sincerely, Watson Ladd > I am planning to update that draft soon... > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Wed, Apr 2, 2014 at 10:24 AM, Sandy Harris wrote: >> On Tue, Apr 1, 2014 at 1:10 PM, Stephen Farrell >> wrote: >> >>> It seems like there's a lot of knowledge on that spread >>> about and if there was someone was willing and able maybe >>> an informational RFC about mistakes that have been made >>> and how implementers can avoid 'em might be useful. >> >> I think the old RFC 1750 and current 4086 pretty much cover that. >> https://tools.ietf.org/html/rfc4086 >> >> There has been mailing list discussion of an update to 4086, but >> I do not know how that is progressing. >> >>> Or maybe there's a survey paper out there somewhere >>> or thesis that already has a load of that material? >> >> At least two reference pages have been mentioned on >> various lists. I have looked at two and found both quite >> good. Unfortunately, I only recall one URL: >> http://www.av8n.com/computer/htm/secure-random.htm >> >> _______________________________________________ >> 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 -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Apr 2 08:45:47 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCFC1A02BF for ; Wed, 2 Apr 2014 08:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy5w_QCM-Km0 for ; Wed, 2 Apr 2014 08:45:40 -0700 (PDT) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by ietfa.amsl.com (Postfix) with ESMTP id 199C31A02C2 for ; Wed, 2 Apr 2014 08:45:35 -0700 (PDT) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id CFE0E3F756; Wed, 2 Apr 2014 08:45:19 -0700 (PDT) Date: Wed, 2 Apr 2014 08:45:19 -0700 From: travis+ml-dsfjdssdfsd@subspacefield.org To: dsfjdssdfsd@ietf.org Message-ID: <20140402154519.GA276@subspacefield.org> Mail-Followup-To: dsfjdssdfsd@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/bg-0p5lQ7mkQ69bKmd38LMqOZCI Subject: [dsfjdssdfsd] another RNG mlist X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 15:45:44 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I thought I had the only one... https://lists.bitrot.info/mailman/listinfo/rng Just found out about this (dsf) and randomness-generation via a djb article. --=20 http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS --ibTvN161/egqYuK8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (OpenBSD) iQIcBAEBAgAGBQJTPDCPAAoJEGQVZZEDJt9HUTAP/3aLs6lBOOVLyUNnOdiXHKOm QUOe838AXqhBRTB6UtxDWg+Dd8LdH/eNGlRvGgRNxEFl6ZljZ5U1/MUd5nMCQxS6 NhzuAbSC09NTvJnm1fyuWQ6RDLkciSZlTBJRDW81d3OL/DF+UU2SUbDafS3Z2WsW yivLMFVUwYTyrWrjzRK/mubhnJY9hrSY5xwjv0Wu8+GL59BxTF5Uh1UCe5m4RVDk t83aJdU+PnQHWQJtfUx/f0Xdt4Kv70h3dQteRoE2H1LMWrHm8Yx0x/JhmW8dQWGr aaUTdernmd84kcMW01TjMGfkmyr1+4w890wluxOOezNyi/jhx1BagGJV/QIYjtbn gs1MvxdS4UlPoxUNeeQgPxu6q6KiQXqsGSrV1xsvFEtQ7swfmQe2kgqKYuFD9zHU 3ZOxKwwLfDF6Uwfn/WoGqd09CvYcoSuphUUBlpnUfAOU4XEi5xcumOTngWT1IySa r0SzWGNBrnAsFQ5iDoI+Z3mgYdcDK1GC1JJ1Fn51dkHVj8A85G8TT47JhOIxgufN /l17rM8Q4fH+9OfXjeIQgwK0pfmIW+oFTVoTtsPMF9PJfyWhPO6bP95qT+PhQX5u FAPO8vSLoDQJLtjWiepjH2eryDf4KAXK44P4cKEdI2DV4MGI+3AFVXS+FOLGwn59 Kc24NJof8D3MA7fVWcii =LjYl -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From nobody Wed Apr 2 08:49:48 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD611A029E for ; Wed, 2 Apr 2014 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU4oPaudcMLL for ; Wed, 2 Apr 2014 08:49:42 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0070E1A0284 for ; Wed, 2 Apr 2014 08:49:41 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ik5so587866vcb.0 for ; Wed, 02 Apr 2014 08:49:38 -0700 (PDT) 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 :cc:content-type; bh=wfInKkg5aC3Uv01Dm/zoycxGjopCFcH6iDrGxXJo1U0=; b=FtyKjCzgey2rUwiN/gCX8taRuale5/IrEPjBoYns+9zwneDJkHOKd2RoYy195DS2lI InIUWa42Z4WR/ZHZyWEEfXJGcSx2gESH868N0DrbaXOCvXBhXxzwj9cqffdiH+cf4ECa 5aR2OcIDr0u6QyE8CBJXBZDkmjaTIFgEsgl8WW7TU9oi/8jZ7AFdwrJBUFPrD6bSD3al 9jzcgrVQKtbu6hkI4drl53YLX6T0gtIBZ1DAe6jScCErwtdlUYh1qvwQAnYujHgiV3BI 8t/1zKYZWmVYxhIsd+wP18H4nrbdvXSVjJcErscc6Om55iFoM9J5I5hX8WvatCUmUTTY Fh/w== X-Received: by 10.52.180.98 with SMTP id dn2mr1306560vdc.58.1396453777890; Wed, 02 Apr 2014 08:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.240.207 with HTTP; Wed, 2 Apr 2014 08:48:57 -0700 (PDT) In-Reply-To: References: <533AF317.5070901@cs.tcd.ie> From: Alexandre Anzala-Yamajako Date: Wed, 2 Apr 2014 17:48:57 +0200 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=bcaec51a821a60648704f6113b50 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/FTo6JBE_Ql5N61yQ1jusfENThmw Cc: Donald Eastlake , "dsfjdssdfsd@ietf.org" , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 15:49:47 -0000 --bcaec51a821a60648704f6113b50 Content-Type: text/plain; charset=ISO-8859-1 Watson, In a world where everybody would only do what they qualified for and know when to call for help I would agree with you but I think you underestimate how many well meaning people would consider that sampling the system clock is "unpredicatble enough". Listing all the ways you could mess things up is obviously a lost cause but naming a few bad ideas serves as a good cautionary tale IMO Sincerely -- Alexandre Anzala-Yamajako --bcaec51a821a60648704f6113b50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Watson,
In a world where everybod= y would only do what they qualified for and know when to call for help I wo= uld agree with you but I think you underestimate how many well meaning peop= le would consider that sampling the system clock is "unpredicatble eno= ugh".
Listing all the ways you could mess things up is obviously a lost cau= se but naming a few bad ideas serves as a good cautionary tale IMO

<= /div>Sincerely

--
Alexandre Anzala-Yamajako


--bcaec51a821a60648704f6113b50-- From nobody Wed Apr 2 08:51:24 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF81A023E for ; Wed, 2 Apr 2014 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpUYj67JWsuh for ; Wed, 2 Apr 2014 08:51:16 -0700 (PDT) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by ietfa.amsl.com (Postfix) with ESMTP id 742761A022F for ; Wed, 2 Apr 2014 08:51:16 -0700 (PDT) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 14A673F756; Wed, 2 Apr 2014 08:51:04 -0700 (PDT) Date: Wed, 2 Apr 2014 08:51:04 -0700 From: travis+ml-dsfjdssdfsd@subspacefield.org To: Watson Ladd Message-ID: <20140402155103.GB276@subspacefield.org> Mail-Followup-To: Watson Ladd , Donald Eastlake , "dsfjdssdfsd@ietf.org" , Sandy Harris References: <533AF317.5070901@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/KpW9w2A3qXHBr45gqsS1euSxAB0 Cc: Donald Eastlake , "dsfjdssdfsd@ietf.org" , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 15:51:21 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sent-To:=20 On Wed, Apr 02, 2014 at 08:18:07AM -0700, Watson Ladd wrote: > On Wed, Apr 2, 2014 at 7:57 AM, Donald Eastlake wrote: > > Hi, > > > > Yes, the "bad ideas" section of RFC 4086bis > > (draft-eastlake-randomness3-00) seems like a good place to collect > > additional things not to do. > > >=20 > No. Do not enumerate badness. Actually the PERL documentation claims that there are psychological studies that show that prohibitions stick better than instruction on correct behavior. > Instead model correct behavior. The problem with this approach is that we do not know what those are, only what has been broken. Our new designs will change based on what we learn, but what has been broken will not. Whether such instruction is appropriate for RFC or not is a valid question. > You will > not be able to list all the ways someone can make a mistake, but you > can explain a way to do things right. For current assumptions, yes. --=20 http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS --Y7xTucakfITjPcLV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (OpenBSD) iQIcBAEBAgAGBQJTPDHnAAoJEGQVZZEDJt9HDXEP/1Hi4NW6QCb5qgu1W9DXkhky +w9u4dlDemDuuvQZn++D3RBvJx1h+KlgLqP1hkIiHuFfCo4tpUJSImVgtyyA+me8 Tt4jq4lGH4TXKwGPhS9zXbwrjGucpQ0awrDK8dTvr79VSqwce3QWZMQ0LX+x4hLK 5JPszmWxsfqJBjZgbTzZ1HJ/THu2Gx3yiQerJplO1V+pPM7xUt9KdbqQwmyplp9b cxmNY4hkjoB01Wxvx/ZhF+ZCsn7mqiN44q2iym+wLKgG1UQ/rnG6ktOCbV67TdpN bKctQ+VtDJ5wRoLO2t9I4OYQ6Hl0wMcJSYC2oj3YmHy4EcCTl8JvcFEeEX4nsu0c 7H+qXZxS48pfrAOoiFMeqUC3HKl3gdxxsAMv5N+czplMJ216rR3rIluaIxXD29md QlW8+LDV2WAe2Geu3rKC30qaeQwkfQQD4D1OdAPc85YUhv5zHtbYGtrAQ8dFhzao gRMv2GDYN3IQaqktknvPA4QEXd768KM1XE1DP0tPaL+l6R38gn5Gpvw29wU8jcyP RkAY9+jcFzujn++2QMy/bA/zZM+0BQIHoUr+UpUuQa4/CpZPSXd06N1wFD2hM8Ti 016XaAt9QhlukLHx+N515mEYQ9/XOGaXT4mNzg/t/I8VX399oWtH0N3iLlOTrmmf hpPNpjdz5/F426M94n+O =5cKO -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From nobody Wed Apr 2 09:19:42 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD611A01E2 for ; Wed, 2 Apr 2014 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zs_sbA1qXHV for ; Wed, 2 Apr 2014 09:19:32 -0700 (PDT) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by ietfa.amsl.com (Postfix) with ESMTP id 481E31A02BE for ; Wed, 2 Apr 2014 09:19:32 -0700 (PDT) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 4CE223F756; Wed, 2 Apr 2014 09:19:28 -0700 (PDT) Date: Wed, 2 Apr 2014 09:19:28 -0700 From: travis+ml-dsfjdssdfsd@subspacefield.org To: Alexandre Anzala-Yamajako Message-ID: <20140402161928.GC276@subspacefield.org> Mail-Followup-To: Alexandre Anzala-Yamajako , Watson Ladd , Donald Eastlake , "dsfjdssdfsd@ietf.org" , Sandy Harris References: <533AF317.5070901@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/a_lVpq1AuTayUsv5dm0jCzZTA1A Cc: Donald Eastlake , Watson Ladd , Sandy Harris , "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 16:19:37 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 05:48:57PM +0200, Alexandre Anzala-Yamajako wrote: > In a world where everybody would only do what they qualified for and know > when to call for help I would agree with you but I think you underestimate > how many well meaning people would consider that sampling the system clock > is "unpredicatble enough". > Listing all the ways you could mess things up is obviously a lost cause b= ut > naming a few bad ideas serves as a good cautionary tale IMO I always thought that many proscriptive and prohibitive lists lack rationale, and so a few words as to why you should not do X and Y are worthy of inclusion. The risk with this is that the developer thinks, "ah, but these do not apply in my case!". Therefore, you should include a few examples that are so obscure that the developer would not have thought of them (so as to humble them intellectually), and indicate that your lists are not exhaustive, to avoid making them feel so smart that they can ignore your warnings. IMHO. When it comes to security, ignorance and hubris combined seem to be the top risk, and so it helps to demonstrate to the dev that things are not as simple as they seem right off the bat. That is best done by way of seemingly reasonable examples of previous attempts and how they failed. Lead them down a "safe" path and spring the trap on them once, and you have a much better chance of being listened to. --=20 http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (OpenBSD) iQIcBAEBAgAGBQJTPDiPAAoJEGQVZZEDJt9HdmYP/RkBYqb1MMs/iSPoXVLmpqTb x8MpYnUiQG6bjXIfL0+JFHy9T11R0+CAtQZibxkdYqqUrDfOY2WOr5Q7HfyWgCbN s8NfagYqAmu3G27ZUUBZ2VHFz0kn/T8Y6RWBC3BtxoIymT7DN1NTU+yCkWPr3Q2T 2CGi4zk+pUDj7ch7SLFAve5WQt7IcfcvyI+6Uovsz85Q6CDwzfQAmgQ4l9CP4Tjp r8B1V57mvDMrG/FLLoDiZuTejh1UYc9h5B4hKN+99psnwV6cA/gRp+Ax8LvrZXWW KDzOPp+Dx9AxwVfgNtEODAXRDQDVEsbHy7Xs5spnzTkeVJ00wLk4gDYxBvIRfLVL Mc7Di2APPcpXXX/chBZPSFYfaZJWt3FsDZP9DSK0xt5uEkXz3mysBYDdib6Xib8K HjxLff89Pdz0IPogZpJ3dWbbTWDx2N48IsjCWKxC6y6BjEukxAcm55css7bFpw0V 6idM+fYI2dZPgOnpWZl9WEN3cwdz7Cxnbq6JSSedZfGYXeY7Z/lNDPtiGI71KgK+ VbrP1h6qgsMx/Ejl4YY9VjSjESeIIcUBEVArEc7RJ2WfYoAMCozoOJ8IOdDYwuxK oD4HFKnGkzGQVV11Om/0yhVu1GqRlsfCiIAW82p6feBJSgmzQudOAEwi4ApRilRs Es8g3ydqKyJrOlWy3ugG =HQsp -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From nobody Wed Apr 2 09:34:33 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA841A01FB for ; Wed, 2 Apr 2014 09:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kONqWkgu2cJz for ; Wed, 2 Apr 2014 09:34:27 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id AAD271A01C8 for ; Wed, 2 Apr 2014 09:34:27 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1WVO6v-0001mV-BL; Wed, 02 Apr 2014 16:33:57 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id BAD35580386; Wed, 2 Apr 2014 12:33:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1396456434; bh=R9EwtLq1RNAnlhlZzjbZQC1AXJCHducqzIyVutFZtW4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0nZ4DZ8TX2L0N535GhJHe5pdJfeatXQv3RRIsoWycoGgfhC5LwQA9fpQTm2mW79s8 NmfQt47iPCyc7M2amNCJd0V2MJbp5BaZ7NvaEjUwUTYUcASml1fpmzPbI1Vl7w4fSS bM/BO4CEM0/3QJV3sBJ+BDHb0sWHIw54oFbfeYLs= Date: Wed, 2 Apr 2014 12:33:54 -0400 From: Theodore Ts'o To: Donald Eastlake Message-ID: <20140402163354.GG6901@thunk.org> References: <533AF317.5070901@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/5snKgoMYrnz2cZ6BFhydcj86jS4 Cc: "dsfjdssdfsd@ietf.org" , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 16:34:32 -0000 On Wed, Apr 02, 2014 at 10:57:34AM -0400, Donald Eastlake wrote: > Hi, > > Yes, the "bad ideas" section of RFC 4086bis > (draft-eastlake-randomness3-00) seems like a good place to collect > additional things not to do. > > I am planning to update that draft soon... Is this list the best list of have discussions about that draft? Or are you planning on using some other wg list? Some things that I might add as caveats is that the recommendations about using disk timing is based on research done decades ago, and disk drives have changed quite a bit since then. I believe there probably is *some* entropy in spinning disks, but it may not be as much as possible. In the section about clocks, it might be worthy to note that on modern CPU's, very often many clocks are derived from a single master oscillator. If there are subsystems where you have two clocks that are _not_ derived from the same oscillator, there may be an opportunity to pick up a few bits of entropy. (And I suspect that's probably one of the remaining sources of entropy from disk drives these days.) Cheers, - Ted From nobody Wed Apr 2 10:02:40 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66521A02D2 for ; Wed, 2 Apr 2014 10:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIzTqvvoJOnF for ; Wed, 2 Apr 2014 10:02:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA81A02D4 for ; Wed, 2 Apr 2014 10:02:31 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s32H2P0t084799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 2 Apr 2014 10:02:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140402163354.GG6901@thunk.org> Date: Wed, 2 Apr 2014 10:02:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> To: "dsfjdssdfsd@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/Od4S5fikVAiN1rbLmsJLGTi1txc Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 17:02:39 -0000 On Apr 2, 2014, at 9:33 AM, Theodore Ts'o wrote: > On Wed, Apr 02, 2014 at 10:57:34AM -0400, Donald Eastlake wrote: >> Hi, >>=20 >> Yes, the "bad ideas" section of RFC 4086bis >> (draft-eastlake-randomness3-00) seems like a good place to collect >> additional things not to do. >>=20 >> I am planning to update that draft soon... >=20 > Is this list the best list of have discussions about that draft? This list was created partially for the discussion of the draft. > Or > are you planning on using some other wg list? Let's hope not. > Some things that I might add as caveats is that the recommendations > about using disk timing is based on research done decades ago, and > disk drives have changed quite a bit since then. I believe there > probably is *some* entropy in spinning disks, but it may not be as > much as possible. There are many places in the draft where it uses antiquated ideas of = where to get randomness, and does not quantify them. That's why I'm = generally against updating the old RFCs at all; instead, we should start = fresh with just what are really the Best Current Practices. > In the section about clocks, it might be worthy to note that on modern > CPU's, very often many clocks are derived from a single master > oscillator. If there are subsystems where you have two clocks that > are _not_ derived from the same oscillator, there may be an > opportunity to pick up a few bits of entropy. (And I suspect that's > probably one of the remaining sources of entropy from disk drives > these days.) Personally, I have a strong hesitation of a BCP using phrases like "a = few bits of entropy" if we can't measure them and if we don't even know = if they exist. --Paul Hoffman= From nobody Wed Apr 2 10:35:01 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560051A032D for ; Wed, 2 Apr 2014 10:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORCzawV8RyyT for ; Wed, 2 Apr 2014 10:34:54 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB0B1A0242 for ; Wed, 2 Apr 2014 10:34:54 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1WVP3V-00027V-7m; Wed, 02 Apr 2014 17:34:29 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 7771F5803BC; Wed, 2 Apr 2014 13:34:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1396460066; bh=Dx/KuRfoH8CpDCKbHdseJIcOCDVnQbIt1jUn0EcM/KM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0w65It2OYHksnlmoyrgSO9N48LOt5mn+NeQyvcKTLy8nQq4+Yq1u6DI2xGZJO4rFp f6bSs6S9ElY85Mdwu6BjUirThjl+b9mTpNUUlWo2Ut1CP7d5Z0ak1JTH5xVJY7Rubl 4ykP8lCgbTli0j/J7f9R1IcyC0Sz6d6LtIjUfEkU= Date: Wed, 2 Apr 2014 13:34:26 -0400 From: Theodore Ts'o To: Paul Hoffman Message-ID: <20140402173426.GI6901@thunk.org> References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/8st-iCt_xlFCk8ekS1s6k30EjEU Cc: "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 17:34:58 -0000 On Wed, Apr 02, 2014 at 10:02:24AM -0700, Paul Hoffman wrote: > > Personally, I have a strong hesitation of a BCP using phrases like > "a few bits of entropy" if we can't measure them and if we don't > even know if they exist. One of the problems is that there is a lot of nuance which is required. For example, if you can't change the hardware, on a mobile device, one of the few sources of unpredictability might be the radio strength --- if you grab this in early boot and if you know that the values aren't being fed via centralized logging scheme. It's not really _entropy_ per se, but if you are assuming that someone sitting in Fort Meade won't know whether your cell phone is in your knapsack under the steel desk, or on top of the desk, it probably does add a certain amount of protection. Ditto grabbing touch screen information; sure, if someone has a camera surveilling you, it might not have much unpredictabiliy, but it's still probably a good thing to mix into your entropy pool. And if we try to tell people that if you can't do anything at all which is True Entropy (tm), you might as well go home, then people might just do that. - Ted From nobody Wed Apr 2 11:07:05 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9751A0326 for ; Wed, 2 Apr 2014 11:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dOeKLs9QeRH for ; Wed, 2 Apr 2014 11:06:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 130791A035C for ; Wed, 2 Apr 2014 11:06:58 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s32I6qVJ087233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 11:06:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140402173426.GI6901@thunk.org> Date: Wed, 2 Apr 2014 11:06:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> <20140402173426.GI6901@thunk.org> To: "Theodore Ts'o" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/dwnoIXuSq803EHHF82dfuHNP3qk Cc: "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 18:07:03 -0000 On Apr 2, 2014, at 10:34 AM, Theodore Ts'o wrote: > On Wed, Apr 02, 2014 at 10:02:24AM -0700, Paul Hoffman wrote: >>=20 >> Personally, I have a strong hesitation of a BCP using phrases like >> "a few bits of entropy" if we can't measure them and if we don't >> even know if they exist. >=20 > One of the problems is that there is a lot of nuance which is > required. For example, if you can't change the hardware, on a mobile > device, one of the few sources of unpredictability might be the radio > strength --- if you grab this in early boot and if you know that the > values aren't being fed via centralized logging scheme. It's not > really _entropy_ per se, but if you are assuming that someone sitting > in Fort Meade won't know whether your cell phone is in your knapsack > under the steel desk, or on top of the desk, it probably does add a > certain amount of protection. >=20 > Ditto grabbing touch screen information; sure, if someone has a camera > surveilling you, it might not have much unpredictabiliy, but it's > still probably a good thing to mix into your entropy pool. Fully agree. We should talk about possible sources, but we should be = careful to say that we are not suggesting how many bits (or fractions of = a bit) those sources produce. The implementer of the RNG is fully = responsible for making the source-to-bit-count assumptions. > And if we try to tell people that if you can't do anything at all > which is True Entropy (tm), you might as well go home, then people > might just do that. That leads into the question of who the target audience for such a = document should be. The committers for Linux and *BSD /dev/random don't = need us to create a BCP for them; the writers of a new OS or distro = might need it. An application writer should either (a) only be pulling = from their OS or (b) be as smart about random sources as the OS dev so = they can create their own pool. The eventual document needs to be very = clear which person should be reading which part. The current document is = completely unclear on this, and an application developer might think = they need to understand things that we would be horrified if they tried = to implement. --Paul Hoffman= From nobody Wed Apr 2 11:19:06 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189F41A0354 for ; Wed, 2 Apr 2014 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQt-6veBZ0mn for ; Wed, 2 Apr 2014 11:19:00 -0700 (PDT) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by ietfa.amsl.com (Postfix) with ESMTP id 508881A039D for ; Wed, 2 Apr 2014 11:18:57 -0700 (PDT) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 955133F756; Wed, 2 Apr 2014 11:18:53 -0700 (PDT) Date: Wed, 2 Apr 2014 11:18:53 -0700 From: travis+ml-dsfjdssdfsd@subspacefield.org To: Theodore Ts'o Message-ID: <20140402181853.GG276@subspacefield.org> Mail-Followup-To: Theodore Ts'o , Donald Eastlake , "dsfjdssdfsd@ietf.org" , Sandy Harris References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cp3Cp8fzgozWLBWL" Content-Disposition: inline In-Reply-To: <20140402163354.GG6901@thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/QcBvlhhDt25xBZpb2VX7B4IFT-o Cc: Donald Eastlake , "dsfjdssdfsd@ietf.org" , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 18:19:04 -0000 --Cp3Cp8fzgozWLBWL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 12:33:54PM -0400, Theodore Ts'o wrote: > Some things that I might add as caveats is that the recommendations > about using disk timing is based on research done decades ago, and > disk drives have changed quite a bit since then. I believe there > probably is *some* entropy in spinning disks, but it may not be as > much as possible. And then there's SSDs. > In the section about clocks, it might be worthy to note that on modern > CPU's, very often many clocks are derived from a single master > oscillator. If there are subsystems where you have two clocks that > are _not_ derived from the same oscillator, there may be an > opportunity to pick up a few bits of entropy. (And I suspect that's > probably one of the remaining sources of entropy from disk drives > these days.) You have to be careful in many cases things look random but are not to someone with the right insight (c.f. whitening); measurement is not enough. Quoting Clive Robinson on a common HWRNG design in chips: Faux entropy consists of many things including the outputs of complex processes and chaotic processes inherant as side effects of the design process. One example of which is to have two free running oscillators one running at high speed into the D input of a D-type latch and the slower one going into the clock input of the D-type. Close in observation of the Q output of the latch shows both metastability and what appeares as random behaviour. However observation at a slower time base shows "bunching" patterns that corespond on the timebase to the lowest frequency difference of the two oscilators. And in fact if driven into a suitable counter circuit will produce a sinusoudal output count... Taking what is in effect an FFT of the random source output will show up this determanistic wave, only if it is within the FFT Window range... --=20 http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS --Cp3Cp8fzgozWLBWL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (OpenBSD) iQIcBAEBAgAGBQJTPFSMAAoJEGQVZZEDJt9HbysP/0+Y7CVwVpaqdE14PjhfLrwQ cjEwD4yJhTZK1/HEe0lVn+Pqdgl1MTD4us2CAcSv8WQ508NmD6X0vcaILPSG3fEe vhZiHsIPnh237S3XAJ9f0sWR2T4J3i1nBCimNC7zXyvAkCIZlBI9TPUxez5Jr4VO ydvAil0+lVrKmtCyn53lmbuN5NSYJr7h/OrSazMZUp5gqXS1Etnvnrk0YMCODbf+ mL2eBwUciQ1sH8VqEqfCnBfsSiuImwDonsDulFSHIj7NETNPsh/00POIzNd5u+ol 5YdnnIOUFwq9er7Zp4IJRLYzpfiHEkhmacH75EZh29rozJChAIuQY4HkWrzIfP1h 9Jt1104v2ZtLuU7kSvRNTGf9Hfi3gGmgzWtdgLVkyMVIXUFxOJAJTQa8qxjUIe5o WZUSDKrKnRXdwPObZdDwu9ckLtBR3ItuW3Xwx4pIjL/KxXmTyKcYydTfdjeRaUzC 5CFTUY4LpK394Cp+d42zEmPVTxg/kuYd6TeDDIoXNMjIO8kk65RiTmOUPNUkPIiD i+MoUMQqcIB7/5cEsmJUo2AjhXdE8ETrWqs7Ki8mgyqlvFTkGUTMAvkhVrNkZi8f +cpc/kSN7Ixp3X9x13fKd6e/8bz7FTVy+MFdgKVknudYscnhxJEb6C3t5ZZplmYV /eUrP+HJqR2hNrR6VW+x =B5cC -----END PGP SIGNATURE----- --Cp3Cp8fzgozWLBWL-- From nobody Wed Apr 2 11:19:24 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DF91A03AD for ; Wed, 2 Apr 2014 11:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFUig59RxXh3 for ; Wed, 2 Apr 2014 11:19:07 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4881A0388 for ; Wed, 2 Apr 2014 11:19:04 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id l6so702869oag.25 for ; Wed, 02 Apr 2014 11:19:00 -0700 (PDT) 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 :cc:content-type; bh=vy4vSNR14gY6Lo4PYNCG3kpvyhfuazLa9jtmgepGwlg=; b=dLrxYEpR2vBEocqzVT6Ivvnphsd7iky95TLXUOzjVavyKJvhNjmXtukqUflI/9lvBC 6dOBNmTxDCjDi9Aiu7QgA9cQHSrFqp25+xfyYstbkuIYH4tFRlGF7fybwEZphVpXp/HX Ukq1GyKoCqNLS7wQ1FCZaSTdzuO4UTwQNQ9vcQ4SJX51JfDixavzLjQwSVE1YgigvECx LbR56bIrlebpqv/RW84flgtTKnhoFwOs45a2X+JvYEwbhPGxWTVarUbGNE5psJ2dyymw ZzJZGwDLUjjXvrG5QKWqgfmOpN6ys5xTMjfeCfR49jXjQjGSiGdjgc5LoMIPt49B3U5l eYpg== X-Received: by 10.60.132.12 with SMTP id oq12mr1371638oeb.42.1396462740342; Wed, 02 Apr 2014 11:19:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.41 with HTTP; Wed, 2 Apr 2014 11:18:40 -0700 (PDT) In-Reply-To: References: <533AF317.5070901@cs.tcd.ie> From: Donald Eastlake Date: Wed, 2 Apr 2014 14:18:40 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/Vbg94cvsJtFxcANnSzwv7UXK1C4 Cc: "dsfjdssdfsd@ietf.org" , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 18:19:11 -0000 On Wed, Apr 2, 2014 at 11:18 AM, Watson Ladd wrote: > On Wed, Apr 2, 2014 at 7:57 AM, Donald Eastlake wrote: >> Hi, >> >> Yes, the "bad ideas" section of RFC 4086bis >> (draft-eastlake-randomness3-00) seems like a good place to collect >> additional things not to do. >> > > No. Do not enumerate badness. Instead model correct behavior. You will No, yourself. We had this same discussion before RFC 1750 and before RFC 4086. I would agree that it should emphasize the right thing to do more than it emphasizes the wrong thing to do. And I'd be fine with relegating what not to do to an appendix or something. But I'm not willing to dump the information from the draft about what not to do. > not be able to list all the ways someone can make a mistake, but you > can explain a way to do things right. The current draft is also > missing a discussion of the impact of fork and threading on random > number generators, which can turn a perfectly working one into > something utterly broken. Yes, there are things missing that should be added. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Sincerely, > Watson Ladd > >> I am planning to update that draft soon... >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> >> On Wed, Apr 2, 2014 at 10:24 AM, Sandy Harris wrote: >>> On Tue, Apr 1, 2014 at 1:10 PM, Stephen Farrell >>> wrote: >>> >>>> It seems like there's a lot of knowledge on that spread >>>> about and if there was someone was willing and able maybe >>>> an informational RFC about mistakes that have been made >>>> and how implementers can avoid 'em might be useful. >>> >>> I think the old RFC 1750 and current 4086 pretty much cover that. >>> https://tools.ietf.org/html/rfc4086 >>> >>> There has been mailing list discussion of an update to 4086, but >>> I do not know how that is progressing. >>> >>>> Or maybe there's a survey paper out there somewhere >>>> or thesis that already has a load of that material? >>> >>> At least two reference pages have been mentioned on >>> various lists. I have looked at two and found both quite >>> good. Unfortunately, I only recall one URL: >>> http://www.av8n.com/computer/htm/secure-random.htm >>> >>> _______________________________________________ >>> 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 > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin From nobody Wed Apr 2 11:32:26 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4BB1A0368 for ; Wed, 2 Apr 2014 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHGT4y0wyGax for ; Wed, 2 Apr 2014 11:32:19 -0700 (PDT) Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by ietfa.amsl.com (Postfix) with ESMTP id C73811A0374 for ; Wed, 2 Apr 2014 11:32:19 -0700 (PDT) Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 1878C3F756; Wed, 2 Apr 2014 11:32:16 -0700 (PDT) Date: Wed, 2 Apr 2014 11:32:16 -0700 From: travis+ml-dsfjdssdfsd@subspacefield.org To: Theodore Ts'o Message-ID: <20140402183216.GH276@subspacefield.org> Mail-Followup-To: Theodore Ts'o , Paul Hoffman , "dsfjdssdfsd@ietf.org" References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> <20140402173426.GI6901@thunk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kHRd/tpU31Zn62xO" Content-Disposition: inline In-Reply-To: <20140402173426.GI6901@thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/VQbdAULtoEpLQtkVhXgBI6TMIrU Cc: "dsfjdssdfsd@ietf.org" , Paul Hoffman Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 18:32:24 -0000 --kHRd/tpU31Zn62xO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 01:34:26PM -0400, Theodore Ts'o wrote: > One of the problems is that there is a lot of nuance which is > required. For example, if you can't change the hardware, on a mobile > device, one of the few sources of unpredictability might be the radio > strength --- if you grab this in early boot and if you know that the > values aren't being fed via centralized logging scheme. It's not > really _entropy_ per se, but if you are assuming that someone sitting > in Fort Meade won't know whether your cell phone is in your knapsack > under the steel desk, or on top of the desk, it probably does add a > certain amount of protection. >=20 > Ditto grabbing touch screen information; sure, if someone has a camera > surveilling you, it might not have much unpredictabiliy, but it's > still probably a good thing to mix into your entropy pool. >=20 > And if we try to tell people that if you can't do anything at all > which is True Entropy (tm), you might as well go home, then people > might just do that. In the movie "The Sting", horse race results are delayed to allow betting-after-the-fact; this demonstrates that with the knowledge you have after its disclosure, unpredictability no longer exists. So philosophically, all unpredictability is measured relative to some knowledge set. As a pragmatic exercise we can measure an upper bound on entropy (using min-entropy) based on what we assume are standard assumptions, but we don't know what we don't know. Which is an interesting parallel to computational security assurances. http://www.subspacefield.org/security/security_concepts/index.html#toc-Sect= ion-29 BTW, hello Paul, nice list :-) --=20 http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS --kHRd/tpU31Zn62xO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (OpenBSD) iQIcBAEBAgAGBQJTPFevAAoJEGQVZZEDJt9HkxYQAK/7e7mOUJ/zhcQAv5zcseqe HreJNAuqjlN3vDc+IoOWCvQXs3J8/DcCuKGA2OhCrZea0L9I4J8KLHSmZfGtFEFw 2/VB3G+3bEqAasNtK2a0UgtsWpqOQkyA4ZRRv8t3vOSh5ZyOLx7VG049wGy4G8O6 J9s8pRryJ36xyXYy0ril6uNZqOpXfTm4ACUXsZ1Oz29ne9X2Mm2a2fhkQPBmJvLm A8yfCEk20ZbTFrcD+3F10EAiObBeEBtzjvpCI6g3jNG88ukpjS6xtko0hGxhIxFa x9L6DdyAH2+Nu0Jp1rRwy3GaoHLJf1xbUJ8HDe7Su88WdDI0CtIgT0/gX4MyeGY8 6j1IXrze5x3EosCZPaHu0InhehEe2+1EMKdixC7zZk6ucBNSjSssMkJhSZE+yq11 0hodtFJciAzYfym8FVg8xeBy9yBs6D6T8wsUTvTgJEJtS9lw4PxFmdln2uBQ7E2w FT30t2dtiTWikY2bNuwPyYXgsdJoHTRLAmR6qsKX/zCPbt3QWIP4Pt4scBH5JSoU ZbKRVodnHAGXl7/eYbxO3etOo7fX4sTj5S3D2I22NAJK3q1c5b4u8iQoPUc6ebVs FK4+mqtT7i6q3+vK5CKrdOyxC4mEXG/Irx/mBgjDPfaoNPZZmNgdTixwfmET7TFj EBGD5lf+ZWZhD2vFTXxv =usOZ -----END PGP SIGNATURE----- --kHRd/tpU31Zn62xO-- From nobody Wed Apr 2 11:32:49 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1D51A0370 for ; Wed, 2 Apr 2014 11:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xySuLEQ-24wB for ; Wed, 2 Apr 2014 11:32:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 72F9C1A0368 for ; Wed, 2 Apr 2014 11:32:41 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 84BA0A888016; Wed, 2 Apr 2014 11:32:37 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Apr 2014 11:32:37 -0700 (PDT) Message-ID: <8a6e62d4203569639dbc6dededf3af9a.squirrel@www.trepanning.net> In-Reply-To: References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> <20140402173426.GI6901@thunk.org> Date: Wed, 2 Apr 2014 11:32:37 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/9tiIdYfnfJuGQMd8J9eXKMPj6EI Cc: "dsfjdssdfsd@ietf.org" , Theodore Ts'o Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 18:32:46 -0000 Hi Paul, On Wed, April 2, 2014 11:06 am, Paul Hoffman wrote: > On Apr 2, 2014, at 10:34 AM, Theodore Ts'o wrote: > [snip] >> And if we try to tell people that if you can't do anything at all >> which is True Entropy (tm), you might as well go home, then people >> might just do that. > > That leads into the question of who the target audience for such a > document should be. The committers for Linux and *BSD /dev/random don't > need us to create a BCP for them; the writers of a new OS or distro might > need it. An application writer should either (a) only be pulling from > their OS or (b) be as smart about random sources as the OS dev so they can > create their own pool. The eventual document needs to be very clear which > person should be reading which part. The current document is completely > unclear on this, and an application developer might think they need to > understand things that we would be horrified if they tried to implement. The idea that linux and BSD developers know what they're doing and application writers should just use their OS is an appeal to authority that I think is increasingly falling on deaf ears these days. If you listened to the experts at Intel you'd have just used their RNG because they know what they're doing. But it turns out a hardware trojan can reduce the entropy from their RNG to whatever the attacker wants it to be. Oops. Which is not to say that I think the people writing the RNGs for linux and BSD do not know what they're doing, or that I know better (I certainly do not). Donald is updating an existing RFC and I think the target audience for his update is the same as that of the existing RFC. My hope is that another draft will be written that specifies a strong RNG and the target audience for that would be people writing security code, especially for embedded OSs that have a more blurred line between kernel and application. regards, Dan. From alexandre.carmel@miniguru.ca Wed Apr 2 11:30:58 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05121A03A2 for ; Wed, 2 Apr 2014 11:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HeOsOYSWSEY for ; Wed, 2 Apr 2014 11:30:54 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 26AE81A0374 for ; Wed, 2 Apr 2014 11:30:54 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so662667wes.39 for ; Wed, 02 Apr 2014 11:30:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gj0Ysd0QzEnLocxePtD1nVR5xzlWBFdwtTTpVa8EKTM=; b=UfdCDCRPsWKvGnjhiuq4y6Y+3pTKcD2apqoUANYGi1K/enMCMes96H8MvznCTFh0Um zePFOVmqGr3LVQaHdONmRVOI7ZlsqseEP4c82YVEwJYmeqH5xLBJi5nYMna/D4HLN+hA M8CRBVM/AdyTmihHeeKBE7gwgRVzo6Q0fplQDLoY02HqfgEzLhqMAWfoOPDOPEqdNYj1 TvIitp8bK6r++IPWemGHph43uNUxXj8xQw8aucq7WvvyNKWD1Td8mpp++k9DynpMNa2h P41X+GxjpYvseJ78P32slMpy+/TpSBLtnExpkKynPEa4uPm4ggTOUOxo+1AhQbII8L5G iZpg== X-Gm-Message-State: ALoCoQl4pIVXTZHGKk5MSnR9CB2kONhd2i7BKz4DvTVKcB3+ZjuMs7f32ETwv9xFPjELIbqzZ61a MIME-Version: 1.0 X-Received: by 10.180.182.166 with SMTP id ef6mr4077937wic.29.1396463449678; Wed, 02 Apr 2014 11:30:49 -0700 (PDT) Sender: alexandre.carmel@miniguru.ca Received: by 10.194.173.168 with HTTP; Wed, 2 Apr 2014 11:30:49 -0700 (PDT) X-Originating-IP: [67.69.227.99] In-Reply-To: References: <533AF317.5070901@cs.tcd.ie> Date: Wed, 2 Apr 2014 14:30:49 -0400 X-Google-Sender-Auth: tLITUhQfxIk8iFnvz-fJbLQ2yH4 Message-ID: From: Alexandre Carmel-Veilleux To: Donald Eastlake Content-Type: multipart/alternative; boundary=089e016347fcdc3d4a04f6137b62 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/Jf7VKzkkp7nKgZU_uSjAQjYJGEE Cc: "dsfjdssdfsd@ietf.org" , Watson Ladd , Sandy Harris Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 18:32:57 -0000 --089e016347fcdc3d4a04f6137b62 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Apr 2, 2014 at 2:18 PM, Donald Eastlake wrote: > > We had this same discussion before RFC 1750 and before RFC 4086. I > would agree that it should emphasize the right thing to do more than > it emphasizes the wrong thing to do. And I'd be fine with relegating > what not to do to an appendix or something. But I'm not willing to > dump the information from the draft about what not to do. I totally agree. A list of known bad practices can provide ammunition to the poor software engineers out there to convince management that fixing the RNG in $PRODUCT is warranted. Deviance from current best practices is often not enough to sell software development with no revenue potential to MBA types. My 2 cents from working for an enterprise software vendor. Alex --089e016347fcdc3d4a04f6137b62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --089e016347fcdc3d4a04f6137b62-- From nobody Wed Apr 2 12:10:41 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53071A03B3 for ; Wed, 2 Apr 2014 12:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToZX5XhCkCiA for ; Wed, 2 Apr 2014 12:10:36 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id B9E011A03B1 for ; Wed, 2 Apr 2014 12:10:36 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1WVQYR-0002j0-6o; Wed, 02 Apr 2014 19:10:31 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 80C6F5803BC; Wed, 2 Apr 2014 15:10:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1396465828; bh=sAMB6SavwmPvHdFpQGrNtJbv3JXPYSFPnevY/qhnxSE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aEjaCuXG+C8cPFJpG71MirFLjJqAomwxVfb5bk+4F/ZG7ahDR8swvVmFOQIXySTdv qagzPMtkzLMtmoTExZ34JsVfGcivFW/BDqOrHwRevCCS/iapDWrKdV4WKqK8+dwKnl tEyxSp2I+JtgmEMpeKg1aLd9tpa3T8T7A9qJTfGw= Date: Wed, 2 Apr 2014 15:10:28 -0400 From: Theodore Ts'o To: Dan Harkins Message-ID: <20140402191028.GN6901@thunk.org> References: <533AF317.5070901@cs.tcd.ie> <20140402163354.GG6901@thunk.org> <2804DA89-211B-4876-A773-A17D6AE8463F@vpnc.org> <20140402173426.GI6901@thunk.org> <8a6e62d4203569639dbc6dededf3af9a.squirrel@www.trepanning.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a6e62d4203569639dbc6dededf3af9a.squirrel@www.trepanning.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/1241ekojpQa4U2ESWgSHiwB8oVA Cc: "dsfjdssdfsd@ietf.org" , Paul Hoffman Subject: Re: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 19:10:41 -0000 On Wed, Apr 02, 2014 at 11:32:37AM -0700, Dan Harkins wrote: > > Donald is updating an existing RFC and I think the target audience for his > update is the same as that of the existing RFC. Well, the current language doesn't say who is the intended audience, and the there may be people who will be reading this that aren't who we think should be the intended audience. So being explicit about this might be good. (BTW, what do *you* think the target audience of the current text is?) It might also be good to have some explicit advice for different audiences. For example, "If you are a SOC designer, you should include a hardware RNG, and please see FOO_REFERENCE for details about how to create a competent hwrng." Or, "If you are an application programmer, and your system has a random number facility, then unless there is a really good reason not to, you should probably use the OS's rng instead of trying to roll your own (since you probably will get it wrong). Alternatively, if your crypto library has a RNG, you should use that, so long as it is documented to be for cryptographic purposes and you have initialized it properly per its instructions." > My hope is that another draft will be written that specifies a strong RNG > and the target audience for that would be people writing security code, > especially for embedded OSs that have a more blurred line between kernel > and application. There's an awful lot in Donald's current text which covers this particular area already. In fact, I'd be really worried if other audiences (i.e., application programmers) were going to try to measure disk timing in their application code per the instructions in RFC 4086. So I'm not sure it makes sense to have two different drafts. I'd suggest being explicit about which pieces of its advice is more suitable for different audiences. Cheers, - Ted From nobody Wed Apr 2 18:25:25 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96CD1A0048 for ; Wed, 2 Apr 2014 18:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZMH4_VdjKKT for ; Wed, 2 Apr 2014 18:25:18 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 592CC1A0043 for ; Wed, 2 Apr 2014 18:25:18 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id 63so1065772qgz.6 for ; Wed, 02 Apr 2014 18:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dMMpkVYC5n9XRYniGG0/pIjXcD+aXZiSFU3glPnbl3I=; b=o5i0fW3HYvbXSvLDMOgbet0HZIKswaHOPjx6RfNllrLYUo3mjbhJRGhGfH0/9J2Yna F5Crhi3cF8GkjZJP+JD2+z59I230h25LogcPzPl+fzXKVVSy3Filz6BMmm4+imrFgXjc vPhnFyRQ7ExDEEOUoLwoN+fFhiVBos+jggLAdYQJ91BlOFZrLo9M5imZVTNVTgusYM1w 1hf3ITsSSiOojXrEt3xGD+JP1M14X1U9DsTnEyR/IRimBdkaCAyR7/GY0YFt0mCO9YC9 arvs7xKU7fRZIslrfeZ0Mn4BNCAhWa6VgtfXeFOs43tj7D0PwlkKqvzj8V8BSUd5jbHh 91rg== MIME-Version: 1.0 X-Received: by 10.140.109.132 with SMTP id l4mr4137431qgf.72.1396488314126; Wed, 02 Apr 2014 18:25:14 -0700 (PDT) Received: by 10.140.21.197 with HTTP; Wed, 2 Apr 2014 18:25:14 -0700 (PDT) Date: Wed, 2 Apr 2014 21:25:14 -0400 Message-ID: From: Sandy Harris To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/fhgaxwYIpiD4tU_hG8hwVzZM4Js Subject: [dsfjdssdfsd] what not to do... X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Apr 2014 01:25:24 -0000 Watson Ladd wrote: > ... The current draft is also > missing a discussion of the impact of fork and threading on random > number generators, which can turn a perfectly working one into > something utterly broken. An otherwise fine RNG may also have serious problems when run in a virtual machine. I think there are a whole lot of tricky issues there. From nobody Wed Apr 2 18:47:51 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5211A0436 for ; Wed, 2 Apr 2014 18:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofjI_WqgiS7f for ; Wed, 2 Apr 2014 18:47:44 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 600761A0447 for ; Wed, 2 Apr 2014 18:47:44 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hw13so990238qab.4 for ; Wed, 02 Apr 2014 18:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+QlME1fWZo5x2zTV1K0EiKbo9XE14QEBpSYjMo8NFBs=; b=O5s6UdcucT42YtrRWZ7ABuSAvARANUWt2bb2TInyMNsUbQKClwgq+AlU0yDmHdTheg wr2J07L4NFTpB6Lg7hSwjKU80BtI1pdTyUPP+xh/4f16OP1cb6GuTNL772kGvnDp+QYQ 7NRbafN6Q3NUB76/l17v1rNRSwmoP+JzshKMMY/H2ywH69/3Wva2ZnEFI3w/gN0PCNMo 6lvCuoBMXX3ZvQ9q5MyiYwAxYDo/qPynsOks0RnQM7e0265I73mYkB+pacJxIKnve/Zg +BcKm1wBfDZpMbMXf3tzqBCr/7r4i4/An8hXBJALq0WVivjox662gjt3iS05JeL56Yd0 moxA== MIME-Version: 1.0 X-Received: by 10.224.57.142 with SMTP id c14mr4432064qah.23.1396489660088; Wed, 02 Apr 2014 18:47:40 -0700 (PDT) Received: by 10.140.21.197 with HTTP; Wed, 2 Apr 2014 18:47:40 -0700 (PDT) In-Reply-To: <20140402154519.GA276@subspacefield.org> References: <20140402154519.GA276@subspacefield.org> Date: Wed, 2 Apr 2014 21:47:40 -0400 Message-ID: From: Sandy Harris To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/HN3iG92mrPuqr3c83XyRbR1cdh8 Subject: Re: [dsfjdssdfsd] another RNG mlist X-BeenThere: dsfjdssdfsd@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 03 Apr 2014 01:47:49 -0000 On Wed, Apr 2, 2014 at 11:45 AM, wrote: > I thought I had the only one... > > https://lists.bitrot.info/mailman/listinfo/rng > > Just found out about this (dsf) and randomness-generation via a djb > article. Those are the only two I know of that focus mainly on these issues. However, there are discussions of some related things on at least: For Linux, at least the Linux kernel and Linux crypto lists. Probably similar lists for various BSDs, and for all I know there are lists for Windows or Mac. Two general crypto lists: http://www.metzdowd.com/mailman/listinfo/cryptography http://lists.randombit.net/mailman/listinfo/cryptography and some related discussion on a mainly politics-of-crypto list: http://www.cypherpunks.to/list/