From nobody Tue Jul 1 06:23: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 888F61A02F7 for ; Tue, 1 Jul 2014 06:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 nZybhqFmYNKL for ; Tue, 1 Jul 2014 06:23:12 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A983B1A02F8 for ; Tue, 1 Jul 2014 06:23:12 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s61DNArG078294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 1 Jul 2014 06:23:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> Date: Tue, 1 Jul 2014 06:23:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> To: dsfjdssdfsd@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/-EfCEBWsF7x7lAwOV3AcF3YQ8O4 Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? 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 Jul 2014 13:23:17 -0000 I sent the following message over six months ago, but the draft was not = updated, and instead expired. Are people on this list interested in starting a different draft that = obsoletes 4086 by giving more modern advice? I would be willing to edit = but not contribute a lot of text; others here might want to contribute = lots of text. --Paul Hoffman On Jan 20, 2014, at 5:28 PM, Paul Hoffman wrote: > On Jan 20, 2014, at 5:53 PM, Donald Eastlake wrote: >=20 >> I've been a bit snowed under just recently and this week but I have >> accumulated some changes and suggestions on the randomness = requirement >> sod security draft and do plan to do a revision soon. >=20 > It would be good to see those revisions. It still feels very wrong for = us to be suggesting to application developers that they should be doing = their own randomness; they should be asking their OS unless they are = experts, and those experts don't need an RFC. From nobody Mon Jul 14 19:54:38 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 0B0921B2801 for ; Mon, 14 Jul 2014 19:54:36 -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 LySjX2Oc18Cn for ; Mon, 14 Jul 2014 19:54:34 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936711B27FD for ; Mon, 14 Jul 2014 19:54:34 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id t59so1153787yho.39 for ; Mon, 14 Jul 2014 19:54:34 -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=eC1Yzb7U5dHpQy3rBZIbBhFBKhgJWsqy8aZeumeNemg=; b=XHYkISSnqW5ad3kz6kuLpdNazLswWDkv9qpfL951U2x0OUg5YGAIq5p2nJadF1hn7n o1YfINtclSBXk+AtGEkIwSdSAlYdy73kGZaGsaMkQKUGZlVLEiyvakCszz7v9HKGoG+2 IJhdyUxC7XadK0cdqLynHjsCbJ5so5ube1N1wdpD4nksYXvVfJnUGWac1QnNKcwPMoss ySa0GMZzsbtZfazTC1gsU8hLncPOOBItjL2Y7Qnm7uME3ClFCYQhF4VFCTyp5xKzUowS IIC+NvuFeimgng77rllZEtRn1cIipnM9/pZV23HFsKA7mAXUwXZMjqgOsvxJe0sag6KZ jcsg== MIME-Version: 1.0 X-Received: by 10.236.37.97 with SMTP id x61mr34602758yha.87.1405392873855; Mon, 14 Jul 2014 19:54:33 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 14 Jul 2014 19:54:33 -0700 (PDT) Date: Mon, 14 Jul 2014 19:54:33 -0700 Message-ID: From: Watson Ladd To: "dsfjdssdfsd@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/b3wP2WgsOvUfmM0KclU_Xi2Klc4 Subject: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 02:54:36 -0000 Dear all, The absence of getentropy(2) on Linux is a major pain point for everyone. It turns out that chroot jails are not compatible with /dev/urandom. which doesn't work on linux anyway (because it will return junk before initialization). As a TLS developer myself (slowly!) I feel that pain: random number generation is the single nastiest problem I have to deal with. Yes, this is different from the usual IETF standard. But application and library developers need a portable way to get entropy, and that has to be the same across all platforms, work every time. Nothing short of a standard system call will work. Perhaps there is a more appropriate venue like the Open Group or POSIX or the Cxx committee (no doubt C++ will happily adopt it: a feature not in C++ is always a bug). That's all I need: a platform and hardware independent means to get some random numbers. Sincerely, Watson Ladd From nobody Tue Jul 15 01:25:17 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 C16D61B283F for ; Tue, 15 Jul 2014 01:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651, 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 sOzSAuJazkPw for ; Tue, 15 Jul 2014 01:25:13 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA881A0343 for ; Tue, 15 Jul 2014 01:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=b4Wk4yw8kiVdSTgMIcffXLInE9fIqxqA5g6uauS7C4Q=; b=mnm0rBD8Cmw8ljg7zxg5aT13pwd9bP7f1PhYlB4sQoRnoRTXLnqSs/8kuMWnbv690/V3x4TVGRMQhXWdNbtWsA6GgEI5d/3PDVOfZsdGPP0xt8Pq1dI37WMqvmlY+UHoo/6MBzuy/zrKcr2FQkfi7om1Y5q538hF9iKggiR/qPk=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1X6y2x-00059U-5t; Tue, 15 Jul 2014 08:25:11 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 4DE19580372; Tue, 15 Jul 2014 04:25:07 -0400 (EDT) Date: Tue, 15 Jul 2014 04:25:07 -0400 From: Theodore Ts'o To: Watson Ladd Message-ID: <20140715082507.GA1451@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.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/goaD_1yM1IPQpOx2iaWiae2VwEI Cc: "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 08:25:16 -0000 On Mon, Jul 14, 2014 at 07:54:33PM -0700, Watson Ladd wrote: > Dear all, > > The absence of getentropy(2) on Linux is a major pain point for > everyone. It turns out that chroot jails are not compatible with > /dev/urandom. which doesn't work on linux anyway (because it will > return junk before initialization). As a TLS developer myself > (slowly!) I feel that pain: random number generation is the single > nastiest problem I have to deal with. I've been talking to Bob Beck about this; and I'm not really convinced how important the presense or lack of getneoptry(2) really is. A couple of high points about our conversation: 1) The question of what to do if /dev is not properly set up is a bit of a red herring. The OpenBSD folks have said that this is not a high priority for them. My perspective is that given that the ELF loader requires that /dev/null be present so it can mmap in zero pages, worrying about what to do if /dev is not properly set up is probably not that big of a deal, and aborting if /dev/[u]random is not present is probably the right thing to do. 2) OpenBSD's primary concern is to protect against the case when the attacker has consumed all available file descriptors, so the attempt to open /dev/[u]random fails. Whether this is something that justifies a new system call is a bit of a philosophical question. After all, if the system is under such an attack, it's likely that many other things will fail, and so failing hard may be better than failing in a soft fashion. There may be other portions of the system that aren't properly checking for these sorts of failure. For example, are applications or libraries that try opening files such as /etc/hosts.deny, if they receive an error, are they distinguishing between ENOENT and EMFILE or ENFILE? Or are the applications just saying, "gee, open("/etc/hosts.deny", O_RDONLY) returned -1, all is good, let's proceed"? So points (1) and (2) means that from a philosophical point of view, you can certainly make the argument that it's actually better to try opening /dev/[u]random, and if it fails for any reason, it's better to hard fail the application with a LOG_ERR or LOG_CRIT syslog followed by an abort() call. 3) OpenBSD's man page for getentropy(2) talks about "seed grade" entropy, but this is a bit of a misnomer for those people who are obsessed about the difference between a DRBG and NRBG in SP 800-90A speak. Hence, getentropy(2) is non-blocking, and in practice, never fails (or at least applications are written assuming that it non-blocks and never fails). I'm willing in practice to try seeing if I can get consensus for adding a system call that works like getentropy(2). I'm probably going to add a flags field so that the application can select between a blocking /dev/random read versus a non-blocking /dev/urandom read. However, it's not clear that enough people will believe that adding a system call just to justify allowing the userspace arc4random pool to be able to initialize, only to have some other part of the application fail due to a file open failing, or worse, silently compromising security due to an open of some file such as /etc/hosts.deny failing, is really worth adding a whole new system call. > Yes, this is different from the usual IETF standard. But application > and library developers need a portable way to get entropy, and that > has to be the same across all platforms, work every time. Nothing > short of a standard system call will work. Perhaps there is a more > appropriate venue like the Open Group or POSIX or the Cxx committee > (no doubt C++ will happily adopt it: a feature not in C++ is always a > bug). What I'd much rather see is a standard library that *all* applications can rely upon and use to get entropy. I don't trust most application programmers to write a userspace library correctly. One approach is to simply advise all applications to use something like getentropy(2) directly --- even if all that is needed is random padding or IV's. The problem is that if you do this, for systems that are trying make some kind of distinction between DRBG and NRBG, you can very quickly exhaust the supply of hardware-derived entropy. I accept that there is significant disagreement about whether such differences should be made, but to the extent that Intel felt it was necessary to add an RDSEED instruction as well as RDRAND, it's clear that the difference is something that at least some people care about. And I suspect it's unfair to say that the only people who care are the crazies^H^H^H^H^H^H^H engineers who think that FIPS certification makes any sense other than a purely commercial one (i.e., being able to sell to the US Government). But if we get all applications to use the same library, we can abstract away not only differences in operating system but also security policies vis-a-vis DRBG/NDRBG blocking/nonblocking. So what *I* would prefer is a library interface where the application declares what it wants the random numbers for: * Monte carlo simulations * Padding * IV * Session key * long-term key etc. The library can then decide whether or not the overall system policy should force application to block when generating long-term keys, ala gpg, or whether it should getting non-blocking entropy directly from the kernel, or whether using a userspace DRBG which is initialized from kernel-supplied entropy is the right answer. Basically, I don't want to leave this choice up to the application writer, since many application writers won't be competent to make this choice, and having consistency across different applications which are conform to the organization's designated security officer seems to be something that at least some organizations would want. Cheers, - Ted From nobody Tue Jul 15 05:39:17 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 5C71A1B287B for ; Tue, 15 Jul 2014 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 2P3M3PlP2TVG for ; Tue, 15 Jul 2014 05:39:12 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F0C1B285F for ; Tue, 15 Jul 2014 05:39:12 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-8b-53c520ef32c2 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 67.0E.24022.FE025C35; Tue, 15 Jul 2014 08:39:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6FCdA0S008173; Tue, 15 Jul 2014 08:39:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6FCd8mI014351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2014 08:39:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6FCd7Xx020329; Tue, 15 Jul 2014 08:39:07 -0400 (EDT) Date: Tue, 15 Jul 2014 08:39:07 -0400 (EDT) From: Benjamin Kaduk To: "Theodore Ts'o" In-Reply-To: <20140715082507.GA1451@thunk.org> Message-ID: References: <20140715082507.GA1451@thunk.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrfte4WiwwfzD3BZ3VktY3O/qYnZg 8liy5CeTR8v+a2wBTFFcNimpOZllqUX6dglcGbP+HGQtWMJVcfPGIvYGxpUcXYycHBICJhJz L79mhbDFJC7cW88GYgsJzGaS6L0l2MXIBWRvZJQ4u24vVOIQk8T/JSEQiQZGiQ2vlzKBJFgE tCXu/vwMVsQmoCIx881GMFtEQFni2LIHYDazgKHEg4aNQNs4OIQFNCT+PfUDCXMK6Em0vG9h AbF5BRwldjf+YoTYVSQx5+0csONEBXQkVu+fAlUjKHFy5hMWiJGWEv/W/mKdwCg4C0lqFpLU AkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbqGermZJXqpKaWbGMFBKsmzg/HNQaVDjAIcjEo8 vBLvDgcLsSaWFVfmHmKU5GBSEuUtZjsaLMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEt/7fkWAh 3pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IErykwGoUEi1LTUyvSMnNK ENJMHJwgw3mAhkuB1PAWFyTmFmemQ+RPMSpKifPygyQEQBIZpXlwvbAk8opRHOgVYV5JkCoe YAKC634FNJgJaHB5zWGQwSWJCCmpBsay/Soth/X/1K2oPZyw0EluoeGC4l+zfj4Q6porsKfL NFUynfvA9uK+spuXHRbv4swJNI+5kr5CXOOczJHIkH0fy2anrtDkW+hUPTfcNGnDBNt3i07X zas+cKluze0ZFRIv2pa1M37MDfw94cmkLzudjtb9O/03ZgXzrBusjI/3u/OVt8sVVesrsRRn JBpqMRcVJwIAxoWMY/0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/Mv8cM2LFfMMGnIll4aU4mf8vwIQ Cc: "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 12:39:14 -0000 On Tue, 15 Jul 2014, Theodore Ts'o wrote: > But if we get all applications to use the same library, we can > abstract away not only differences in operating system but also > security policies vis-a-vis DRBG/NDRBG blocking/nonblocking. So what > *I* would prefer is a library interface where the application declares > what it wants the random numbers for: > > * Monte carlo simulations > * Padding > * IV > * Session key > * long-term key > [...] > > Basically, I don't want to leave this choice up to the application > writer, since many application writers won't be competent to make this > choice, and having consistency across different applications which are > conform to the organization's designated security officer seems to be > something that at least some organizations would want. I'm not confident that [all] application writers will even be competent to correctly choose amongst the 5 listed uses [plus whatever others might be added]. If it stays a small number of easily identified things, it might still be better than only exposing the blocking/nonblocking-ness directly, but it doesn't seem clear-cut to me. BTW, FreeBSD exposes a sysctl MIB (CTL_KERN.KERN_ARND) to get entropy directly, saving syscalls over open("/dev/[u]random")/read()/close(). -Ben From nobody Tue Jul 15 06:13:31 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 562651B28B7 for ; Tue, 15 Jul 2014 06:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651, 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 83r2B1qVld7f for ; Tue, 15 Jul 2014 06:13:28 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C2A1B28B2 for ; Tue, 15 Jul 2014 06:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=V8CQ6PnbF863n3a/eXOFi/hoKlQpdarx6D2+ipgwWa0=; b=irL/esNOWwlcnbiNbEnNmZj6ilJmUyf5HB8QLnSACK32UPSfK5WS2gW+UFWwZ2Y+F4oRgpki3f1zgx2JEB8n3fltSbjWGGmkLs0bFVolDw8f088ZJ3c6/mNq23IqbA9qTcwtCuKK0aJfvNn5UgWdxB9gzI0/UVJnq3rQ0dRRx0g=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1X72Xu-0007Oq-LU; Tue, 15 Jul 2014 13:13:26 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id B7F9A5803B7; Tue, 15 Jul 2014 09:13:21 -0400 (EDT) Date: Tue, 15 Jul 2014 09:13:21 -0400 From: Theodore Ts'o To: Benjamin Kaduk Message-ID: <20140715131321.GA32728@thunk.org> References: <20140715082507.GA1451@thunk.org> 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/xd4Mq9qZ2rzEJryCGYdUryELGfs Cc: "dsfjdssdfsd@ietf.org" Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 13:13:29 -0000 On Tue, Jul 15, 2014 at 08:39:07AM -0400, Benjamin Kaduk wrote: > > I'm not confident that [all] application writers will even be competent to > correctly choose amongst the 5 listed uses [plus whatever others might be > added]. If it stays a small number of easily identified things, it might > still be better than only exposing the blocking/nonblocking-ness directly, > but it doesn't seem clear-cut to me. Well, a large number of these uses should be done in the crypto library -- since if the application writer can't tell the difference between an IV and a session key, I'm not sure I want that person anywhere near crypto code... > BTW, FreeBSD exposes a sysctl MIB (CTL_KERN.KERN_ARND) to get entropy > directly, saving syscalls over open("/dev/[u]random")/read()/close(). That only matters if you want to encourage applications to be constantly asking the kernel to generate numbers, though, yes? I'm arguing that it might be better to have a standardized userspace library, ala OpenBSD's arc4random, which takes care of all of the OS specific issues, and also provides a crypto-based DRBG. In that case, it saves even more syscalls, since it only needs to read entropy from the kernel at application startup time, and perhaps periodically every so often when it wants to reseed, but not every single time you need crypto-sensitive padding, IV's, session keys, etc. Cheers, - Ted From nobody Tue Jul 15 07:09:10 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 47B791A03F9 for ; Tue, 15 Jul 2014 07:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_21=0.6, J_CHICKENPOX_36=0.6, 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 D8UCv3JJvk_9 for ; Tue, 15 Jul 2014 07:09:06 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E9A1A03DE for ; Tue, 15 Jul 2014 07:09:05 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 20so1651634yks.1 for ; Tue, 15 Jul 2014 07:09:05 -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=vG+cfbOWeI6sDdNa+nJu8Wa1A8zHAqnkrNy2cKqullw=; b=ogy0OxTwR14E/v5wF/DFLb8Fu/1+RgJChzufGDxVxrMEeaGbD7EuNVpBD9d9uG02At zHuJfRnDEyRyz+FJEDZ9pLgjwcSANp/rPDKuJFn5i/CvLxp5qUQEHbs7oUsGcXECUP+c C0aCujZagb7uksRUWOEsaPVFX94zCHppXNpituBX8ccqpkkY4hxqJ4VYhGqsidvZmUzD GFH10i7pJqUAtRdhdK4+fOd8Z9tWuieUny6VfyYuZ3ZTr+n7lN20Op3IXsctgwTz0Crl x7sbzoQlqvtgf6sXvSW93xtVYPLi5RSytcoT/YSnq1k57zHgrH6yR9i7I4MO4IMtitbL IOYg== MIME-Version: 1.0 X-Received: by 10.236.25.234 with SMTP id z70mr40443234yhz.107.1405433345334; Tue, 15 Jul 2014 07:09:05 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Tue, 15 Jul 2014 07:09:05 -0700 (PDT) In-Reply-To: <20140715131321.GA32728@thunk.org> References: <20140715082507.GA1451@thunk.org> <20140715131321.GA32728@thunk.org> Date: Tue, 15 Jul 2014 07:09:05 -0700 Message-ID: From: Watson Ladd To: "Theodore Ts'o" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/JppntaahL6dFNHCAAwp2YmXA29g Cc: "dsfjdssdfsd@ietf.org" , Benjamin Kaduk Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 14:09:07 -0000 On Tue, Jul 15, 2014 at 6:13 AM, Theodore Ts'o wrote: > On Tue, Jul 15, 2014 at 08:39:07AM -0400, Benjamin Kaduk wrote: >> >> I'm not confident that [all] application writers will even be competent to >> correctly choose amongst the 5 listed uses [plus whatever others might be >> added]. If it stays a small number of easily identified things, it might >> still be better than only exposing the blocking/nonblocking-ness directly, >> but it doesn't seem clear-cut to me. > > Well, a large number of these uses should be done in the crypto > library -- since if the application writer can't tell the difference > between an IV and a session key, I'm not sure I want that person > anywhere near crypto code... What is the difference in how random they should be? There isn't one, and making it exposable in system policy invites all sorts of issues. > >> BTW, FreeBSD exposes a sysctl MIB (CTL_KERN.KERN_ARND) to get entropy >> directly, saving syscalls over open("/dev/[u]random")/read()/close(). > > That only matters if you want to encourage applications to be > constantly asking the kernel to generate numbers, though, yes? I'm > arguing that it might be better to have a standardized userspace > library, ala OpenBSD's arc4random, which takes care of all of the OS > specific issues, and also provides a crypto-based DRBG. In that case, > it saves even more syscalls, since it only needs to read entropy from > the kernel at application startup time, and perhaps periodically every > so often when it wants to reseed, but not every single time you need > crypto-sensitive padding, IV's, session keys, etc. getentropy(2) could be getentropy(3). What's more important is what I want it to do - Block if the random system is not initialized (or return a return value indicating failure) - Return random numbers, even if I've forked or have a multithreaded process - Do so promptly Currently on Linux none of the available options work. Forking requires a post-fork call, /dev/random blocks constantly, and /dev/urandom does not block on startup. I'm probably going to open /dev/urandom: it's the best current alternative. Perhaps arc4random is better to imitate: I don't really care. I just need it to work and ship yesterday. Sincerely, Watson Ladd (And don't use RC4 for it!) > > Cheers, > > - Ted > > _______________________________________________ > 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 Tue Jul 15 11:10:18 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 61B091A04E7 for ; Tue, 15 Jul 2014 11:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_36=0.6, SPF_HELO_PASS=-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 1BONylHjr7ln for ; Tue, 15 Jul 2014 11:10:11 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95041A0005 for ; Tue, 15 Jul 2014 11:10:10 -0700 (PDT) Message-ID: <53C56E7F.7070103@akr.io> Date: Tue, 15 Jul 2014 19:10:07 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: dsfjdssdfsd@ietf.org References: <20140715082507.GA1451@thunk.org> <20140715131321.GA32728@thunk.org> In-Reply-To: <20140715131321.GA32728@thunk.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/LdNQd169mvNSzMS0iLAX3CufVoA Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 18:10:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15/07/2014 14:13, Theodore Ts'o wrote: > I'm arguing that it might be better to have a standardized > userspace library, ala OpenBSD's arc4random, which takes care of > all of the OS specific issues, and also provides a crypto-based > DRBG. In that case, it saves even more syscalls, since it only > needs to read entropy from the kernel at application startup time, > and perhaps periodically every so often when it wants to reseed, > but not every single time you need crypto-sensitive padding, IV's, > session keys, etc. I agree with that entirely - that should definitely be in the libc (we need to take special care to ensure threads and forks never share a context of this), and that is of course how arc4random(3) works. We then have the thorny issue of how to seed it. Failure to seed should definitely be considered a fatal error (OpenBSD bails with SIGKILL). The existing Linux RNG, though it has stood up well to the test of time if I may say so, does not quite meet the needs of that use as it stands. Linux /dev/random estimates incoming entropy and blocks on warmup, but cools down on output, assuming entropy is removed from the pool when used. Many non-interactive systems without hardware TRNGs have insufficient entropy to keep the pool from blocking frequently: it would be impractical to make this a fatal error. Linux /dev/urandom is the same, but never blocks - even if the generator has not received sufficient initial seeding. This is a problem which has resulted in many predictable keys in the wild, especially in embedded devices (which are notoriously challenging environments for entropy collection in the absence of a TRNG, and which obviously did not collect enough at startup and just winged it). What Linux doesn't seem to have is something in the middle; that blocks until it's safely warmed up, but then doesn't need to block again. That's the approach used by OpenBSD (as far as I know?). It stops someone calling it before it's seeded, but also has no concept of 'entropy exhaustion' as the DRBG is secure (hopefully!). The fact that reading from Linux's RNG currently requires device file accesses means access is not atomic and is dependent upon the finite resources of file descriptors, as the libReSSL developers have clearly pointed out. I agree a better approach would be to have a syscall such as getentropy(2) which: - - requires no special privileges - - provides a small amount of data into a provided buffer from a kernel CSPRNG (40-256 bytes, ish) - - iff it has been correctly seeded beforehand with sufficient collected entropy - - returns an error (ENOENT?) if it has never been insufficiently seeded to operate securely - - otherwise does not error (except if an invalid buffer or byte count is given) or block - - does not reduce the entropy estimate in the accumulated buffer (the DRBG should be cryptographically secure so this is not a problem) - - is suitable for seeding arc4random(3) or another CSPRNG, or for direct use if only small quantities are required - - is atomic and uninterruptible and then libc can use that to seed arc4random(3) using ChaCha20 or another very good DRBG (i.e. not RC4!) and hopefully everyone can swim in a sea of quite fast, long-term-key-grade random numbers. If a blocking/pure-entropy mode analogous to /dev/random is required, I think the best approach would be to run a second CSPRNG in parallel which does reduce the entropy count when queried - and its first secure output could be used to kickstart the main kernel CSPRNG, which would be a reasonable implementation in practice I think. I don't think a mode analogous to current /dev/urandom should be provided, because it can be run completely unseeded. If someone wants a non-cryptographic PRNG, they can do it much faster in user-space. Of course, that is just my opinion, this isn't LKML but more of a case study/general discussion here, and I am aware over the decade the generator has been in Linux you've seen _plenty_ of opinions. :) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTxW5/AAoJEOyEjtkWi2t6FVQP/jjPdnn5KozDhiMaY2e5Ohy9 evQc7kZpgF9z0ZWVhx1LUd6o1WMmgUqDa/rnA+Py0R/s7XMg6zuuuUMagLB/YoB0 C3i1E2A1OywnzJAaX6Q31jCyYyIvr8nP2zWdl41cn5NU8kmR0odduuPMgders7bT 4wA6W687qr9ABDolUy9+zNMBfFo/UF8eXn6FBMgdnobNf5OJCqmpmv1RDBFTc80W e4Fhn34r0fAtWRxj+nyC5zAK9HwlKapV1w8HcxLK175rdEfNQAJoalJ19UfgXLvd +w2uohF3uA4UFBlhqvW2UoM9ZTfmbmi2Zr8P/ak0p4rc/2Vg6GU/OLEciqkaHBtE CFgCNbYM0N5JhgAc4pW5Gk4AnoH1xUQLgqNHxsjOji1KeHWTTyk0ZaK1n2fskEXl /Av4z8xmfyXHeus56igtfb82bEhERddUFXixaXbHbxq5KswLiYMQ5rAnTojJZkZz aroZ3V5DPKgIC1yp5YlyJH0YDbGfq3yQ+nKOA3HqDZze7euks3h6/IG0T8mkGEhv sH340xwJqc309n8V3507i+c4ECRMlM3SEBpYpWvGFBRM3Im/1Ah98N2IX9x15rON HsK/tZEyhi98ewd/NPAzgXrVRPTXh5zyGG2S5Ep4ViYMVGKLhQbiNjrqcynYclKc zC9z8ddoGFhcURcifsu0 =U9FN -----END PGP SIGNATURE----- From nobody Tue Jul 15 14: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 A9C441B291F for ; Tue, 15 Jul 2014 14:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651, 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 epzsHSePWLru for ; Tue, 15 Jul 2014 14:07:01 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6961A00A3 for ; Tue, 15 Jul 2014 14:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=NStWJqeNE0sxuEpq2ic3otNhxs0WlwRETkSiW31H7eI=; b=xRcR6GHqlvOx/omcVQUgtL9qTbPARtgj70aHHHTSEXAjflN8QF2Y3JVxKCAuFki+JGjkBktf/zYUYwgZUaE0Ak+o9wZr7E3o1bIKcBAOQamv2n2mYrwOiCNd6yfhFI2rz9nnUcfYhhmxFiCA2qlZTe3HK6qs9hZ1ekQyO4IX88s=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1X79wA-0002l9-5F; Tue, 15 Jul 2014 21:06:58 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 06938580179; Tue, 15 Jul 2014 17:06:51 -0400 (EDT) Date: Tue, 15 Jul 2014 17:06:51 -0400 From: Theodore Ts'o To: Watson Ladd Message-ID: <20140715210650.GC1491@thunk.org> References: <20140715082507.GA1451@thunk.org> <20140715131321.GA32728@thunk.org> 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/k9IHzW6dpIq4LZ0KaXSgbky6Y50 Cc: "dsfjdssdfsd@ietf.org" , Benjamin Kaduk Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 15 Jul 2014 21:07:04 -0000 On Tue, Jul 15, 2014 at 07:09:05AM -0700, Watson Ladd wrote: > > Well, a large number of these uses should be done in the crypto > > library -- since if the application writer can't tell the difference > > between an IV and a session key, I'm not sure I want that person > > anywhere near crypto code... > > What is the difference in how random they should be? There isn't one, > and making it exposable in system policy invites > all sorts of issues. Some people believe, quite passionately, that there should be a difference in at least some of those use cases. NIST believes that there is a difference between what is output by a DRBG and what a NRBG which is used to seed a DRBG. Presumably if you need to sell into the US government market, you'll be forced to care as well, just as companies who have US government customers are forced to deal with FIPS whether or not it is actively harmful to security. And I would *hope* that people would agree there should be a difference between what is needed for a Monte Carlo simulation and other various cryptographic use cases. (I've gotten bug reports from people who insisted on using /dev/urandom for Monte Carlo simulations, and who then complained when it was too slow for their purposes....) So my including Monte Carlo simulations was quite deliberate --- I can pretty much guarantee some cluess graduate student will come across the interface, and decide to use it, and if we list "monte carlo simulations" as one of the options, hopefully they will chose it and be happy. - Ted From nobody Tue Jul 15 22:03:55 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 4E33B1B2A74 for ; Tue, 15 Jul 2014 22:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_21=0.6, 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 oSjvb_I5fNeQ for ; Tue, 15 Jul 2014 22:03:52 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BBF1B2A64 for ; Tue, 15 Jul 2014 22:03:52 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so212521ykp.18 for ; Tue, 15 Jul 2014 22:03:51 -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=QnrDFY4zwiCjhW70Zlm8joMl4pHwI09fG2XuSaxIcPo=; b=nDnZGTtBFEC55EG/9edtE//aM2lVrvJq9sGzxJEniuEOQvR1bTrI1ft3DpW1ySp8RQ h2ambOwNUQgvRzecr71Rolr5HMdVgLTV2hWCHmMRrJacjAjF9gy2zAvvbUHPhwmgjvJ+ jwHVTkoY+2blqlwm5BfS9lIS2yRZrQwPjTb+8BvUD1mtfQA8ZflNZOAG1vCVLusgRLof ZR1uQodU8RnmzqbWOECRryfb4Lo30xnZSMtbeBppDJCogCMPNPCkxRnYnhevz7aGb9K/ BDbKL9h0PVTmFYXD4zm0E/YU/VkEvyHN30MbxqNUsIIQcKrZHQs8t6cpo5e8JY7rQcNF Cmaw== MIME-Version: 1.0 X-Received: by 10.236.15.133 with SMTP id f5mr47787457yhf.63.1405487031717; Tue, 15 Jul 2014 22:03:51 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Tue, 15 Jul 2014 22:03:51 -0700 (PDT) In-Reply-To: <20140715210650.GC1491@thunk.org> References: <20140715082507.GA1451@thunk.org> <20140715131321.GA32728@thunk.org> <20140715210650.GC1491@thunk.org> Date: Tue, 15 Jul 2014 22:03:51 -0700 Message-ID: From: Watson Ladd To: "Theodore Ts'o" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/UkvUlCRvmgi3biqcI31ebqK6O14 Cc: "dsfjdssdfsd@ietf.org" , Benjamin Kaduk Subject: Re: [dsfjdssdfsd] getentropy(2) 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, 16 Jul 2014 05:03:54 -0000 On Tue, Jul 15, 2014 at 2:06 PM, Theodore Ts'o wrote: > On Tue, Jul 15, 2014 at 07:09:05AM -0700, Watson Ladd wrote: >> > Well, a large number of these uses should be done in the crypto >> > library -- since if the application writer can't tell the difference >> > between an IV and a session key, I'm not sure I want that person >> > anywhere near crypto code... >> >> What is the difference in how random they should be? There isn't one, >> and making it exposable in system policy invites >> all sorts of issues. > > Some people believe, quite passionately, that there should be a > difference in at least some of those use cases. NIST believes that > there is a difference between what is output by a DRBG and what a NRBG > which is used to seed a DRBG. Presumably if you need to sell into the > US government market, you'll be forced to care as well, just as > companies who have US government customers are forced to deal with > FIPS whether or not it is actively harmful to security. OpenBSD supplies both getentropy(2) and arc4random(3). I need at least one of these. Make getentropy(2) the seed, and arc4random(3) the RNG. Also, just because you have a portable method not suitable for everyone doesn't mean you can't have a nonportable one for niche uses like getting seeds. The problem is only partly /dev/urandom vanishing in chroots. It's the fact that every system has a different way to do things, so cross-platform compatibility is difficult. Just stick with a good idea, and use arc4random(3). > > And I would *hope* that people would agree there should be a > difference between what is needed for a Monte Carlo simulation and > other various cryptographic use cases. (I've gotten bug reports from > people who insisted on using /dev/urandom for Monte Carlo simulations, > and who then complained when it was too slow for their purposes....) If the library lives in userspace it can be fast enough, even while using AES or HMAC to generate the random samples. > > So my including Monte Carlo simulations was quite deliberate --- I can > pretty much guarantee some cluess graduate student will come across > the interface, and decide to use it, and if we list "monte carlo > simulations" as one of the options, hopefully they will chose it and be happy. > > - Ted Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin