From stephen.farrell@cs.tcd.ie Mon Jan 20 13:47: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 28EE41A01F2 for ; Mon, 20 Jan 2014 13:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 eLg2aTEw2UFP for ; Mon, 20 Jan 2014 13:47:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C53C31A01BB for ; Mon, 20 Jan 2014 13:47:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB297BE39 for ; Mon, 20 Jan 2014 21:47:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omghZk0ZdZBX for ; Mon, 20 Jan 2014 21:47:27 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.53.241]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D7A09BE33 for ; Mon, 20 Jan 2014 21:47:27 +0000 (GMT) Message-ID: <52DD996F.3040708@cs.tcd.ie> Date: Mon, 20 Jan 2014 21:47:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dsfjdssdfsd@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dsfjdssdfsd] 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: Mon, 20 Jan 2014 21:47:33 -0000 Hiya, Just a health-check on this list. Anyone got plans? Ta, S. From d3e3e3@gmail.com Mon Jan 20 14:54: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 69BE81A026F for ; Mon, 20 Jan 2014 14:54:17 -0800 (PST) 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 bwb4lAs2yZEz for ; Mon, 20 Jan 2014 14:54:16 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 103891A0262 for ; Mon, 20 Jan 2014 14:54:15 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id gq1so5924372obb.35 for ; Mon, 20 Jan 2014 14:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W2PDkePBa2Hq6BarG+YcYiv7YqFvyyarVvMejVdjD3A=; b=GzyiFQ3buBTwKzgUQyUed9QZc4Mb2nZin8ePbiR/v26GXzyFdnQ5/mSZhOQ6MHpUnS QruuDtEt+xXZZeYI5ncPFDVk8bTH9cxKjTCHT2AmTNdpPjmHt3qePECF0MBVvJ1sMD6s uxSwEJ6ih8ei7a945ZJ4xD2giKNIEd/fjYMv2quVq1AAP6Wuh4zTEHqzMbvwLEMdlr3i aOKiIeivKvdUvaXbIbYAECGcIq5jYTkFIWiyi8yeEig0SryrqCqnV8USTGsX1ShCtA3e aeu2XKtRR/+cGV28CnW8vS9LgFrlxcvFcQyu51MMJiaNeXmqxsuxX5WCBPdYpM8ZsDyn x8rg== X-Received: by 10.60.246.104 with SMTP id xv8mr17905477oec.18.1390258456001; Mon, 20 Jan 2014 14:54:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Mon, 20 Jan 2014 14:53:55 -0800 (PST) In-Reply-To: <52DD996F.3040708@cs.tcd.ie> References: <52DD996F.3040708@cs.tcd.ie> From: Donald Eastlake Date: Mon, 20 Jan 2014 17:53:55 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: dsfjdssdfsd@ietf.org 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: Mon, 20 Jan 2014 22:54:17 -0000 Hi Stephen, 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. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jan 20, 2014 at 4:47 PM, Stephen Farrell wrote: > > Hiya, > > Just a health-check on this list. Anyone got plans? > > Ta, > S. > _______________________________________________ > dsfjdssdfsd mailing list > dsfjdssdfsd@ietf.org > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From dharkins@lounge.org Mon Jan 20 16:27:13 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 C6B951A0280 for ; Mon, 20 Jan 2014 16:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 lGPUcCzK6lHl for ; Mon, 20 Jan 2014 16:27:11 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DC1841A027C for ; Mon, 20 Jan 2014 16:27:11 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B190D10224008; Mon, 20 Jan 2014 16:27:11 -0800 (PST) Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Jan 2014 16:27:11 -0800 (PST) Message-ID: In-Reply-To: <52DD996F.3040708@cs.tcd.ie> References: <52DD996F.3040708@cs.tcd.ie> Date: Mon, 20 Jan 2014 16:27:11 -0800 (PST) From: "Dan Harkins" To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] 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, 21 Jan 2014 00:27:14 -0000 Hi Stephen, On Mon, January 20, 2014 1:47 pm, Stephen Farrell wrote: > > Hiya, > > Just a health-check on this list. Anyone got plans? Thanks for the prod. Are HMAC_DRBG and CTR_DRBG suitable as general purpose DRBGs? If yes, then do people see value in producing an Informational RFC describing them? If not, what's the problem and what's a suitable alternative? thanks, Dan. From paul.hoffman@vpnc.org Mon Jan 20 17:28:57 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 AE9FA1A0017 for ; Mon, 20 Jan 2014 17:28:57 -0800 (PST) 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 UzOBBn8qUYjp for ; Mon, 20 Jan 2014 17:28:56 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C47921A000E for ; Mon, 20 Jan 2014 17:28:56 -0800 (PST) Received: from pauls-mac.home (pool-108-5-148-206.nwrknj.fios.verizon.net [108.5.148.206]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0L18JjE097602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Jan 2014 18:08:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host pool-108-5-148-206.nwrknj.fios.verizon.net [108.5.148.206] claimed to be pauls-mac.home Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Mon, 20 Jan 2014 20:28:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> To: Donald Eastlake X-Mailer: Apple Mail (2.1827) Cc: dsfjdssdfsd@ietf.org, Stephen Farrell 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, 21 Jan 2014 01:28:57 -0000 On Jan 20, 2014, at 5:53 PM, Donald Eastlake wrote: > 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. 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. --Paul Hoffman= From dharkins@lounge.org Wed Jan 22 08:13:16 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 6E4871A046C for ; Wed, 22 Jan 2014 08:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, 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 97Q09aEltU-o for ; Wed, 22 Jan 2014 08:13:14 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C31A0469 for ; Wed, 22 Jan 2014 08:13:14 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F30541022404A; Wed, 22 Jan 2014 08:13:13 -0800 (PST) Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Jan 2014 08:13:14 -0800 (PST) Message-ID: In-Reply-To: <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> Date: Wed, 22 Jan 2014 08:13:14 -0800 (PST) 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 Cc: Donald Eastlake , dsfjdssdfsd@ietf.org, Stephen Farrell 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: Wed, 22 Jan 2014 16:13:16 -0000 Paul, On Mon, January 20, 2014 5:28 pm, Paul Hoffman wrote: > On Jan 20, 2014, at 5:53 PM, Donald Eastlake wrote: > >> 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. > > 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. "Ask your OS" is putting faith in the guy that wrote the relevant code in your OS. It might be a reasonable leap but it's a leap nevertheless. Recent events should tell us that we should not trust a single source for these things (even if we are told that this single source is actually the output of a bunch of uncorrelated sources of entropy being mixed up). I see value in draft-eastlake-randomness3 and I also see value in an Informational RFC on a good DRBG for those who feel the need to have a belt as well as suspenders. Dan. From paul.hoffman@vpnc.org Wed Jan 22 08:28:46 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 6C7891A014B for ; Wed, 22 Jan 2014 08:28:46 -0800 (PST) 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 rI7G7iU3EaXI for ; Wed, 22 Jan 2014 08:28:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 53DF21A035D for ; Wed, 22 Jan 2014 08:28:45 -0800 (PST) Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MG8Xx9096042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 09:08:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90] Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 22 Jan 2014 08:28:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> To: Dan Harkins X-Mailer: Apple Mail (2.1827) Cc: dsfjdssdfsd@ietf.org 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: Wed, 22 Jan 2014 16:28:46 -0000 On Jan 22, 2014, at 8:13 AM, Dan Harkins wrote: > "Ask your OS" is putting faith in the guy that wrote the relevant = code > in your OS. Yes, exactly. > It might be a reasonable leap but it's a leap nevertheless. We put faith in the (~85%) guy for all the other crypto code as well, so = I don't see the leap. > Recent events should tell us that we should not trust a single source = for > these things (even if we are told that this single source is actually = the > output of a bunch of uncorrelated sources of entropy being mixed up). That's one interpretation. Another is that attackers will look for bad = implementations and use those as best they can. > I see value in draft-eastlake-randomness3 and I also see value in an > Informational RFC on a good DRBG for those who feel the need to have > a belt as well as suspenders. We disagree here; the chance that the person writing the belt will get = it wrong and make their crypto trivial to break for an attacker who = knows the weakness seems much higher to me than the change that the OS = got it wrong. Yes, we could put some warning at the front of the new = document about this, but that warning will be ignored by programmers who = are sure they know this stuff. I could see writing something that forces them to mix in randomness from = the OS to their possibly-borked DRBG in the hopes that at least that = step will fix their problems. However, if we do that, nearly all the = interesting technical stuff in the current document is just confusing = fluff. The new document reduces to "use an HMAC with the randomness from = your OS as the key and whatever stuff you think is random as the data; = done". --Paul Hoffman= From pinterkr@gmail.com Wed Jan 22 09:51: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 D9FBA1A011B for ; Wed, 22 Jan 2014 09:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 Lj3InpWaWyax for ; Wed, 22 Jan 2014 09:51:42 -0800 (PST) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id E06D41A0186 for ; Wed, 22 Jan 2014 09:51:41 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id d17so5186734eek.9 for ; Wed, 22 Jan 2014 09:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=uleh95dFYgO1FUERNA1S/L8FuKi0bXZRJr/GhfmeZto=; b=PN2h7wCsIQ6SKVgtaUgwik9qjQxm6j9VCf71gHpVN59hTKzqy7s/H7OOcabTLLNNyM DOjRgtuF4RBR7p12KfhDo+2KcOyLjpka0YEhmnqY+wPP4lxSIWH45T7MjaBDNW5CxLvN HawhURfDEQrT6OQas9PUgTGx39DBu3fjpGLlg8Mowi6JpkbMxS8/UGacPN/rbj5Zskqm LJKFZiOm4gUhLpnWk2JG8wgoHUi1EPaJZrsDfD2seR5tQPB3MeYHegu81SDuHgyOsn6a 4G/DXeqbtOmvZQEYjigJBYGg399W4INP6L3cG4MpBoVJph+dW+P9Bj4TN0Afpv98WpTA CHtg== X-Received: by 10.14.103.194 with SMTP id f42mr2849164eeg.15.1390413100955; Wed, 22 Jan 2014 09:51:40 -0800 (PST) Received: from [192.168.2.244] (catv-176-63-52-22.catv.broadband.hu. [176.63.52.22]) by mx.google.com with ESMTPSA id v1sm29742458eef.9.2014.01.22.09.51.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Jan 2014 09:51:40 -0800 (PST) Date: Wed, 22 Jan 2014 18:51:49 +0100 From: =?iso-8859-15?Q?Kriszti=E1n_Pint=E9r?= X-Priority: 3 (Normal) Message-ID: <1737731959.20140122185149@gmail.com> To: Paul Hoffman In-Reply-To: <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Donald Eastlake , dsfjdssdfsd@ietf.org, Stephen Farrell 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: Wed, 22 Jan 2014 17:51:43 -0000 Paul Hoffman (at Tuesday, January 21, 2014, 2:28:26 AM): > 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. (new to the list, and i'm not sure about the scope or context, so forgive me if i'm talking nonsense.) i agree that the OS should do the work, for multiple reasons, 1, it is better done in a protected environment (aka ring 0), 2, OS has access to more entropy, 3, better have one excellent than many good solutions. that said, what is the list of OS's today that has sound, reviewed RNG? openbsd, ...? so this is pretty thin. From d3e3e3@gmail.com Wed Jan 22 10:13: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 1FC171A0174 for ; Wed, 22 Jan 2014 10:13:55 -0800 (PST) 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 LrAMYkYb_QOi for ; Wed, 22 Jan 2014 10:13:54 -0800 (PST) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6FC1A015A for ; Wed, 22 Jan 2014 10:13:54 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so890174oag.12 for ; Wed, 22 Jan 2014 10:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=7NJ9Zti+/fWG4Kw5wGcZpwGu9fAsmqpqmO6q/7jlBos=; b=w0GblHQl6//+DIDpRTmo1WPo9nRmp7F0ccm3UwA8GHyxpnkit+juFt3Bt7Xac7sVKB d0NlF08Jsp4PmQgmGC5vppH4GjWOuR/vxiSINQ4+anMemT1qFBiK5+fxQCqbOxIQgCE7 3BAPy9E28rOfJYy9HVILzJtVm1EZnywznOXqJqNA2t+l7P1P8UqatVH0CMvFwbL908Fe Wx2Wv0i/emzf7uq52hV2XoNsk/map4z3Se9N035gMm6UdFUEGcTiZ+YE9FZT8i6sA3UC MYv1yPffXSlp/j/p7ZNN3Px+NB8KEJM0Wq07/Z8gDZoGEEbS0mrfC9F4xz2enHRaSJYd 7xpQ== X-Received: by 10.182.250.163 with SMTP id zd3mr2672570obc.20.1390414433555; Wed, 22 Jan 2014 10:13:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.33.102 with HTTP; Wed, 22 Jan 2014 10:13:33 -0800 (PST) In-Reply-To: <1737731959.20140122185149@gmail.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> From: Donald Eastlake Date: Wed, 22 Jan 2014 13:13:33 -0500 Message-ID: To: dsfjdssdfsd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 22 Jan 2014 18:13:55 -0000 Hi Paul, > Paul Hoffman (at Tuesday, January 21, 2014, 2:28:26 AM): >> 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. I don't understand why you think having an RFC means that applications developers are supposed to implement what is described in that RFC. The IETF does lots of non-application level RFCs. I don't agree that it is clear who is an expert in this area. I don't agree that any person believed to be an expert will, in the absence of documentation, know or take into account all the aspects of what might be called best current practice in this area. IETF specifications that call for quantities unpredictable by adversaries need to reference something. Should they just reference the NIST documents? Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From dharkins@lounge.org Wed Jan 22 10:40:36 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 E83381A0158 for ; Wed, 22 Jan 2014 10:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 wBgCXpTZM8CI for ; Wed, 22 Jan 2014 10:40:35 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 922CC1A011C for ; Wed, 22 Jan 2014 10:40:35 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1D9E41022404A; Wed, 22 Jan 2014 10:40:34 -0800 (PST) Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Jan 2014 10:40:34 -0800 (PST) Message-ID: In-Reply-To: References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> Date: Wed, 22 Jan 2014 10:40:34 -0800 (PST) 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 Cc: dsfjdssdfsd@ietf.org, Dan Harkins 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: Wed, 22 Jan 2014 18:40:37 -0000 On Wed, January 22, 2014 8:28 am, Paul Hoffman wrote: > On Jan 22, 2014, at 8:13 AM, Dan Harkins wrote: >> >> I see value in draft-eastlake-randomness3 and I also see value in an >> Informational RFC on a good DRBG for those who feel the need to have >> a belt as well as suspenders. > > We disagree here; the chance that the person writing the belt will get it > wrong and make their crypto trivial to break for an attacker who knows the > weakness seems much higher to me than the change that the OS got it wrong. > Yes, we could put some warning at the front of the new document about > this, but that warning will be ignored by programmers who are sure they > know this stuff. > > I could see writing something that forces them to mix in randomness from > the OS to their possibly-borked DRBG in the hopes that at least that step > will fix their problems. However, if we do that, nearly all the > interesting technical stuff in the current document is just confusing > fluff. The new document reduces to "use an HMAC with the randomness from > your OS as the key and whatever stuff you think is random as the data; > done". To minimize the possibility of someone borking their DRBG implementation we can include some test vectors-- instantiating with A produces state of B; reseeding of state B with C produces state D; generating with state D produces E, etc. The more people that implement anything will increase the probability of a broken implementation somewhere, I definitely agree. But it is an accepted economic truth that relying on a single source for anything is a bad idea. Dan. From paul.hoffman@vpnc.org Wed Jan 22 11:12:09 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 B7C631A02BF for ; Wed, 22 Jan 2014 11:12:09 -0800 (PST) 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 7vipdprgQQgb for ; Wed, 22 Jan 2014 11:12:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AA1421A01AF for ; Wed, 22 Jan 2014 11:12:08 -0800 (PST) Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MIpsf2001394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 11:51:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 Jan 2014 11:12:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2E83403A-659D-4671-813A-5FC55EC781FE@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> To: Donald Eastlake X-Mailer: Apple Mail (2.1827) Cc: dsfjdssdfsd@ietf.org 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: Wed, 22 Jan 2014 19:12:09 -0000 On Jan 22, 2014, at 10:13 AM, Donald Eastlake wrote: > Hi Paul, >=20 >> Paul Hoffman (at Tuesday, January 21, 2014, 2:28:26 AM): >>> 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. >=20 > I don't understand why you think having an RFC means that applications > developers are supposed to implement what is described in that RFC. Why else write the RFC? Is it for developers who work on /dev/random in = various OSs? If so, there is a whole different set of problems with the = document, which we discussed during the round before this. > The IETF does lots of non-application level RFCs. Sure, and if this is one of those, you need to say that clearly. That's = why I said I wanted to see what changes you were making in the -01. > I don't agree that > it is clear who is an expert in this area. I don't agree that any > person believed to be an expert will, in the absence of documentation, > know or take into account all the aspects of what might be called best > current practice in this area. Sure. However, I also don't think the document describes what are = "best", much less "current", practices in the area. The permathreads on = the cryptography mailing list makes it really clear that there is no = agreement on what is "best" even among active crypto developers. They = also show that many people don't even know what is "current": Ted Ts'o = has had to tell folks a few times that their new ideas are in fact = already implemented, at least in Linux. > IETF specifications that call for > quantities unpredictable by adversaries need to reference something. Yes. > Should they just reference the NIST documents? Definitely not. --Paul Hoffman= From paul.hoffman@vpnc.org Wed Jan 22 11:16:22 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 4B71A1A01AF for ; Wed, 22 Jan 2014 11:16:22 -0800 (PST) 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 UBrpfv_Sb0wZ for ; Wed, 22 Jan 2014 11:16:21 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDAA1A0141 for ; Wed, 22 Jan 2014 11:16:21 -0800 (PST) Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MIuABZ001585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 11:56:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90] Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 22 Jan 2014 11:16:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7F55125F-1669-4A36-A4A5-C1655CDCE77A@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> To: Dan Harkins X-Mailer: Apple Mail (2.1827) Cc: dsfjdssdfsd@ietf.org 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: Wed, 22 Jan 2014 19:16:22 -0000 On Jan 22, 2014, at 10:40 AM, Dan Harkins wrote: > To minimize the possibility of someone borking their DRBG = implementation > we can include some test vectors-- instantiating with A produces state = of > B; reseeding of state B with C produces state D; generating with state = D > produces E, etc. If we could be sure that there was no way for the mechanisms needed to = test those vectors could possibly appear in an implementation, that = would be great. If we can't be sure of that, we are proposing an = implementer include something that could cause a catastrophic failure if = those inputs are accidentally left in. Regardless, that's not what Don's draft does. > The more people that implement anything will increase the probability = of > a broken implementation somewhere, I definitely agree. But it is an = accepted > economic truth that relying on a single source for anything is a bad = idea. That seems like a strawman: who says that there is a "single source" of = ideas for how to implement randomness? Three large server OSs (Linux, = FreeBSD, Windows) all do it differently. --Paul Hoffman= From dharkins@lounge.org Wed Jan 22 12:29:08 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 25D8D1A0490 for ; Wed, 22 Jan 2014 12:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 Pwl6r7gSbcfp for ; Wed, 22 Jan 2014 12:29:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A18751A0493 for ; Wed, 22 Jan 2014 12:29:04 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D0C8810224008; Wed, 22 Jan 2014 12:29:03 -0800 (PST) Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Jan 2014 12:29:04 -0800 (PST) Message-ID: In-Reply-To: <7F55125F-1669-4A36-A4A5-C1655CDCE77A@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <7F55125F-1669-4A36-A4A5-C1655CDCE77A@vpnc.org> Date: Wed, 22 Jan 2014 12:29:04 -0800 (PST) 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 Cc: dsfjdssdfsd@ietf.org 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: Wed, 22 Jan 2014 20:29:08 -0000 On Wed, January 22, 2014 11:16 am, Paul Hoffman wrote: > On Jan 22, 2014, at 10:40 AM, Dan Harkins wrote: > >> To minimize the possibility of someone borking their DRBG >> implementation >> we can include some test vectors-- instantiating with A produces state >> of >> B; reseeding of state B with C produces state D; generating with state D >> produces E, etc. > > If we could be sure that there was no way for the mechanisms needed to > test those vectors could possibly appear in an implementation, that would > be great. If we can't be sure of that, we are proposing an implementer > include something that could cause a catastrophic failure if those inputs > are accidentally left in. That seems like an absurdly high bar-- that there is no way someone could so something demonstrably stupid. We use test vectors when specifying things like HKDF or AES- and no one seems to generate a function that only accepts those inputs and only produces the specified outputs. I really don't think people will suddenly start hard-coding test vectors into code now. > Regardless, that's not what Don's draft does. I'm still hoping that an Informational RFC on a good DRBG will be generated. >> The more people that implement anything will increase the probability >> of >> a broken implementation somewhere, I definitely agree. But it is an >> accepted >> economic truth that relying on a single source for anything is a bad >> idea. > > That seems like a strawman: who says that there is a "single source" of > ideas for how to implement randomness? Three large server OSs (Linux, > FreeBSD, Windows) all do it differently. The single source is "your OS". While there are 3 large server OSs, there is no single application that can obtain randomness from all three since there is no application that runs on all of them (and my experience is that a single linux application won't necessarily work from version X of the OS to version Y-- hell, sometimes the source won't even compile). And you know, the "if we could be sure there was no way…" thing works both ways, especially regarding a large (monopoly) OS whose track record on security and code quality is not perfect. Dan. From paul.hoffman@vpnc.org Wed Jan 22 14:15: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 703781A04C2 for ; Wed, 22 Jan 2014 14:15:40 -0800 (PST) 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 L-USXjSlfOTF for ; Wed, 22 Jan 2014 14:15:39 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 822B61A04A2 for ; Wed, 22 Jan 2014 14:15:09 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MLswYN007404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 14:54:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 22 Jan 2014 14:15:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEB58EF-1102-458A-A215-AE4822C60FEE@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <7F55125F-1669-4A36-A4A5-C1655CDCE77A@vpnc.org> To: Dan Harkins X-Mailer: Apple Mail (2.1827) Cc: dsfjdssdfsd@ietf.org 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: Wed, 22 Jan 2014 22:15:40 -0000 On Jan 22, 2014, at 12:29 PM, Dan Harkins wrote: > On Wed, January 22, 2014 11:16 am, Paul Hoffman wrote: >> On Jan 22, 2014, at 10:40 AM, Dan Harkins = wrote: >>=20 >>> To minimize the possibility of someone borking their DRBG >>> implementation >>> we can include some test vectors-- instantiating with A produces = state >>> of >>> B; reseeding of state B with C produces state D; generating with = state D >>> produces E, etc. >>=20 >> If we could be sure that there was no way for the mechanisms needed = to >> test those vectors could possibly appear in an implementation, that = would >> be great. If we can't be sure of that, we are proposing an = implementer >> include something that could cause a catastrophic failure if those = inputs >> are accidentally left in. >=20 > That seems like an absurdly high bar-- that there is no way someone > could so something demonstrably stupid. We use test vectors when > specifying things like HKDF or AES- and no one > seems to generate a function that only accepts those inputs and only > produces the specified outputs. Note the difference with "HKDF or AES-" and a DBRG. In = the former case, if they only accepted the test vectors for input, they = would never interoperate. In the latter case, if they only accepted = those inputs, they generator would still work just fine; it would also = be completely predictable. > I really don't think people will suddenly > start hard-coding test vectors into code now. They already frequently do exactly that. I have seen multiple = implementations have a FIPS 140 self-test mode built in. >=20 >> Regardless, that's not what Don's draft does. >=20 > I'm still hoping that an Informational RFC on a good DRBG will be > generated. In your mind, who is the intended reader? Implementers of the good DRBG = in an OS, or in an application, or both? >>> The more people that implement anything will increase the = probability >>> of >>> a broken implementation somewhere, I definitely agree. But it is an >>> accepted >>> economic truth that relying on a single source for anything is a bad >>> idea. >>=20 >> That seems like a strawman: who says that there is a "single source" = of >> ideas for how to implement randomness? Three large server OSs (Linux, >> FreeBSD, Windows) all do it differently. >=20 > The single source is "your OS". Ah, got it. Are you saying "if you are going to re-implement crypto = primitives and not trust your OS, and one of the ones you are = re-implementing is the DBRG, here is a best practice for how to do it"? > While there are 3 large server OSs, there > is no single application that can obtain randomness from all three = since > there is no application that runs on all of them (and my experience is > that a single linux application won't necessarily work from version X = of > the OS to version Y-- hell, sometimes the source won't even compile). >=20 > And you know, the "if we could be sure there was no way=85" thing = works > both ways, especially regarding a large (monopoly) OS whose track > record on security and code quality is not perfect. Fully agree. We should definitely not say "X is a best practice for = DBRG" where X is a single value.= From dharkins@lounge.org Wed Jan 22 15:36:03 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 7FEA21A0511 for ; Wed, 22 Jan 2014 15:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 D9K7PNaiuV4W for ; Wed, 22 Jan 2014 15:36:02 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 145541A051F for ; Wed, 22 Jan 2014 15:36:02 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 34D0E10224008; Wed, 22 Jan 2014 15:36:01 -0800 (PST) Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Jan 2014 15:36:01 -0800 (PST) Message-ID: <5a5cccde75afefd7dee966083f641293.squirrel@www.trepanning.net> In-Reply-To: <9CEB58EF-1102-458A-A215-AE4822C60FEE@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <7F55125F-1669-4A36-A4A5-C1655CDCE77A@vpnc.org> <9CEB58EF-1102-458A-A215-AE4822C60FEE@vpnc.org> Date: Wed, 22 Jan 2014 15:36:01 -0800 (PST) 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 Cc: dsfjdssdfsd@ietf.org 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: Wed, 22 Jan 2014 23:36:03 -0000 On Wed, January 22, 2014 2:15 pm, Paul Hoffman wrote: > On Jan 22, 2014, at 12:29 PM, Dan Harkins wrote: > >> On Wed, January 22, 2014 11:16 am, Paul Hoffman wrote: >> I'm still hoping that an Informational RFC on a good DRBG will be >> generated. > > In your mind, who is the intended reader? Implementers of the good DRBG in > an OS, or in an application, or both? If an OS developer feels he needs a DRBG then, yes, this would be for him. And depending on the application, yes this would be for that developer too. >>>> The more people that implement anything will increase the probability >>>> of >>>> a broken implementation somewhere, I definitely agree. But it is an >>>> accepted >>>> economic truth that relying on a single source for anything is a bad >>>> idea. >>> >>> That seems like a strawman: who says that there is a "single source" of >>> ideas for how to implement randomness? Three large server OSs (Linux, >>> FreeBSD, Windows) all do it differently. >> >> The single source is "your OS". > > Ah, got it. Are you saying "if you are going to re-implement crypto > primitives and not trust your OS, and one of the ones you are > re-implementing is the DBRG, here is a best practice for how to do it"? It's not necessarily that you don't trust the OS, it's that you don't trust that to be your sole source. Dan. From Francis.Dupont@fdupont.fr Wed Jan 22 15:55:45 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 A151B1A0364 for ; Wed, 22 Jan 2014 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 flfOJO4aOC0I for ; Wed, 22 Jan 2014 15:55:43 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 610421A01F6 for ; Wed, 22 Jan 2014 15:55:43 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s0MNtfEr078519; Thu, 23 Jan 2014 00:55:42 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201401222355.s0MNtfEr078519@givry.fdupont.fr> From: Francis Dupont To: Paul Hoffman In-reply-to: Your message of Wed, 22 Jan 2014 08:28:41 PST. Date: Thu, 23 Jan 2014 00:55:41 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dsfjdssdfsd@ietf.org, Dan Harkins 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: Wed, 22 Jan 2014 23:55:45 -0000 In your previous mail you wrote: > > "Ask your OS" is putting faith in the guy that wrote the relevant code > > in your OS. > > Yes, exactly. > > > It might be a reasonable leap but it's a leap nevertheless. > > We put faith in the (~85%) guy for all the other crypto code as well, > so I don't see the leap. => another argument is the kernel has access to more resources/entropy sources than a user mode code. So I tend to agree with Paul: if you have to trust something the OS is not the worst choice. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Jan 22 16:26:02 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 43BC21A01D6 for ; Wed, 22 Jan 2014 16:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 xVQTj-cmK97t for ; Wed, 22 Jan 2014 16:26:01 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD71A01A5 for ; Wed, 22 Jan 2014 16:26:00 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s0N0PxMU080596; Thu, 23 Jan 2014 01:25:59 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201401230025.s0N0PxMU080596@givry.fdupont.fr> From: Francis Dupont To: "Dan Harkins" In-reply-to: Your message of Wed, 22 Jan 2014 12:29:04 PST. Date: Thu, 23 Jan 2014 01:25:59 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dsfjdssdfsd@ietf.org, Paul Hoffman 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: Thu, 23 Jan 2014 00:26:02 -0000 In your previous mail you wrote: > > That seems like a strawman: who says that there is a "single source" of > > ideas for how to implement randomness? Three large server OSs (Linux, > > FreeBSD, Windows) all do it differently. > > The single source is "your OS". While there are 3 large server OSs, there > is no single application that can obtain randomness from all three since > there is no application that runs on all of them => I know many applications which run on these 3 OSs (and more, i.e., Solaris, AIX and HP-UX too if you limit to still alive OSs). So either I didn't understand you or we are not talking about the same thing... > (and my experience is > that a single linux application won't necessarily work from version X of > the OS to version Y-- hell, sometimes the source won't even compile). => change your application developer? Regards Francis.Dupont@fdupont.fr From dharkins@lounge.org Wed Jan 22 17:36:32 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 CD0EE1A0348 for ; Wed, 22 Jan 2014 17:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 TRU4xGIWAgYZ for ; Wed, 22 Jan 2014 17:36:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAD1A01B7 for ; Wed, 22 Jan 2014 17:36:31 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0155410224008; Wed, 22 Jan 2014 17:36:30 -0800 (PST) Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Jan 2014 17:36:31 -0800 (PST) Message-ID: <82535cea19e2c6434090b94565e652f5.squirrel@www.trepanning.net> In-Reply-To: <201401230025.s0N0PxMU080596@givry.fdupont.fr> References: <201401230025.s0N0PxMU080596@givry.fdupont.fr> Date: Wed, 22 Jan 2014 17:36:31 -0800 (PST) From: "Dan Harkins" To: "Francis Dupont" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dsfjdssdfsd@ietf.org, Paul Hoffman 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: Thu, 23 Jan 2014 01:36:33 -0000 On Wed, January 22, 2014 4:25 pm, Francis Dupont wrote: > In your previous mail you wrote: > >> > That seems like a strawman: who says that there is a "single source" >> of >> > ideas for how to implement randomness? Three large server OSs (Linux, >> > FreeBSD, Windows) all do it differently. >> >> The single source is "your OS". While there are 3 large server OSs, >> there >> is no single application that can obtain randomness from all three >> since >> there is no application that runs on all of them > > => I know many applications which run on these 3 OSs (and more, i.e., > Solaris, AIX and HP-UX too if you limit to still alive OSs). > So either I didn't understand you or we are not talking about the same > thing... If you take the executable from Solaris and copy it onto your HP-UX machine it will not run. My point was that there were not 3 sources (Paul mentioned 3) available to an application, there is just one: the one that's part of OS that the application happened to be compiled for. >> (and my experience is >> that a single linux application won't necessarily work from version X >> of >> the OS to version Y-- hell, sometimes the source won't even compile). > > => change your application developer? Ha, ha. Funny. I have considered firing myself several times. The issue was not the code I was writing, it is the annoying habit of linux driver developers to change data structures (the one in question was for an 802.11 device) in gratuitous ways that cause breakage. I have never had that problem with freeBSD. In fact, the inability of an application to just compile from one OS release to another is touted as a feature by some of the more zealous linux people. Dan. From jon@hosed.org Wed Jan 22 19:55:02 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 4DED61A0183 for ; Wed, 22 Jan 2014 19:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, 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 kb9udajLUUJg for ; Wed, 22 Jan 2014 19:55:01 -0800 (PST) Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id 082AF1A0179 for ; Wed, 22 Jan 2014 19:55:00 -0800 (PST) Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id DD6E41706E; Wed, 22 Jan 2014 19:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390449300; bh=f6/ekX1XwJ2b+S7PoPvLkioBX//MiPanuAjjGCFNLQA=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=vRzrWndfZCndh9IYOBupcmDQccwCfawhfpM9Os73CQTt3htnDGTBf8WN5Joslm602 P8DWGtScUBSLK2cdtS8HCxBXehxm0yDTvVASGUrvIejxO2yV2gWDLetsh1UmvQ0KU9 xUuTRO+vKdcyeDNvi9M2l+qO7tpSZDaUCqM4WY3Y= X-Virus-Scanned: amavisd-new at encrypted.net Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSaiTxk_G2wS; Wed, 22 Jan 2014 19:54:59 -0800 (PST) Received: from jgreent410s (76-220-43-250.lightspeed.sntcca.sbcglobal.net [76.220.43.250]) by firefly.encrypted.net (Postfix) with ESMTPA id 7817A17068; Wed, 22 Jan 2014 19:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390449299; bh=f6/ekX1XwJ2b+S7PoPvLkioBX//MiPanuAjjGCFNLQA=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=RBBz1c6C1PcXka88qi3+sw7l/VFr+WW7mxYwfD7LGBs/Ec/7uXqM43XalK22UukkU fvJH7Hlp4ljItMZ1IqlX0Hb5r550yDehw1SYVDrAJwXpeONEYdaxtH7EgHa6hD77xC 1R7zyi+PG0ntu0j3+CRNLnG6GmEBiXpfNId4nRkU= From: Sender: "Jon Green" To: =?Windows-1252?Q?'Kriszti=E1n_Pint=E9r'?= References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> In-Reply-To: <1737731959.20140122185149@gmail.com> Date: Wed, 22 Jan 2014 19:54:59 -0800 Message-ID: <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3sdi2ZRq1Hpg6dXIL/pF6U42SYgGC9VecARNdWnIB1CvuGpqdIaQg Content-Language: en-us Cc: dsfjdssdfsd@ietf.org 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: Thu, 23 Jan 2014 03:56:01 -0000 I'm new to the list, so apologies if I go off the track here. The problem with relying on the OS is that you're not always sure what = the OS is doing. Example: If I run Linux under ESXi on a headless server, = with an SSD for a disk, and I use the Ethernet NIC built into the = motherboard, where is the entropy for /dev/random coming from? Is the driver for = that particular NIC instrumented to contribute to the entropy pool? Most = people don't know, and further don't know how to find out. I have seen embedded Linux products before where the sole source of = entropy was the hard disk. Problem was, the entire system operated off a = RAMdisk, so guess how much disk activity there was during runtime? =20 Those of us who deal with FIPS 140 and Common Criteria are now being = asked to document entropy sources, including providing measurements of how = much entropy is actually there and how fast it can be produced. Looking at = one Common Criteria protection profile specifically - the VPN client PP - = the developer has the choice of generating cryptographic entropy within the application, or relying on the underlying platform to supply it. But = the only way you get to rely on the underlying platform is if that platform itself has been through a PP evaluation and thus quantified the entropy. = So if you want to have any hope of passing the evaluation, you're almost = forced into doing something yourself. The various DRBGs are fine IMHO for handing out bits of random to an application, and lacking anything better today I would certainly = encourage developers to use one. But the question is how do we seed the DRBG in = the first place? =20 -Jon -----Original Message----- From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Kriszti=E1n Pint=E9r Sent: Wednesday, January 22, 2014 9:52 AM To: Paul Hoffman Cc: Donald Eastlake; dsfjdssdfsd@ietf.org; Stephen Farrell Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? Paul Hoffman (at Tuesday, January 21, 2014, 2:28:26 AM): > 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. (new to the list, and i'm not sure about the scope or context, so forgive me if i'm talking nonsense.) i agree that the OS should do the work, for multiple reasons, 1, it is better done in a protected environment (aka ring 0), 2, OS has access to more entropy, 3, better have one excellent than many good solutions. that said, what is the list of OS's today that has sound, reviewed RNG? openbsd, ...? so this is pretty thin. _______________________________________________ dsfjdssdfsd mailing list dsfjdssdfsd@ietf.org https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From Francis.Dupont@fdupont.fr Thu Jan 23 01:34: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 04CE51A0349 for ; Thu, 23 Jan 2014 01:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 v8AUFp_8HSxy for ; Thu, 23 Jan 2014 01:34:40 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id DBF3A1A0357 for ; Thu, 23 Jan 2014 01:34:39 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s0N9Ycqu015366; Thu, 23 Jan 2014 10:34:38 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201401230934.s0N9Ycqu015366@givry.fdupont.fr> From: Francis Dupont To: "Dan Harkins" In-reply-to: Your message of Wed, 22 Jan 2014 17:36:31 PST. <82535cea19e2c6434090b94565e652f5.squirrel@www.trepanning.net> Date: Thu, 23 Jan 2014 10:34:38 +0100 Sender: Francis.Dupont@fdupont.fr Cc: dsfjdssdfsd@ietf.org, Paul Hoffman 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: Thu, 23 Jan 2014 09:34:42 -0000 In your previous mail you wrote: > If you take the executable from Solaris and copy it onto your HP-UX > machine it will not run. => it depends: this is true (i.e., won't run) for an application written in C/C++, but false (i.e., will run) for an application written in python or ocaml. So there is another level between binary and source code compatibilities. To come back to the main subject, as an application developer I have the choice between the OS, the crypto library (e.g., OpenSSL) and home made to provide a (P)RNG/(D/N)RBG to be used to generate not predictable (BTW it is nearly always prediction resistance, not backtracking resistance :-) values (e.g., transaction IDs), and to generate crypto material (I cite the two because constraints are very different, for instance for not predictable values I really want a not blocking solution). > My point was that there were not 3 sources (Paul mentioned 3) > available to an application, there is just one: the one that's part of > OS that the application happened to be compiled for. => I should have said "to run over" (BTW with virtualization it is not so trivial...) > > => change your application developer? > > Ha, ha. Funny. I have considered firing myself several times. > > The issue was not the code I was writing, it is the annoying habit of > linux driver developers to change data structures (the one in question > was for an 802.11 device) in gratuitous ways that cause breakage. I > have never had that problem with freeBSD. In fact, the inability of an > application to just compile from one OS release to another is touted > as a feature by some of the more zealous linux people. => I'd like to join you as an old BSD man in Linux zealot bashing (e.g., it is not a gratuitous change: they just never read the previous code until they get conflicts from multiple definitions with the same name :-) but we shall be off topic... Regards Francis.Dupont@fdupont.fr From stephen.farrell@cs.tcd.ie Thu Jan 23 01:57:22 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 32A101A0390 for ; Thu, 23 Jan 2014 01:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] 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 W8MMTJx8HRJg for ; Thu, 23 Jan 2014 01:57:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EE7931A0349 for ; Thu, 23 Jan 2014 01:57:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C6574BE55; Thu, 23 Jan 2014 09:57:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-+66UDaNR9L; Thu, 23 Jan 2014 09:57:18 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.63.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51016BE38; Thu, 23 Jan 2014 09:57:18 +0000 (GMT) Message-ID: <52E0E77E.5020800@cs.tcd.ie> Date: Thu, 23 Jan 2014 09:57:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ietf@hosed.org, =?ISO-8859-1?Q?=27Kriszti=E1n_Pint=E9r=27?= References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> In-Reply-To: <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dsfjdssdfsd@ietf.org Subject: [dsfjdssdfsd] evaluating stuff (was: Re: 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: Thu, 23 Jan 2014 09:57:22 -0000 (Great to see the discussion re-started, but I guess we can afford more than one subject line:-) On 01/23/2014 03:54 AM, ietf@hosed.org wrote: > Those of us who deal with FIPS 140 and Common Criteria are now being asked > to document entropy sources, First, my sympathies for having to deal with that. But I do wonder to what extent we're finding such evaluations really useful. I know they are formal form-filling requirements in various contexts, but I'm not so sure I'm that comfortable treating them as a first order requirement when it comes to things we do in the IETF. I have seen a number of credible arguments that such schemes, as applied to crypto implementations, are actually counter- productive. So - how important is it that any new work in the IETF on this topic be consistent with a requirement for implementations to be evaluated via such schemes? My take would be that that's not hugely important and should lose out to "doing the right thing," but given that some folks do need to suffer such evaluations, we should think about 'em but treat any evaluation-scheme-specific requirements only as nice-to-have level requirements. I expect vendors who are forced into doing it might disagree though. S. From Jeff.Hodges@KingsMountain.com Thu Jan 23 07:14:11 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 A80A21A0032 for ; Thu, 23 Jan 2014 07:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xTNGFtGsRAGY for ; Thu, 23 Jan 2014 07:14:08 -0800 (PST) Received: from alt-proxy11.mail.unifiedlayer.com (alt-proxy11.mail.unifiedlayer.com [74.220.211.241]) by ietfa.amsl.com (Postfix) with SMTP id 850961A000E for ; Thu, 23 Jan 2014 07:14:08 -0800 (PST) Received: (qmail 26026 invoked by uid 0); 23 Jan 2014 15:14:07 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy16.mail.unifiedlayer.com with SMTP; 23 Jan 2014 15:14:07 -0000 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=CxjeZe2lDpuYtKOs3m9FXpiIS5YnwSGqHSAiB8HRn88=; b=gZ73c0gGphAqpd9v6QUFGCTScUabZlHDWxszMI+6sThUjMuqUwVLz73faXoH5PSUOqLThh0WX1QQQAa0A1xQkFj9vZs05f220r3vmFzGhZtUhq3PYH0EoXk4z77PVXHn; Received: from [216.113.168.128] (port=25319 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1W6Lyp-0002lg-Mu for dsfjdssdfsd@ietf.org; Thu, 23 Jan 2014 08:14:07 -0700 Message-ID: <52E131BE.6090309@KingsMountain.com> Date: Thu, 23 Jan 2014 07:14:06 -0800 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} Subject: [dsfjdssdfsd] fyi: Pseudorandom Number Generation in Smart Cards: An Implementation, Performance and Randomness Analysis 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, 23 Jan 2014 15:14:11 -0000 of possible overall interest (in terms of the analysis aspects)... Akram, Raja Naeem, Konstantinos Markantonakis, and Keith Mayes.=20 "Pseudorandom Number Generation in Smart Cards: An Implementation,=20 Performance and Randomness Analysis." New Technologies, Mobility and=20 Security (NTMS), 2012 5th International Conference on. IEEE, 2012. http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Pap= er.pdf Abstract=97 Smart cards rely on pseudorandom number generators to provide uniqueness and freshness in their cryptographic services i.e. encryption and digital signatures. Their implementations are kept proprietary by smart card manufacturers in order to remain competitive. In this paper we look at how these generators are implemented in general purpose computers. How architecture of such generators can be modified to suit the smart card environment. Six variations of this modified model were implemented in Java Card along with the analysis of their performance and randomness. To analyse the randomness of the implemented algorithms, the NIST statistical test suite is used. Finally, an overall analysis is provided, that is useful for smart card designers to make informed decisions when implementing pseudorandom number generators. From jon@hosed.org Thu Jan 23 08:06:19 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 5671A1A0022 for ; Thu, 23 Jan 2014 08:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XzjFp2p_r6Xe for ; Thu, 23 Jan 2014 08:06:17 -0800 (PST) Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF21A001B for ; Thu, 23 Jan 2014 08:06:17 -0800 (PST) Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id 0D1F317091; Thu, 23 Jan 2014 08:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390493177; bh=CgBcbZMPLsLbOXZHYTVx+4XdVGHbYIKvXcNNIuMK0e0=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=k99sdRoGTxsJZfIKiwft4WlooclbHG/swk0/L3uXoMzTxTKEz20DjHJUmB/BZWwl8 lc3XVeOWJ+I+gMDtMpPC2mf3kLamtnAtqmH70/y1nqUVLePn7DxslylvOF1uroETUV w2ybjGCKzMVNrf/nH2npttiJTqtBsGVIUwS0r8yg= X-Virus-Scanned: amavisd-new at encrypted.net Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS6aUV7DQfYD; Thu, 23 Jan 2014 08:06:16 -0800 (PST) Received: from jgreent410s (76-220-43-250.lightspeed.sntcca.sbcglobal.net [76.220.43.250]) by firefly.encrypted.net (Postfix) with ESMTPA id A0FE21708C; Thu, 23 Jan 2014 08:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390493176; bh=CgBcbZMPLsLbOXZHYTVx+4XdVGHbYIKvXcNNIuMK0e0=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=IUcONSBKf9Gd6aiI6MNrf9xLpUNPjseyRmUqQhk3C19NMQdNe4neFh3OEF1qCqQXA lZ5Zh5HLPfsTLjrRF7LCP0Hk1GzFN2/Uw14SrEiRNtXSVTGBIYO6AYW7PbMy/fCZma e8dLFxPfXPPJ2/9DyjzXMfPVoAEigbFcpAW7n4aY= From: Sender: "Jon Green" To: "'Stephen Farrell'" References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <52E0E77E.5020800@cs.tcd.ie> In-Reply-To: Date: Thu, 23 Jan 2014 08:06:16 -0800 Message-ID: <04e701cf1855$0c2594b0$2470be10$@hosed.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3sdi2ZRq1Hpg6dXIL/pF6U42SYgGC9VecARNdWnIB1CvuGgLUDWy9AkHNKyYCxa4095pfFe4Q Content-Language: en-us Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] evaluating stuff (was: Re: 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: Thu, 23 Jan 2014 16:06:19 -0000 What I thought the topic was originally about was providing guidance to developers on dealing with randomness, should they choose to do that. = My point was only that there are valid reasons a developer might be forced = to deal with randomness rather than depend on the OS, and public-sector certification is one such reason. I know it sounds like paper pushing, but the people writing Common = Criteria profiles really are trying to get vendors to do the right thing. They = are also open to feedback from the vendor and developer community, and = within the last year the CC community has started "technical communities" which = are open to participation from anyone - for just that purpose. So if they = are doing the wrong thing, there is an opportunity to correct them. In the case of entropy specifically, if you believe what is written = here: https://www.niap-ccevs.org/pp/pp_nd_v1.1-add3.pdf ...it has done some good. By simply requiring vendors to think about = the problem, it got them to uncover deficiencies and make improvements. BTW this is a useful document to read to understand what the government = folks are going after when it comes to entropy. But back to your question: >So - how important is it that any new work in the IETF on >this topic be consistent with a requirement for implementations >to be evaluated via such schemes? Not important. The government certification people mandate that vendors implement IETF standards, not the other way around. Sometimes they pick subsets - for example "Product SHALL implement TLS 1.2, but only with specific ciphersuites (things based on various combinations of AES, RSA, ECDSA, ECDHE, etc.)" But no, I don't think we should let their = requirements drive standards activity. -Jon -- Jon Green jon@hosed.org http://www.hosed.org -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, January 23, 2014 1:57 AM To: ietf@hosed.org; 'Kriszti=E1n Pint=E9r' Cc: dsfjdssdfsd@ietf.org Subject: evaluating stuff (was: Re: [dsfjdssdfsd] Any plans for drafts = or discussions on here?) (Great to see the discussion re-started, but I guess we can afford more than one subject line:-) On 01/23/2014 03:54 AM, ietf@hosed.org wrote: > Those of us who deal with FIPS 140 and Common Criteria are now being = asked > to document entropy sources, First, my sympathies for having to deal with that. But I do wonder to what extent we're finding such evaluations really useful. I know they are formal form-filling requirements in various contexts, but I'm not so sure I'm that comfortable treating them as a first order requirement when it comes to things we do in the IETF. I have seen a number of credible arguments that such schemes, as applied to crypto implementations, are actually counter- productive. So - how important is it that any new work in the IETF on this topic be consistent with a requirement for implementations to be evaluated via such schemes? My take would be that that's not hugely important and should lose out to "doing the right thing," but given that some folks do need to suffer such evaluations, we should think about 'em but treat any evaluation-scheme-specific requirements only as nice-to-have level requirements. I expect vendors who are forced into doing it might disagree though. S. From jon@hosed.org Thu Jan 23 07:59:50 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 EE8031A001A for ; Thu, 23 Jan 2014 07:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, 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 pDGeY2XCAe8Y for ; Thu, 23 Jan 2014 07:59:48 -0800 (PST) Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id A92DA1A0005 for ; Thu, 23 Jan 2014 07:59:48 -0800 (PST) Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id 5522917048; Thu, 23 Jan 2014 07:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390492787; bh=CgBcbZMPLsLbOXZHYTVx+4XdVGHbYIKvXcNNIuMK0e0=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=E+DZmf6K2PGDjPbcDEHochNYCAYdLslNTJXDgI/7/2IK3zUyE+INeBoqHIfqIKBBv S+7+aUDBkYHOnG77GtCHyZbaEfTt9H0f/bccE4TM7Y6BJck4OOEpi/2w8zUQtx+NCv YHUvSfCC+O9wNBgknvFknTtKmeAMkDnSVL04n5oA= X-Virus-Scanned: amavisd-new at encrypted.net Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO7mMLrm5r-x; Thu, 23 Jan 2014 07:59:47 -0800 (PST) Received: from jgreent410s (76-220-43-250.lightspeed.sntcca.sbcglobal.net [76.220.43.250]) by firefly.encrypted.net (Postfix) with ESMTPA id CC42F1706D; Thu, 23 Jan 2014 07:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hosed.org; s=default; t=1390492787; bh=CgBcbZMPLsLbOXZHYTVx+4XdVGHbYIKvXcNNIuMK0e0=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=E+DZmf6K2PGDjPbcDEHochNYCAYdLslNTJXDgI/7/2IK3zUyE+INeBoqHIfqIKBBv S+7+aUDBkYHOnG77GtCHyZbaEfTt9H0f/bccE4TM7Y6BJck4OOEpi/2w8zUQtx+NCv YHUvSfCC+O9wNBgknvFknTtKmeAMkDnSVL04n5oA= From: "Jon Green" To: "'Stephen Farrell'" , =?Windows-1252?Q?'Kriszti=E1n_Pint=E9r'?= References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <52E0E77E.5020800@cs.tcd.ie> In-Reply-To: <52E0E77E.5020800@cs.tcd.ie> Date: Thu, 23 Jan 2014 07:59:46 -0800 Message-ID: <04e201cf1854$23db5550$6b91fff0$@hosed.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3sdi2ZRq1Hpg6dXIL/pF6U42SYgGC9VecARNdWnIB1CvuGgLUDWy9AkHNKyaadT3rAA== Content-Language: en-us X-Mailman-Approved-At: Thu, 23 Jan 2014 09:17:53 -0800 Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] evaluating stuff (was: Re: 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: Thu, 23 Jan 2014 15:59:50 -0000 What I thought the topic was originally about was providing guidance to developers on dealing with randomness, should they choose to do that. = My point was only that there are valid reasons a developer might be forced = to deal with randomness rather than depend on the OS, and public-sector certification is one such reason. I know it sounds like paper pushing, but the people writing Common = Criteria profiles really are trying to get vendors to do the right thing. They = are also open to feedback from the vendor and developer community, and = within the last year the CC community has started "technical communities" which = are open to participation from anyone - for just that purpose. So if they = are doing the wrong thing, there is an opportunity to correct them. In the case of entropy specifically, if you believe what is written = here: https://www.niap-ccevs.org/pp/pp_nd_v1.1-add3.pdf ...it has done some good. By simply requiring vendors to think about = the problem, it got them to uncover deficiencies and make improvements. BTW this is a useful document to read to understand what the government = folks are going after when it comes to entropy. But back to your question: >So - how important is it that any new work in the IETF on >this topic be consistent with a requirement for implementations >to be evaluated via such schemes? Not important. The government certification people mandate that vendors implement IETF standards, not the other way around. Sometimes they pick subsets - for example "Product SHALL implement TLS 1.2, but only with specific ciphersuites (things based on various combinations of AES, RSA, ECDSA, ECDHE, etc.)" But no, I don't think we should let their = requirements drive standards activity. -Jon -- Jon Green jon@hosed.org http://www.hosed.org -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, January 23, 2014 1:57 AM To: ietf@hosed.org; 'Kriszti=E1n Pint=E9r' Cc: dsfjdssdfsd@ietf.org Subject: evaluating stuff (was: Re: [dsfjdssdfsd] Any plans for drafts = or discussions on here?) (Great to see the discussion re-started, but I guess we can afford more than one subject line:-) On 01/23/2014 03:54 AM, ietf@hosed.org wrote: > Those of us who deal with FIPS 140 and Common Criteria are now being = asked > to document entropy sources, First, my sympathies for having to deal with that. But I do wonder to what extent we're finding such evaluations really useful. I know they are formal form-filling requirements in various contexts, but I'm not so sure I'm that comfortable treating them as a first order requirement when it comes to things we do in the IETF. I have seen a number of credible arguments that such schemes, as applied to crypto implementations, are actually counter- productive. So - how important is it that any new work in the IETF on this topic be consistent with a requirement for implementations to be evaluated via such schemes? My take would be that that's not hugely important and should lose out to "doing the right thing," but given that some folks do need to suffer such evaluations, we should think about 'em but treat any evaluation-scheme-specific requirements only as nice-to-have level requirements. I expect vendors who are forced into doing it might disagree though. S. From paul.hoffman@vpnc.org Thu Jan 23 10:01: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 AAD321A0096 for ; Thu, 23 Jan 2014 10:01:24 -0800 (PST) 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 zd7uebg3ZUWb for ; Thu, 23 Jan 2014 10:01:20 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA81A0091 for ; Thu, 23 Jan 2014 10:01:17 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0NHeabU031422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jan 2014 10:40:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <52E0E77E.5020800@cs.tcd.ie> Date: Thu, 23 Jan 2014 10:00:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8911E8B6-6049-44A8-9172-02AFD226EAFB@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <52E0E77E.5020800@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1827) Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] evaluating stuff (was: Re: 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: Thu, 23 Jan 2014 18:01:24 -0000 On Jan 23, 2014, at 1:57 AM, Stephen Farrell = wrote: > But I do wonder to what extent we're finding such evaluations > really useful. Not. > I know they are formal form-filling requirements > in various contexts, but I'm not so sure I'm that comfortable > treating them as a first order requirement when it comes to > things we do in the IETF. Quite right. The base requirement boils down to "prove that input X gave = the DBRG N bits of entropy that could not be known by any external = system". That proof is always hand-waving for nearly any typical = computer or network device. If the inputs are chosen conservatively = enough, you can be confident that you got N unguessable bits, but you = cannot prove it. > I have seen a number of credible arguments that such schemes, > as applied to crypto implementations, are actually counter- > productive. Exactly. Vendors tend to copy the claims of other systems that have = earlier passed the evaluations, even when the claims do not fully apply = to the new system. After a few rounds of this, the claims are = meaningless and the vendor is not trying hard enough to get truly random = bits. > So - how important is it that any new work in the IETF on > this topic be consistent with a requirement for implementations > to be evaluated via such schemes? >=20 > My take would be that that's not hugely important and should > lose out to "doing the right thing," but given that some folks > do need to suffer such evaluations, we should think about 'em > but treat any evaluation-scheme-specific requirements only as > nice-to-have level requirements. Advice on where you might find the bits in typical computers and network = boxes is probably useful. Advice about the value of N for input X is = actively dangerous. --Paul Hoffman= From pinterkr@gmail.com Thu Jan 23 12:40:12 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 58A761A00C5 for ; Thu, 23 Jan 2014 12:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 lehlccyDykRf for ; Thu, 23 Jan 2014 12:40:11 -0800 (PST) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B71641A0197 for ; Thu, 23 Jan 2014 12:40:10 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a15so631320eae.9 for ; Thu, 23 Jan 2014 12:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=csTLfGH+095QFNzAaqOMPlGvwOiaLeKlTLVT7x6YzHQ=; b=SrQK74GkSjQj7eWxW/CiMPoVYpP4nKKpTrvC646NaEpycfqEKfFVLDbxPvU7wMuD2U 8BG6V7BrSDkQmT0+IDua643xsbViIcwchAcrK1Rbfi0nF4PRqY6IeTD3/cr2esLTEbUG vWJPXFRHX8uii/D6UHWsTp9Kse3SRjhe7yLynIyGAbGSUkPc3WTXf1LmHf503oQOUhGb t9OpfOMT0RGfFMDeapNRu8MnVqQ+kY147UDeSE+bpCTHfuLNW1pDN36QI+XjpwFAacgQ onxJThwCuOhw/Y75pMOR1/5GlFUjhhJUn2gzrdLvE1i2PkZ7SYGRn/Lxlt77ojY6m/G9 ABqw== X-Received: by 10.14.202.8 with SMTP id c8mr4585433eeo.88.1390509609397; Thu, 23 Jan 2014 12:40:09 -0800 (PST) Received: from [192.168.2.244] (catv-176-63-52-22.catv.broadband.hu. [176.63.52.22]) by mx.google.com with ESMTPSA id b41sm42942939eef.16.2014.01.23.12.40.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jan 2014 12:40:08 -0800 (PST) Date: Thu, 23 Jan 2014 21:40:20 +0100 From: =?windows-1252?Q?Kriszti=E1n_Pint=E9r?= X-Priority: 3 (Normal) Message-ID: <15541579.20140123214020@gmail.com> To: ietf@hosed.org In-Reply-To: <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dsfjdssdfsd@ietf.org 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: Thu, 23 Jan 2014 20:40:12 -0000 ietf@hosed.org (at Thursday, January 23, 2014, 4:54:59 AM): > The problem with relying on the OS is that you're not always sure what the > OS is doing. Example: If I run Linux under ESXi on a headless server, with > an SSD for a disk, and I use the Ethernet NIC built into the motherboard, > where is the entropy for /dev/random coming from? you do know what the OS does, you have either a source code, or at least a statement that everything is fine. you choose the OS with this knowledge in mind. it is another issue that in certain systems, the opsys might be not good enough. but i doubt that you can write RFC that is of any use for such special systems. plus, it is still advisable that you only implement your additional entropy collection, and just feed it back to the OS. > Those of us who deal with FIPS 140 and Common Criteria are now being asked > to document entropy sources, we need to make clear what the goal is. me being new here, maybe i just missed it, but i'm not sure what do we want: a, building a secure system b, building a system that can be marketed as secure c, building a FIPS compliant system because i claim that these are very different. if you want to be FIPS compliant, you probably need to do a whole sort of silly things that helps nobody in no way. but again, this won't be too much aided with an RFC, or any "best practices" document. nor i personally care much. marketability of a system can be affected by any number of things, probably boasting a lot of numbered acronyms, like RFCs as well. but i'm not into this kind of psychology. but if we aim at security, the OS can provide the best service here. yeah, windows don't, but really, how secure your application will be on windows anyway? you don't need to go over that level. > The various DRBGs are fine IMHO for handing out bits of random to an > application, and lacking anything better today I would certainly encourage > developers to use one. But the question is how do we seed the DRBG in the > first place? i certainly agree that we are well equipped with good DRBGs (which linux still refuses to include, forget about windows). do you happen to know fortuna, and especially its entropy collection policy? i think it is kind of a cool concept, except does not really solve the problem you mentioned before, namely early entropy gathering. one more point: it is not only about creating good random. you also need to protect it. what sources of entropy do you have that other processes on the same system don't? what information do you leak during the collection phase? a little bit harder problem than a DRBG. From michael.hammer@yaanatech.com Thu Jan 23 12:49:35 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 B9D781A0161 for ; Thu, 23 Jan 2014 12:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 QbRX44SeCgo1 for ; Thu, 23 Jan 2014 12:49:33 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id BC9991A00C5 for ; Thu, 23 Jan 2014 12:49:33 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 12:49:33 -0800 From: Michael Hammer To: "pinterkr@gmail.com" , "ietf@hosed.org" Thread-Topic: [dsfjdssdfsd] Any plans for drafts or discussions on here? Thread-Index: AQHPFik7i/q5nfCSa0yR/K7nGCDgcJqOvseAgAArLACAAqUWgIAAqIaAgAEY5AD//3wacA== Date: Thu, 23 Jan 2014 20:49:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> In-Reply-To: <15541579.20140123214020@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.212] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F3_01CF1839.8F838F40" MIME-Version: 1.0 Cc: "dsfjdssdfsd@ietf.org" 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: Thu, 23 Jan 2014 20:49:35 -0000 ------=_NextPart_000_00F3_01CF1839.8F838F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This may get off-topic, but are there good software tools for testing entropy,=20 that could help applications determine if the underlying system is = giving them good input? Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Kriszti=E1n Pint=E9r Sent: Thursday, January 23, 2014 12:40 PM To: ietf@hosed.org Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? ietf@hosed.org (at Thursday, January 23, 2014, 4:54:59 AM): > The problem with relying on the OS is that you're not always sure what = > the OS is doing. Example: If I run Linux under ESXi on a headless=20 > server, with an SSD for a disk, and I use the Ethernet NIC built into=20 > the motherboard, where is the entropy for /dev/random coming from? you do know what the OS does, you have either a source code, or at least = a statement that everything is fine. you choose the OS with this knowledge = in mind. it is another issue that in certain systems, the opsys might be not good enough. but i doubt that you can write RFC that is of any use for such special systems. plus, it is still advisable that you only implement = your additional entropy collection, and just feed it back to the OS. > Those of us who deal with FIPS 140 and Common Criteria are now being=20 > asked to document entropy sources, we need to make clear what the goal is. me being new here, maybe i just missed it, but i'm not sure what do we want: a, building a secure system b, building a system that can be marketed as secure c, building a FIPS compliant system because i claim that these are very different. if you want to be FIPS compliant, you probably need to do a whole sort of silly things that = helps nobody in no way. but again, this won't be too much aided with an RFC, = or any "best practices" document. nor i personally care much. marketability of a system can be affected by any number of things, = probably boasting a lot of numbered acronyms, like RFCs as well. but i'm not into this kind of psychology. but if we aim at security, the OS can provide the best service here. yeah, windows don't, but really, how secure your application will be on windows anyway? you don't need to go over that level. > The various DRBGs are fine IMHO for handing out bits of random to an=20 > application, and lacking anything better today I would certainly=20 > encourage developers to use one. But the question is how do we seed=20 > the DRBG in the first place? i certainly agree that we are well equipped with good DRBGs (which linux still refuses to include, forget about windows). do you happen to know fortuna, and especially its entropy collection = policy? i think it is kind of a cool concept, except does not really solve the problem you mentioned before, namely early entropy gathering. one more point: it is not only about creating good random. you also need = to protect it. what sources of entropy do you have that other processes on = the same system don't? what information do you leak during the collection = phase? a little bit harder problem than a DRBG. _______________________________________________ dsfjdssdfsd mailing list dsfjdssdfsd@ietf.org https://www.ietf.org/mailman/listinfo/dsfjdssdfsd ------=_NextPart_000_00F3_01CF1839.8F838F40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEy MzIwNDkzMVowIwYJKoZIhvcNAQkEMRYEFGSamR3taRtkrMxMwIeyUIR4tQY3MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAQdumE/0jSp/LRSNqLC8VEcXlJtpgzE1QQ7wOzHTR mFs+ZqymRAfPh3XjO+ZBi150FKNyVMf7nXcuHpN72UudrAHUrrhKOvU5BErRPR2OS2pbpB/SAVHj GUdkJCijbwSBs+Ida7D/4fk687HVVH+GQlFd3jZqcBUGqq52FE8uuScvkWfLRsvo/ilgw/8/D35U 7eh+Qgyrg6SMuqhr7/feeaxeP9MoVFIOyNuzkv2wFkJHmR2yIp9oGWz1jydyP6v9DDSVOAjCJD9g sit3TA9mpYWZpO7nSp0pLaF538Lb5yHrB2+injxzJJP2FU3yazr+maWy/jfBi22UBOQzDU1hLwAA AAAAAA== ------=_NextPart_000_00F3_01CF1839.8F838F40-- From pinterkr@gmail.com Thu Jan 23 14:37: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 667EC1A0403 for ; Thu, 23 Jan 2014 14:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 M1AUaJBD4E1W for ; Thu, 23 Jan 2014 14:37:57 -0800 (PST) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 078BC1A03DC for ; Thu, 23 Jan 2014 14:37:56 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id d49so643792eek.34 for ; Thu, 23 Jan 2014 14:37:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=7B1iStkrXoRRDhqKXtTXuCjBnEg6aLHdZJruCX5ifa8=; b=nUKFoIF2QyBv64xT/2xr/PByd0g2mH/rLdd28FtomFmmrEC5EPqbTR+zSVzpERwXM6 6tab/vPr7X6VDvAQbrxSa3PCe1qYm8lg8TURsd3JcNEgtZ7Fk0L3XXvrAs7hDCjWAm+f mZZactH2iKGL19p7KJ5HJs40Br/P1EYdPiF1zu4FkiZQOJ28seSkIsJI58p6dgzNWuPS FbNyZ8j+sNGh7DSJzvsxuQfGhDUngkUI+Z46dHnmWWuwECg8fNL1RARTxKEJRFGseWaK sSBTegQhAbyS+QMzQbACq/jS5XP/UwRG1eYrBSgT+tA2k/rFqDRMAsvc6UG4CoA1BBNC SG4A== X-Received: by 10.14.209.129 with SMTP id s1mr9495290eeo.21.1390516675694; Thu, 23 Jan 2014 14:37:55 -0800 (PST) Received: from [192.168.2.244] (catv-176-63-52-22.catv.broadband.hu. [176.63.52.22]) by mx.google.com with ESMTPSA id o43sm8605068eef.12.2014.01.23.14.37.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jan 2014 14:37:55 -0800 (PST) Date: Thu, 23 Jan 2014 23:38:07 +0100 From: =?iso-8859-1?Q?Kriszti=E1n_Pint=E9r?= X-Priority: 3 (Normal) Message-ID: <204592464.20140123233807@gmail.com> To: Michael Hammer In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "dsfjdssdfsd@ietf.org" , "ietf@hosed.org" 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: Thu, 23 Jan 2014 22:37:58 -0000 Michael Hammer (at Thursday, January 23, 2014, 9:49:32 PM): > This may get off-topic, but are there good software tools for testing > entropy, > that could help applications determine if the underlying system is giving > them good input? disclaimer: i'm no expert, it is just what i gathered. (i'm pretty much interested in randomness.) short answer: no long answer: in some situations yes. if you are handed a bunch of data, all you can do is to try different techniques to put an upper limit on the entropy. for example you can calculate the shannon entropy assuming independent bits. then you can hypothesize some interdependence, and see if you can compress the data. you can apply different lossless compression methods. the better compression you find puts an upper limit on the entropy. but never a lower limit. you can only do better if you have an idea about the process that created the data. for example you might assume that it is mostly thermal noise. you can assume that thermal noise has some frequency distribution, or energy or whatever, etc. within this assumption, you can determine the entropy content by measurements. but at this point, you are pretty much prone to two errors: 1, what if your assumption is wrong and 2, what if your physical model overestimates the unpredictability of the given system. example for the former: the signal might be largely controllable by an external EM interference, and then you measure not noise, but attacker controlled data. example for the latter: a smartass scientist might come up with a better physical model for thermal noise. it is also important to note that entropy is observer dependent. we actually talk about the entropy as seen by the attacker. but it is not straightforward to assess what is actually visible to an attacker and what is not. observation methods improve with time. From michael.hammer@yaanatech.com Thu Jan 23 15:19:07 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 077391A0449 for ; Thu, 23 Jan 2014 15:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 NroVwkMYPaBZ for ; Thu, 23 Jan 2014 15:19:04 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id DD0771A035C for ; Thu, 23 Jan 2014 15:19:04 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 15:19:04 -0800 From: Michael Hammer To: "pinterkr@gmail.com" Thread-Topic: [dsfjdssdfsd] Any plans for drafts or discussions on here? Thread-Index: AQHPFik7i/q5nfCSa0yR/K7nGCDgcJqOvseAgAArLACAAqUWgIAAqIaAgAEY5AD//3wacIAApM6A//+D2yA= Date: Thu, 23 Jan 2014 23:19:03 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> In-Reply-To: <204592464.20140123233807@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.212] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011F_01CF184E.72EE4F90" MIME-Version: 1.0 Cc: "dsfjdssdfsd@ietf.org" , "ietf@hosed.org" 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: Thu, 23 Jan 2014 23:19:07 -0000 ------=_NextPart_000_011F_01CF184E.72EE4F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hmmm... that makes it sound rather subjective. If we don't have objective measures,=20 then who is to say that one's randomness is better or worse than = another? Understand that user data input may or may not have good entropy. But, hope that would be the only source of any output entropy,=20 given good encryption algorithms and random keys. Was thinking in terms of how an app with access to alternate random = sources, some which might be from OS or from some software, might choose one over another. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: Kriszti=E1n Pint=E9r [mailto:pinterkr@gmail.com]=20 Sent: Thursday, January 23, 2014 2:38 PM To: Michael Hammer Cc: ietf@hosed.org; dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? Michael Hammer (at Thursday, January 23, 2014, 9:49:32 PM): > This may get off-topic, but are there good software tools for testing=20 > entropy, that could help applications determine if the underlying=20 > system is giving them good input? disclaimer: i'm no expert, it is just what i gathered. (i'm pretty much interested in randomness.) short answer: no long answer: in some situations yes. if you are handed a bunch of data, = all you can do is to try different techniques to put an upper limit on the entropy. for example you can calculate the shannon entropy assuming independent bits. then you can hypothesize some interdependence, and see = if you can compress the data. you can apply different lossless compression methods. the better compression you find puts an upper limit on the = entropy. but never a lower limit. you can only do better if you have an idea about the process that = created the data. for example you might assume that it is mostly thermal noise. = you can assume that thermal noise has some frequency distribution, or energy = or whatever, etc. within this assumption, you can determine the entropy = content by measurements. but at this point, you are pretty much prone to two = errors: 1, what if your assumption is wrong and 2, what if your physical model overestimates the unpredictability of the given system. example for the former: the signal might be largely controllable by an external EM interference, and then you measure not noise, but attacker controlled = data. example for the latter: a smartass scientist might come up with a better physical model for thermal noise. it is also important to note that entropy is observer dependent. we = actually talk about the entropy as seen by the attacker. but it is not straightforward to assess what is actually visible to an attacker and = what is not. observation methods improve with time. ------=_NextPart_000_011F_01CF184E.72EE4F90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEy MzIzMTkwM1owIwYJKoZIhvcNAQkEMRYEFDxEOntg8dL2Mb+bEcvKmeNdHtRxMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOSvB9U4ae4VsPgkB/dKK2ghJ/QNsUKgnU2IjVlHi VThVVCv6NpZJSFkoAYuHFAtbZrgAmoFUf3FkfDf1nDEQM01tBK0TDZMyVV6Mq5zth5x4TB1EGa2y PFVI/jK3gs9vLAmpIyXQ/1eA8bZqGZhHy7/qWz2JU4OdYfXC320WJRfySg25FYhcAr+WrEQK/pk5 wUwqnCF0wyWMJB0OPOllU7GjXj5mbxoj6cRy5yxkjJ5zynpLif5ri7yFGO+XdBM2r3J5bsFZnGpe LhcbmOhimOinJVjha6ik+hLH2JU9RFIU5XAIOT0B+mIF7Yo7NwroKwV1GixYJP9Bvt9MTSFBEwAA AAAAAA== ------=_NextPart_000_011F_01CF184E.72EE4F90-- From paul.hoffman@vpnc.org Thu Jan 23 16:01: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 D17041A048A for ; Thu, 23 Jan 2014 16:01:58 -0800 (PST) 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 Pi54RlM2-f51 for ; Thu, 23 Jan 2014 16:01:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E36301A01D3 for ; Thu, 23 Jan 2014 16:01:57 -0800 (PST) Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0NNfjZr042379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jan 2014 16:41:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90] Content-Type: multipart/signed; boundary="Apple-Mail=_2F6C65AB-DA7D-4B28-AE6A-699286302952"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 23 Jan 2014 16:01:45 -0800 Message-Id: References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) Cc: "dsfjdssdfsd@ietf.org" 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: Fri, 24 Jan 2014 00:01:59 -0000 --Apple-Mail=_2F6C65AB-DA7D-4B28-AE6A-699286302952 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 23, 2014, at 3:19 PM, Michael Hammer = wrote: > Hmmm... that makes it sound rather subjective. The value of an individual bit from an entropy source is subjective. > If we don't have objective measures,=20 > then who is to say that one's randomness is better or worse than = another? Once there is agreement on the amount of entropy in a given set of = initial bits, there are objective measures about the effectiveness of = ways to distribute them. > Understand that user data input may or may not have good entropy. > But, hope that would be the only source of any output entropy,=20 > given good encryption algorithms and random keys. Adding additional sources of output entropy, if done correctly, is = *always* at least as good as only using the initial bits. --Paul Hoffman --Apple-Mail=_2F6C65AB-DA7D-4B28-AE6A-699286302952 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJS4a1xAAoJEJz/fXByZmLZVDsH/0kSdbsotLbCuJ26HVgDr35H ePbW3RZhULxaenCcQRwGaKryFOCsJq+7FLWxLa5VHnREp78cDvKWBR2FF77Hv5rK 1+adcd/bOVH5MNLojtL+AGWSI9sEdXl5bhwvYQhGdV0Qws1SFc14DpfFyyY5zmId 6pU61aa/w1DQfTjEgmg/mKdcGBwMhHWGblsvZIo8FjSrkzYCbl8Kfr7Sklcuc9g0 e/4PZnhGESxJKrYSIOdj6oLjIXsGBeiwTYXM3u35oKYnvqXPlZKGcklGEB9Fp+0D yd8o4Yd9h0uWDNypZlGyO3AiLycAMpwNLb0zGbghISUdIyH4j9VkBXWFuya72fg= =5drE -----END PGP SIGNATURE----- --Apple-Mail=_2F6C65AB-DA7D-4B28-AE6A-699286302952-- From Jeff.Hodges@KingsMountain.com Thu Jan 23 16:32: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 ECCEC1A04A7 for ; Thu, 23 Jan 2014 16:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0UXEOrTtwz4G for ; Thu, 23 Jan 2014 16:32:30 -0800 (PST) Received: from oproxy19-pub.mail.unifiedlayer.com (oproxy19-pub.mail.unifiedlayer.com [70.40.200.33]) by ietfa.amsl.com (Postfix) with SMTP id 0980E1A04A3 for ; Thu, 23 Jan 2014 16:32:29 -0800 (PST) Received: (qmail 7598 invoked by uid 0); 24 Jan 2014 00:32:29 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy19.mail.unifiedlayer.com with SMTP; 24 Jan 2014 00:32:29 -0000 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=lsgqF9GarTbi/b5jSCBlaAw/iREvBIBzmwfVbmhpQtA=; b=viBaX62rsNpw6/DfOevW0ZJmsQrqA9wUYcTgfpsWGPPNs9Fd6NGHKYGPl8+sUHOYhUXE9ezZYHzAJJQ1PYnJD0R76qooVmB073yeHU56Qe/uykV29L+wJHYMea2PXlN4; Received: from [70.197.2.244] (port=9931 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1W6UhA-0005hQ-IU for dsfjdssdfsd@ietf.org; Thu, 23 Jan 2014 17:32:28 -0700 Message-ID: <52E1B499.8050404@KingsMountain.com> Date: Thu, 23 Jan 2014 16:32:25 -0800 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: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.2.244 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dsfjdssdfsd] software tools for testing entropy (was: 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: Fri, 24 Jan 2014 00:32:33 -0000 > are there good software tools for testing entropy, that could help > applications determine if the underlying system is giving them good > input? well, from.. [0] Akram, Raja Naeem, Konstantinos Markantonakis, and Keith Mayes. "Pseudorandom Number Generation in Smart Cards: An Implementation, Performance and Randomness Analysis." New Technologies, Mobility and Security (NTMS), 2012 5th International Conference on. IEEE, 2012. http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper.pdf ..there's the sections reproduced at [1] below which may (or may not) be helpful. also, NIST has these resources.. NIST SP 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Application. http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP800-22rev1a.pdf Random Number Generators (RNG) Testing Requirements: http://csrc.nist.gov/groups/STM/cavp/index.html#04 RNG Test Vectors http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngtestvectors.zip One could also ask the authors of [0] if they might share their impl. hth, =JeffH [1] E. Experimental Proof To provide experimental proof, the NIST statistical test suite was applied. Each algorithm was provided with a common seed file, and generated sequences from it were saved in a binary file. This binary file was used as input to the statistical test. Point to note here is that seed files given to all algorithms were the same. The reason for doing so was to analyse differences in the quality of output while using the same entropy source. For statistical analysis, each algorithm was executed to generate 1,048,578 pseudorandom sequences of 128 bits. Concatenating the outputs into a binary file that was then used for NIST SP 800-22 statistical analysis. The results of each algorithm are listed in Appendix A. Taking into account the Common Criteria AIS 20 [18], our implementation fulfils the requirements for the K4 DRNG. Below is the discussion on how our implementation satisfies these requirements. 1) K1 DRNG: Its a simple requirement that states that if the generated values is of set C =f c1, c2, c3, .., cm g then all members of the set should be distinct regardless of the statistical properties. 2) K2 DRNG: Requires that the implementation should satisfy the statistical properties such as monobit test, poker test and tests on runs. Our implementations were subjected to the NIST SP 800-22 test suite. 3) K3 DRNG: This requires that the entropy of the PRNG is at least 80. All SHA based algorithms has 440 bits seed and block cipher based algorithms has 128 bits seed. All of the seed values were chosen from an external high entropy source that is carefully tested. 4) K4 DRNG: This level requires that the PRNG should be forward-secure. A PRNG is forward-secure if after n iteration of the PRNG, a malicious user is unable to guess the internal state of the generator. The implemented PRNG feed back to the internal seed that is changing in each of the iterations. Furthermore, block cipher based implementation of the PRNG use different key in each of the iterations. Even retrieving a cryptographic key would not help a malicious user to successfully know the entire state of the seed file. In our implementations we tested SHA and block cipher based algorithms for the PRNGs. In general block cipher based algorithms, only a single key is used for the entire lifetime of the generator. However, we have tested that a PRNG could be modified to use a new key on each execution of the generator. The internal key generation mechanism of the block cipher based PRNG implementations are light weight and they do not hamper the overall performance of the generator. Therefore, it could be argued that it provides a more secure block cipher based PRNG then an PRNG that only uses a single key for entire lifetime. Table IV details the percentage of passing sequences pro duced by individual algorithms. As it is evident from table III and IV, there is not a big difference between the implemented algorithms both in terms of performance and percentage of sequence passing the NIST statistical tests. Of particular note, if we take the accumulated average of the passing sequences percentage in the table IV an interesting result emerges. The SHA-1 performs comparative better than other algorithms and AES based PRNG has the least accumulated average of passing sequence as illustrated in figure 4. This measure represents the randomness of the generated sequences - not the security of the algorithm. If we also account for the performance, SHA based algorithms perform better than the encryption based algorithms (e.g. DES and AES). V. CONCLUSION AND FUTURE RESEARCH DIRECTIONS ... Our research into the possibility of using a test suite like NIST SP 800-SP to check pseudorandom number generators in smart cards has showed that it is a workable concept. The tests listed in the NIST SP 800-22 are substantially more then the one recommended for the smart card pseudorandom number generators in AIS20 [18] and AIS31 [13]. This research has demonstrated that even with limited resources and an entropy constrained environment like a smart card, good quality pseudorandom sequences can be generated that can satisfy all the requirements for a PRNG even the ones that are used for general purpose computers. ... --- end From michael.hammer@yaanatech.com Thu Jan 23 16:41:07 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 F2E5A1A0491 for ; Thu, 23 Jan 2014 16:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 mxHD36ytWfHX for ; Thu, 23 Jan 2014 16:41:04 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 89B8B1A0224 for ; Thu, 23 Jan 2014 16:41:04 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 16:41:03 -0800 From: Michael Hammer To: "Jeff.Hodges@KingsMountain.com" , "dsfjdssdfsd@ietf.org" Thread-Topic: [dsfjdssdfsd] software tools for testing entropy (was: Any plans for drafts or discussions on here?) Thread-Index: AQHPGJv+nJMhr9DohUaIoac1IFVu95qTCHrg Date: Fri, 24 Jan 2014 00:41:00 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF190ED@sc9-ex2k10mb1.corp.yaanatech.com> References: <52E1B499.8050404@KingsMountain.com> In-Reply-To: <52E1B499.8050404@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.212] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0180_01CF1859.E5493590" MIME-Version: 1.0 Subject: Re: [dsfjdssdfsd] software tools for testing entropy (was: 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: Fri, 24 Jan 2014 00:41:07 -0000 ------=_NextPart_000_0180_01CF1859.E5493590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks. This is useful to me. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of =JeffH Sent: Thursday, January 23, 2014 4:32 PM To: IETF Pseudorandom Number Generator PRNG discussion list Subject: Re: [dsfjdssdfsd] software tools for testing entropy (was: Any plans for drafts or discussions on here?) > are there good software tools for testing entropy, that could help > applications determine if the underlying system is giving them good > input? well, from.. [0] Akram, Raja Naeem, Konstantinos Markantonakis, and Keith Mayes. "Pseudorandom Number Generation in Smart Cards: An Implementation, Performance and Randomness Analysis." New Technologies, Mobility and Security (NTMS), 2012 5th International Conference on. IEEE, 2012. http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper. pdf ..there's the sections reproduced at [1] below which may (or may not) be helpful. also, NIST has these resources.. NIST SP 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Application. http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP800-22rev1a.pdf Random Number Generators (RNG) Testing Requirements: http://csrc.nist.gov/groups/STM/cavp/index.html#04 RNG Test Vectors http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngtestvectors.zip One could also ask the authors of [0] if they might share their impl. hth, =JeffH [1] E. Experimental Proof To provide experimental proof, the NIST statistical test suite was applied. Each algorithm was provided with a common seed file, and generated sequences from it were saved in a binary file. This binary file was used as input to the statistical test. Point to note here is that seed files given to all algorithms were the same. The reason for doing so was to analyse differences in the quality of output while using the same entropy source. For statistical analysis, each algorithm was executed to generate 1,048,578 pseudorandom sequences of 128 bits. Concatenating the outputs into a binary file that was then used for NIST SP 800-22 statistical analysis. The results of each algorithm are listed in Appendix A. Taking into account the Common Criteria AIS 20 [18], our implementation fulfils the requirements for the K4 DRNG. Below is the discussion on how our implementation satisfies these requirements. 1) K1 DRNG: Its a simple requirement that states that if the generated values is of set C =f c1, c2, c3, .., cm g then all members of the set should be distinct regardless of the statistical properties. 2) K2 DRNG: Requires that the implementation should satisfy the statistical properties such as monobit test, poker test and tests on runs. Our implementations were subjected to the NIST SP 800-22 test suite. 3) K3 DRNG: This requires that the entropy of the PRNG is at least 80. All SHA based algorithms has 440 bits seed and block cipher based algorithms has 128 bits seed. All of the seed values were chosen from an external high entropy source that is carefully tested. 4) K4 DRNG: This level requires that the PRNG should be forward-secure. A PRNG is forward-secure if after n iteration of the PRNG, a malicious user is unable to guess the internal state of the generator. The implemented PRNG feed back to the internal seed that is changing in each of the iterations. Furthermore, block cipher based implementation of the PRNG use different key in each of the iterations. Even retrieving a cryptographic key would not help a malicious user to successfully know the entire state of the seed file. In our implementations we tested SHA and block cipher based algorithms for the PRNGs. In general block cipher based algorithms, only a single key is used for the entire lifetime of the generator. However, we have tested that a PRNG could be modified to use a new key on each execution of the generator. The internal key generation mechanism of the block cipher based PRNG implementations are light weight and they do not hamper the overall performance of the generator. Therefore, it could be argued that it provides a more secure block cipher based PRNG then an PRNG that only uses a single key for entire lifetime. Table IV details the percentage of passing sequences pro duced by individual algorithms. As it is evident from table III and IV, there is not a big difference between the implemented algorithms both in terms of performance and percentage of sequence passing the NIST statistical tests. Of particular note, if we take the accumulated average of the passing sequences percentage in the table IV an interesting result emerges. The SHA-1 performs comparative better than other algorithms and AES based PRNG has the least accumulated average of passing sequence as illustrated in figure 4. This measure represents the randomness of the generated sequences - not the security of the algorithm. If we also account for the performance, SHA based algorithms perform better than the encryption based algorithms (e.g. DES and AES). V. CONCLUSION AND FUTURE RESEARCH DIRECTIONS ... Our research into the possibility of using a test suite like NIST SP 800-SP to check pseudorandom number generators in smart cards has showed that it is a workable concept. The tests listed in the NIST SP 800-22 are substantially more then the one recommended for the smart card pseudorandom number generators in AIS20 [18] and AIS31 [13]. This research has demonstrated that even with limited resources and an entropy constrained environment like a smart card, good quality pseudorandom sequences can be generated that can satisfy all the requirements for a PRNG even the ones that are used for general purpose computers. ... --- end _______________________________________________ dsfjdssdfsd mailing list dsfjdssdfsd@ietf.org https://www.ietf.org/mailman/listinfo/dsfjdssdfsd ------=_NextPart_000_0180_01CF1859.E5493590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEy NDAwNDA1OVowIwYJKoZIhvcNAQkEMRYEFCwodB0DgH+SybBqBTFE7iOPRuE9MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAgoL/ty2Tj1mSR2BEwYcPFUG6Iaa1yXrYmjK7yTWI mfHf3aIq1XhibjwKm7vB4E6o2Cy1GGJf+otzWQLRd+TUsIbVKdSBIXxBVEBx+BAQwlPj2RncUdrV TT8n5ci9ugb73uCAVTz2dwcK8TLVG6574ft+0YQjI4URCRE7zDajsGis5hwswPeH57A+mZR11dMJ gUvOsDKHvpFKXhcGHbCpLtuYpP9rwgAMVNNaY9apG8rhgma4my4Y5MkYFgY0ZEN1cKmvKwYkuVaN EToo/EzcsO5kg62CY4ry1rav7g8tztO4zTzRz4q6L9U1QJpO3JYyEyYHR8WkQ1N0uYnWjmTQKAAA AAAAAA== ------=_NextPart_000_0180_01CF1859.E5493590-- From wim.henderickx@alcatel-lucent.com Thu Jan 23 20:52:57 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 E873E1A0132 for ; Thu, 23 Jan 2014 20:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] 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 TwaaFEJ4Ads8 for ; Thu, 23 Jan 2014 20:52:54 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id C5B991A00FB for ; Thu, 23 Jan 2014 20:52:54 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0O4qofl021262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2014 22:52:52 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0O4qnf4007188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 05:52:49 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.122]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 24 Jan 2014 05:52:49 +0100 From: "Henderickx, Wim (Wim)" To: =?iso-8859-1?Q?Kriszti=E1n_Pint=E9r?= , Michael Hammer Thread-Topic: [dsfjdssdfsd] Any plans for drafts or discussions on here? Thread-Index: AQHPGHtZhPrq+TLITk+z92rlLgyyZZqSt4EAgAAeVoCAAHlrgA== Date: Fri, 24 Jan 2014 04:52:48 +0000 Message-ID: References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> In-Reply-To: <204592464.20140123233807@gmail.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1350802837CFFC40AEF179F88CF59A9F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dsfjdssdfsd@ietf.org" , "ietf@hosed.org" 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: Fri, 24 Jan 2014 04:52:57 -0000 ok On 23/01/14 23:38, "Kriszti=E1n Pint=E9r" wrote: > >Michael Hammer (at Thursday, January 23, 2014, 9:49:32 PM): >> This may get off-topic, but are there good software tools for testing >> entropy,=20 >> that could help applications determine if the underlying system is >>giving >> them good input? > >disclaimer: i'm no expert, it is just what i gathered. (i'm pretty >much interested in randomness.) > >short answer: no > >long answer: in some situations yes. if you are handed a bunch of >data, all you can do is to try different techniques to put an upper >limit on the entropy. for example you can calculate the shannon >entropy assuming independent bits. then you can hypothesize some >interdependence, and see if you can compress the data. you can apply >different lossless compression methods. the better compression you >find puts an upper limit on the entropy. but never a lower limit. > >you can only do better if you have an idea about the process that >created the data. for example you might assume that it is mostly >thermal noise. you can assume that thermal noise has some frequency >distribution, or energy or whatever, etc. within this assumption, you >can determine the entropy content by measurements. but at this point, >you are pretty much prone to two errors: 1, what if your assumption is >wrong and 2, what if your physical model overestimates the >unpredictability of the given system. example for the former: the >signal might be largely controllable by an external EM interference, >and then you measure not noise, but attacker controlled data. example >for the latter: a smartass scientist might come up with a better >physical model for thermal noise. > >it is also important to note that entropy is observer dependent. we >actually talk about the entropy as seen by the attacker. but it is not >straightforward to assess what is actually visible to an attacker and >what is not. observation methods improve with time. > >_______________________________________________ >dsfjdssdfsd mailing list >dsfjdssdfsd@ietf.org >https://www.ietf.org/mailman/listinfo/dsfjdssdfsd From pinterkr@gmail.com Fri Jan 24 09:02:19 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 A9FF31A004B for ; Fri, 24 Jan 2014 09:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 VP3zb1ewq8bM for ; Fri, 24 Jan 2014 09:02:14 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AD7B91A0048 for ; Fri, 24 Jan 2014 09:02:13 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id c13so1076916eek.31 for ; Fri, 24 Jan 2014 09:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=kDZsWTtQvFQytBKQfNmi0cxXNxGovA1GnIB7t5mqQV4=; b=JRL5M6m8EZUE7YHXw3yKwlehNbeBC9nR3HSSRmpEQ7OHmcnSDW/YumKvnjKFsKWP5g 0wpCnXULg+3V3adn6Yul05Pe0YvnG0TH7a/teS4r/hv5YeqUcVluz4lSGHlCTenGWXTn TBb2ZyoUMeWT27AhQVFdQts3sk6eZRhRXlya9Zt/zCF9H22+ByC0Y+9Qc7cUb9UmZe6W Dv7yer89SYHnCyuU90vYNqGYYk3B5Pq5Qwaiy8xidu9mSaqDp9jhPetRAjXpgEhUKdlE +Xdb6fj4B2BKEF6qwsHj0iXUi/GMRix6kQdVmLOC8BoToqyeQPuAUOoI/uTQQDhzslI7 5MkA== X-Received: by 10.14.100.204 with SMTP id z52mr9555611eef.68.1390582932074; Fri, 24 Jan 2014 09:02:12 -0800 (PST) Received: from [192.168.2.244] (catv-176-63-52-22.catv.broadband.hu. [176.63.52.22]) by mx.google.com with ESMTPSA id u7sm5651319eep.11.2014.01.24.09.02.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 24 Jan 2014 09:02:11 -0800 (PST) Date: Fri, 24 Jan 2014 18:02:25 +0100 From: =?iso-8859-1?Q?Kriszti=E1n_Pint=E9r?= X-Priority: 3 (Normal) Message-ID: <1825449796.20140124180225@gmail.com> To: Michael Hammer In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "dsfjdssdfsd@ietf.org" , "ietf@hosed.org" 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: Fri, 24 Jan 2014 17:02:19 -0000 Michael Hammer (at Friday, January 24, 2014, 12:19:03 AM): > Hmmm... that makes it sound rather subjective. > If we don't have objective measures, > then who is to say that one's randomness is better or worse than another? as i said, we need to examine the physical processes. the best source of entropy as of now is thermal noise. we understand thermal noise to a great degree, we don't expect sudden breakthrough in modeling it, and it is relatively abundant and easy to access. user input also contains noise, as the user can control keystroke or mouse movement timing up to some 10's or 100's of milliseconds, below that, it is just noise from the equipment and the "biological equipment". > Was thinking in terms of how an app with access to alternate random sources, > some which might be from OS or from some software, might choose one over > another. if you are adamant on doing homebrewed, why choose? you can combine them. if your combinator is good, you can't lose. From Jeff.Hodges@KingsMountain.com Fri Jan 24 10:33:52 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 5BBAE1A002F for ; Fri, 24 Jan 2014 10:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W4Fk-Q4vjOzi for ; Fri, 24 Jan 2014 10:33:51 -0800 (PST) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 5D1081A0028 for ; Fri, 24 Jan 2014 10:33:51 -0800 (PST) Received: (qmail 24338 invoked by uid 0); 25 Jan 2014 01:32:48 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.mail.unifiedlayer.com with SMTP; 25 Jan 2014 01:32:48 -0000 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=CAYPMXjyY+iUGET/X/L0J+b+6ULrc/fBRZvjpDXfTuY=; b=UBmGfHW/agrWLCjO0kYYb2dpnuJGDzsyNkE42IhwOm9yvrks4Wfnd1bg6jRLKq6l2qTttiahILnnKRFhBnjLYGJU3jZhil+KgtT5hltDG/wUZZOlJk5c8pj6RRADapVf; Received: from [216.113.168.128] (port=59535 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1W6lYf-0003cB-Oz for dsfjdssdfsd@ietf.org; Fri, 24 Jan 2014 11:32:49 -0700 Message-ID: <52E2B1CF.50906@KingsMountain.com> Date: Fri, 24 Jan 2014 10:32:47 -0800 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: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dsfjdssdfsd] software tools for testing entropy (was: 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: Fri, 24 Jan 2014 18:33:52 -0000 > are there good software tools for testing entropy, that could help > applications determine if the underlying system is giving them good > input? see also... http://packages.debian.org/wheezy/rng-tools Package: rng-tools (2-unofficial-mt.14-1) Daemon to use a Hardware TRNG The rngd daemon acts as a bridge between a Hardware TRNG (true random number generator) such as the ones in some Intel/AMD/VIA chipsets, and the kernel's PRNG (pseudo-random number generator). It tests the data received from the TRNG using the FIPS 140-2 (2002-10-10) tests to verify that it is indeed random, and feeds the random data to the kernel entropy pool. This increases the bandwidth of the /dev/random device, from a source that does not depend on outside activity. It may also improve the quality (entropy) of the randomness of /dev/random. A TRNG kernel module such as hw_random, or some other source of true entropy that is accessible as a device or fifo, is required to use this package. This is an unofficial version of rng-tools which has been extensively modified to add multithreading and a lot of new functionality. --- end From dharkins@lounge.org Fri Jan 24 11:16:30 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 CC2151A01A2 for ; Fri, 24 Jan 2014 11:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 7R2CdsA3NNIz for ; Fri, 24 Jan 2014 11:16:29 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 92C751A01A7 for ; Fri, 24 Jan 2014 11:16:10 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3CBBAA888012; Fri, 24 Jan 2014 11:16:09 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 24 Jan 2014 11:16:09 -0800 (PST) Message-ID: In-Reply-To: <1825449796.20140124180225@gmail.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> <1825449796.20140124180225@gmail.com> Date: Fri, 24 Jan 2014 11:16:09 -0800 (PST) From: "Dan Harkins" To: =?iso-8859-1?Q?Kriszti=E1n_Pint=E9r?= User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "dsfjdssdfsd@ietf.org" , "ietf@hosed.org" , Michael Hammer 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: Fri, 24 Jan 2014 19:16:31 -0000 On Fri, January 24, 2014 9:02 am, Krisztián Pintér wrote: > > Michael Hammer (at Friday, January 24, 2014, 12:19:03 AM): >> >> Was thinking in terms of how an app with access to alternate random >> sources, >> some which might be from OS or from some software, might choose one over >> another. > > if you are adamant on doing homebrewed, why choose? you can combine > them. if your combinator is good, you can't lose. ^^^^^^^^^^^^^^^^^^^^ Is that all there is to it? This sounds like only the generation function of a random bit generator. Shouldn't there also be some process that handles the internal state necessary to do the generation? Shouldn't that process have certain security properties, for instance allowing the continued generation of a random bit stream* when an attacker is able to limit (some of) the input(s) to the "combinator"? This is really more like "home distilling" than "home brewing" in that if you don't do it right it will kill you instead of just taste bad. So, on the contrary, I think you definitely can lose. Dan. * random in the sense that to the attacker an n-bit sample appears uniformly distributed over the entire set of n-bit vectors. From michael.hammer@yaanatech.com Sat Jan 25 08:16:37 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 ABF0A1A03C4 for ; Sat, 25 Jan 2014 08:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 9a7du2bp0dCa for ; Sat, 25 Jan 2014 08:16:35 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB21A039E for ; Sat, 25 Jan 2014 08:16:35 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Sat, 25 Jan 2014 08:16:33 -0800 From: Michael Hammer To: "pinterkr@gmail.com" Thread-Topic: [dsfjdssdfsd] Any plans for drafts or discussions on here? Thread-Index: AQHPFik7i/q5nfCSa0yR/K7nGCDgcJqOvseAgAArLACAAqUWgIAAqIaAgAEY5AD//3wacIAApM6A//+D2yCAAbCvgIAA/mZA Date: Sat, 25 Jan 2014 16:16:32 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF1BE0E@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> <1825449796.20140124180225@gmail.com> In-Reply-To: <1825449796.20140124180225@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.244] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0081_01CF19A5.C1435F70" MIME-Version: 1.0 Cc: "dsfjdssdfsd@ietf.org" , "ietf@hosed.org" 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: Sat, 25 Jan 2014 16:16:37 -0000 ------=_NextPart_000_0081_01CF19A5.C1435F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, if you mix a non-random input with a random input,=20 using a deterministic algorithm, the output will be more random? That doesn't seem right to me. We can't control the randomness of the input data,=20 but the other inputs to an encryption or hashing algorithm are my = concern. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: Kriszti=E1n Pint=E9r [mailto:pinterkr@gmail.com]=20 Sent: Friday, January 24, 2014 9:02 AM To: Michael Hammer Cc: ietf@hosed.org; dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? Michael Hammer (at Friday, January 24, 2014, 12:19:03 AM): > Hmmm... that makes it sound rather subjective. > If we don't have objective measures, > then who is to say that one's randomness is better or worse than = another? as i said, we need to examine the physical processes. the best source of entropy as of now is thermal noise. we understand thermal noise to a = great degree, we don't expect sudden breakthrough in modeling it, and it is relatively abundant and easy to access. user input also contains noise, = as the user can control keystroke or mouse movement timing up to some 10's = or 100's of milliseconds, below that, it is just noise from the equipment = and the "biological equipment". > Was thinking in terms of how an app with access to alternate random=20 > sources, some which might be from OS or from some software, might=20 > choose one over another. if you are adamant on doing homebrewed, why choose? you can combine = them. if your combinator is good, you can't lose. ------=_NextPart_000_0081_01CF19A5.C1435F70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEy NTE2MTYzMVowIwYJKoZIhvcNAQkEMRYEFHn8x+axrl6J3muNyyTBTvg7QwDDMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAStnoQPl3TsvD3FJF8/YDxwzlZfqkf8UE5axqucAF Zip0GiiUn3qXjGcCQToKw13k78iSr8Qtvif2buVgJ8zlx2fNEdxi0FE91BljnA0yq1jEYSrsqRGy t0zkrnzUZW7poREylY8wjm2xzBG8dsqhMmqScnD7aSU8KFG788akQ0toDakfPFWD3SoulyQnB0MS l0/NY1v0teuWZSVEehH3IwDTQ/kSLBTShlLTKIcRZOKb0pFrazRkxqHSqGwRqCTsrtEucfcWqV5x wV+mCJbTwwvid+PVffk2pTCFNHZYjp11AmuxwryYQMysJCH3XApJQqxZXFKxQk6cMImTQ2n9uAAA AAAAAA== ------=_NextPart_000_0081_01CF19A5.C1435F70-- From paul.hoffman@vpnc.org Sat Jan 25 11:35: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 AD43D1A005A for ; Sat, 25 Jan 2014 11:35:23 -0800 (PST) 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 A2-KoPw5TjK0 for ; Sat, 25 Jan 2014 11:35:22 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9177D1A002F for ; Sat, 25 Jan 2014 11:35:22 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0PJF7gI077238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Jan 2014 12:15:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: multipart/signed; boundary="Apple-Mail=_C05AD8B3-7DC3-43ED-886C-776097A09509"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF1BE0E@sc9-ex2k10mb1.corp.yaanatech.com> Date: Sat, 25 Jan 2014 11:35:11 -0800 Message-Id: <2C723E08-FB16-4D03-9371-94D164111E5B@vpnc.org> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> <1825449796.20140124180225@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF1BE0E@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) Cc: "dsfjdssdfsd@ietf.org" 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: Sat, 25 Jan 2014 19:35:23 -0000 --Apple-Mail=_C05AD8B3-7DC3-43ED-886C-776097A09509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 25, 2014, at 8:16 AM, Michael Hammer = wrote: > So, if you mix a non-random input with a random input,=20 > using a deterministic algorithm, the output will be more random? > That doesn't seem right to me. That's because it is not right for many reasons. To start, you haven't = defined "non-random" and "more random". A better description: Value A has X bits that cannot be known to adversary M. Value B has Y = bits that cannot be known to M. Securely mixing A and B into a value C whose length is greater than or = equal to (X + Y) will result in C having (X + Y) bits that cannot be = known by M. If C's length is less than (A + B), every bit in C cannot be = known by M. In your question above, the fact that B might be 0 is irrelevant to the = calculation.=20 --Paul Hoffman --Apple-Mail=_C05AD8B3-7DC3-43ED-886C-776097A09509 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJS5BH1AAoJEJz/fXByZmLZ/vEIALOrrxjC+KaIhNfM/tY4ynTY E3xDbKLrzGbM6SzNtgdem2AuKfZPhBKcR0wADL1GKHlYFbQRRSNJWpAT41QQ0Arb ujf8IQQ8F+8NOcXB6uoFSb2GxgPzIIUnS2t2A/l2Eg/boXRqLoC6bsqtPpXLxjtU WkF0s4Wj8YREmSvzfjX12dv1k0hHDatLZbNcnVY4UkoK7+Xe5BsaLCubnZowW3Rb r6rs+KgULxXdCybfLoPj98J4JldJ+q76RC4iMc0cYYuRw5ykQgI5fRQ1SyKndFzJ crxo5ZLh4NEeDg8ygaZVuWXQMbHB8mQNW0NAVBdSFqxfe13jnJM+fd0PmL25nXo= =DHnK -----END PGP SIGNATURE----- --Apple-Mail=_C05AD8B3-7DC3-43ED-886C-776097A09509-- From michael.hammer@yaanatech.com Sat Jan 25 13:17: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 153E41A0045 for ; Sat, 25 Jan 2014 13:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 gl4fCRQl-LX6 for ; Sat, 25 Jan 2014 13:17:03 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id E7D491A003A for ; Sat, 25 Jan 2014 13:17:03 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Sat, 25 Jan 2014 13:17:02 -0800 From: Michael Hammer To: "paul.hoffman@vpnc.org" Thread-Topic: [dsfjdssdfsd] Any plans for drafts or discussions on here? Thread-Index: AQHPFik7i/q5nfCSa0yR/K7nGCDgcJqOvseAgAArLACAAqUWgIAAqIaAgAEY5AD//3wacIAApM6A//+D2yCAAbCvgIAA/mZAgAC+noD//5NagA== Date: Sat, 25 Jan 2014 21:17:00 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF1C045@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> <1825449796.20140124180225@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF1BE0E@sc9-ex2k10mb1.corp.yaanatech.com> <2C723E08-FB16-4D03-9371-94D164111E5B@vpnc.org> In-Reply-To: <2C723E08-FB16-4D03-9371-94D164111E5B@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.244] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_016A_01CF19CF.BA1D22B0" MIME-Version: 1.0 Cc: "dsfjdssdfsd@ietf.org" 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: Sat, 25 Jan 2014 21:17:06 -0000 ------=_NextPart_000_016A_01CF19CF.BA1D22B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am not sure if we are talking past each other. Using terms from your example, I have one input (trying to map to what you say) that is message A. I have another input, call it key B. The output of the "secure algorithm" is C. C will be known by adversary M. The question is whether B is sufficiently random that C cannot guess it. Also, that M cannot easily discover A knowing C. The strength of the algorithm is part of the assurance. The strength of the key is the other part. Weak key B does not adequately protect message A. Now, being random does not guarantee that the key B is not weak, just not easily deduced by M. But, if B is generated from inputs B1 and B2 in such a way that it tends to reduce the randomness (worse case results in very small subset of keys B), then M can brute force B to reveal A. One of the papers cited earlier pointed out how a complex algorithm actually ended up converging on a small number of values. I would hope to avoid repeating that mistake. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Saturday, January 25, 2014 11:35 AM To: Michael Hammer Cc: dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here? On Jan 25, 2014, at 8:16 AM, Michael Hammer wrote: > So, if you mix a non-random input with a random input, using a > deterministic algorithm, the output will be more random? > That doesn't seem right to me. That's because it is not right for many reasons. To start, you haven't defined "non-random" and "more random". A better description: Value A has X bits that cannot be known to adversary M. Value B has Y bits that cannot be known to M. Securely mixing A and B into a value C whose length is greater than or equal to (X + Y) will result in C having (X + Y) bits that cannot be known by M. If C's length is less than (A + B), every bit in C cannot be known by M. In your question above, the fact that B might be 0 is irrelevant to the calculation. --Paul Hoffman ------=_NextPart_000_016A_01CF19CF.BA1D22B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEy NTIxMTY1OFowIwYJKoZIhvcNAQkEMRYEFNJYyiyQaJvZY8DOVtsa+oKZX2YUMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOLvVUYe7ZA6dAqIQtqaNQ000J+7AtHqBYUILmyM+ JYv6aGIwVSEGMIQJJM3gOatxrMsMvY9YH69xckKSGsTrj7SKFNpO9hl+PxS4Rp8qniT9YQaj+iVR rrM8gueZqfFXzMf1ZXxUnYwg8sy7BH/ACqI2LKEutuc4Xf/zB5yH21ee/RWluK2UQ16ZOns2ABp+ 4fx1QY5CQXiZfZ3e8ddV54nqFcuGRGsXfAvLW3r2UzEb8fvm9/J/mz9ERiIH2+vJ74LrDpKZrr9z uzk8qcesyjYHeQ7G5laKzvHTJKlq+vgL5/mV2Mg9dvcMJ87Te6o7GVcgPVhrj9/6zZJ7J98ungAA AAAAAA== ------=_NextPart_000_016A_01CF19CF.BA1D22B0-- From pinterkr@gmail.com Sat Jan 25 15:24:52 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 4AD8F1A00AA for ; Sat, 25 Jan 2014 15:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 FdiVkLJd4fuA for ; Sat, 25 Jan 2014 15:24:51 -0800 (PST) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DD4131A00A9 for ; Sat, 25 Jan 2014 15:24:50 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n15so1624959ead.22 for ; Sat, 25 Jan 2014 15:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=GsyD8Syu1o+VHNqruF6/QmM2B1Pl6suys9m/Dp/YrCg=; b=sEqSrkN4q1W2O4Ohe77xI1IbzFw2arrxnDZNmPQ/D2m5UmvwZmooW68sv6vS6xYQpH VIO1mJVEyVFi3MP5o41wo0UxPsLaBU7fe0xbt3wKV0/RHHqzn0JY0xuojdQNtRLe0zBU NtdxPqzsCv7eYpcV6CZ9rMErcCBXvccXU5Nu55ulsysmPr8b3W1IOpiBSYltAFw3md4q FvcRZDmaNiSy015glU1bJh8V0oxbSqof9GSQ0PCjsmBQ1WZ8lhBe+/t35IwvWJPTNFil J9aHaxYdIK3Zi8uJPCRRgi7WTB/yZioW3okoOxLDUgK68OUm73YHB9JsHmHzUMFD2JDX S7jA== X-Received: by 10.14.39.3 with SMTP id c3mr18912059eeb.4.1390692288849; Sat, 25 Jan 2014 15:24:48 -0800 (PST) Received: from [192.168.2.244] (catv-176-63-52-22.catv.broadband.hu. [176.63.52.22]) by mx.google.com with ESMTPSA id o43sm21547474eef.12.2014.01.25.15.24.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 25 Jan 2014 15:24:48 -0800 (PST) Date: Sun, 26 Jan 2014 00:25:06 +0100 From: =?iso-8859-15?Q?Kriszti=E1n_Pint=E9r?= X-Priority: 3 (Normal) Message-ID: <328236349.20140126002506@gmail.com> To: Michael Hammer In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF1C045@sc9-ex2k10mb1.corp.yaanatech.com> References: <52DD996F.3040708@cs.tcd.ie> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org> <15541579.20140123214020@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18E51@sc9-ex2k10mb1.corp.yaanatech.com> <204592464.20140123233807@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF18FD6@sc9-ex2k10mb1.corp.yaanatech.com> <1825449796.20140124180225@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF1BE0E@sc9-ex2k10mb1.corp.yaanatech.com> <2C723E08-FB16-4D03-9371-94D164111E5B@vpnc.org> <00C069FD01E0324C9FFCADF539701DB3BBF1C045@sc9-ex2k10mb1.corp.yaanatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "dsfjdssdfsd@ietf.org" , "paul.hoffman@vpnc.org" 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: Sat, 25 Jan 2014 23:24:52 -0000 Michael Hammer (at Saturday, January 25, 2014, 10:17:00 PM): > One of the papers cited earlier pointed out how a complex algorithm > actually ended up converging on a small number of values. > I would hope to avoid repeating that mistake. yep, you need to take good care. but we do have good mixing functions.