On Mon, Mar 17, 2014 at 10:35 AM, Dan Brown <<= a href=3D"mailto:dbrown@certicom.com" target=3D"_blank">dbrown@certicom.com= > wrote:

> EE. B= ad entropy estimation
> = ;

> Numerous RNGs rely on each entropy inputs being acccompan= ied by an
> estimate of how many bi= ts of entropy each contains. Historically,

> these entropy estimates have been pretty bogus, but I'= ;m not aware of
> any attack arisi= ng out of that.

=
Does the Goldberg—Wagner = attack on the poorly seeded Netscape SSL RNG count here?

Not exactly. I meant item "EE" to cover only= cases where the RNG has an internal variable that tracks how much entropy = it has received, but this internal variable is calculated through a dubious= process.

If I'm reading [1] correctly, the Netscape SSL RNG = problem was that it only seeded with the PID, the parent PID, and the curre= nt time in microseconds. It didn't track entropy levels at all: it just= failed to use adequate entropy.

So let's add a new category to the list:

"
J. Not even trying to use enough entr= opy as an input.
"

[1] http://www.cs= .berkeley.edu/~daw/papers/ddj-netscape.html

--
Nick

--089e012281329c2c6f04f4cfbd6f-- From nobody Mon Mar 17 09:35:54 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 897F11A040E for ; Mon, 17 Mar 2014 09:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 2eyfZL-l8ere for ; Mon, 17 Mar 2014 09:35:51 -0700 (PDT) Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtp002.mac.com [17.172.204.237]) by ietfa.amsl.com (Postfix) with ESMTP id B38D61A0401 for ; Mon, 17 Mar 2014 09:35:51 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_kddiOC0fzYvJwvOXwgm4Zw)" Received: from [10.0.23.30] (media.merrymeet.com [173.164.244.98]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2L001EMA3HHPB0@st11p01mm-asmtp002.mac.com> for dsfjdssdfsd@ietf.org; Mon, 17 Mar 2014 16:35:43 +0000 (GMT) From: Jon Callas In-reply-to: <810C31990B57ED40B2062BA10D43FBF5C59197@XMB116CNC.rim.net> Date: Mon, 17 Mar 2014 09:35:40 -0700 Message-id: References: <810C31990B57ED40B2062BA10D43FBF5C59197@XMB116CNC.rim.net> To: Dan Brown X-Mailer: Apple Mail (2.1874) x-icloud-spam-score: 34444444 f=icloud.com; e=icloud.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaEhEKTEMXGx0EGx0YBBIZBBsTEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxseGmJCH2lmG2RYGXhzB xhiGxwZH0IRClhcFxkEGgQdB01LHRJISRxMBRsdBBsdGAQSGQQbExAbHhofGxEKXlkXYXJnQBw RCkxGF2xraxEKQ1oXGx0ZBBscHgQYHh4EExIRCkRYFxkRCkRJFxkRCkJGF2x9TER+fWUTaV4TE QpCRRduRX9kXngBE0AScBEKQk4Xa0UaUlAeQ1xZXGgRCkJMF2NEZh18TBNQZh5mEQpCbBdtSBN abU9PZ2dkHxEKQkAXZH5uWG8TbG1aTQURCnBoF2MbYU0cYWRHG3B6EQpwaBdsBRp+GXJ9HGhfH BEKcGgXZ38TcBh4XlpaUhIRCnBoF3ocEnMfQE9tQxJkEQpwaBdjcxwSWnBBEkldaxEKcGwXelh tBUMfH1tzUEcRCnBMF2YdfFxJSR95ZHxJEQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/l_sobBjUBaFCscXpzvSK_EgUBYs Cc: "dsfjdssdfsd@ietf.org" , Jon Callas Subject: Re: [dsfjdssdfsd] Blum-Blum-Shub ambiguity in 4086 ... 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, 17 Mar 2014 16:35:53 -0000 --Boundary_(ID_kddiOC0fzYvJwvOXwgm4Zw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Mar 17, 2014, at 7:42 AM, Dan Brown wrote: > Two issues: > > 1. If it is unclear to me from the 4086 description of BBS whether the state s_i is to be updated after each output. I believe that the state should be updated to improve backtracking resistance. (Otherwise, it would be affected by a similar weak backtracking attack to the one DSS RNG, i.e. current state compromise the latest output can be distinguished from random.) > 2. Does the secret state include p and q? If so, then the BBS suffers from a more severe backtracking attack: recovering the current state allows recovery of all the previous states, because p and q allows one to compute square roots. This would undermine forward security applications. > Yes, it does suffer from that same problem. While BBS has number-theoretic proofs of security, those proofs presume a random, unknown p and q. I've said that this is pushing the randomness problem down to the turtle below you. I wrote a missive on the Cryptography list around the turn of the year in which I said that the EC DRBGs have this problem -- you get randomness providing you have a secret key, but how did you get *that*? -- going back to BBS. If you want, I'll dredge it up and post here. Jon --Boundary_(ID_kddiOC0fzYvJwvOXwgm4Zw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

On Mar 17, 2014, at 7:42 AM, Dan Brown = <dbrown@certicom.com> = wrote:

Two issues:

1. = If it is unclear = to me from the 4086 description of BBS whether the state s_i is to be = updated after each output. I believe that the state should be updated to = improve backtracking resistance. (Otherwise, it would be affected = by a similar weak backtracking attack to the one DSS RNG, i.e. current = state compromise the latest output can be distinguished from = random.)
2. = Does the secret = state include p and q? If so, then the BBS suffers from a more = severe backtracking attack: recovering the current state allows recovery = of all the previous states, because p and q allows one to compute square = roots. This would undermine forward security = applications.

<= /div>Yes, it does suffer from that same problem. While BBS has = number-theoretic proofs of security, those proofs presume a random, = unknown p and q. I've said that this is pushing the randomness problem = down to the turtle below you.

I wrote a missive = on the Cryptography list around the turn of the year in which I said = that the EC DRBGs have this problem -- you get randomness providing you = have a secret key, but how did you get *that*? -- going back to BBS. If = you want, I'll dredge it up and post = here.

= Jon

= --Boundary_(ID_kddiOC0fzYvJwvOXwgm4Zw)-- From nobody Mon Mar 17 09:53: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 BA9E81A0436 for ; Mon, 17 Mar 2014 09:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 bN_BVa3YfAn7 for ; Mon, 17 Mar 2014 09:53:46 -0700 (PDT) Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtpout002.mac.com [17.172.204.237]) by ietfa.amsl.com (Postfix) with ESMTP id 064F71A006F for ; Mon, 17 Mar 2014 09:53:44 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_resG8UD9if42WWC1TmNTow)" Received: from [10.0.23.30] (media.merrymeet.com [173.164.244.98]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2L002LAAWXX3A0@st11p01mm-asmtp002.mac.com> for dsfjdssdfsd@ietf.org; Mon, 17 Mar 2014 16:53:23 +0000 (GMT) From: Jon Callas In-reply-to: Date: Mon, 17 Mar 2014 09:53:20 -0700 Message-id: References: <810C31990B57ED40B2062BA10D43FBF5C59197@XMB116CNC.rim.net> To: "dsfjdssdfsd@ietf.org" X-Mailer: Apple Mail (2.1874) x-icloud-spam-score: 34444444 f=icloud.com; e=icloud.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHxEKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCHx1SH3JpGXhzB xhiGxwfGWQYEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGx0QGx4aHxsRCl5ZF2FyZxp PEQpMRhdsa2sRCkNaFxsdGQQbHB4EGB4eBBMSEQpEWBcYEQpEXhcYEQpESRcbEQpCRhdsfUxEf n1lE2leExEKQkUXbkV/ZF54ARNAEnARCkJOF2tFGlJQHkNcWVxoEQpCTBdjRGYdfEwTUGYeZhE KQmwXbUgTWm1PT2dnZB8RCkJAF2BrRXNCYml8bRh/EQpwaBdlYWtiYV1NTWcFTxEKcGgXZ2ZHc 0FdQH5PekgRCnBoF2tObXNeQHsbcEluEQpwaBdmTFofRUUBckdlYxEKcGgXY09YSwFlaBhcYx0 RCnB/F2dGAXpcG21sYlNlEQpwXxdgRRlsYV54WH9HcxEKcH8XYlh5elBEWW5NW20RCnBfF25ue 1NcUnJaZG5AEQpwfxd6QU0Ya2h8XUhIcBEKcF8XYkIbBU4SUFkBTWsRCnB/F2l4T3B6SBMaThp 5EQpwXxd6Z0FbTnJYe2lzSBEKcH8XZhISeRwTEm9jHB0RCnBfF2d7HFhlaUdFAU0eEQpwbBd6W G0FQx8fW3NQRxE= X-CLX-Spam: false X-CLX-Score: 1011 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/gWYywOs9NCYcuu_raRjwgHxyZqE Cc: Jon Callas Subject: Re: [dsfjdssdfsd] Blum-Blum-Shub ambiguity in 4086 ... 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, 17 Mar 2014 16:53:49 -0000 --Boundary_(ID_resG8UD9if42WWC1TmNTow) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I found my missive in question, and upon re-reading it, I think it bears repeating here. The thread starts with and the message I quote from below is . The discussion started with the blog post which purports to show how DUAL_EC_DRBG *must* have been backdoored from the start. That blog post is the antecedent of "it" in the paragraph first paragraph. ---- It's nice work on a technical level, but I think it fails at its goal, that is to be a piece of polemic -- even mischaracterizing the Ferguson/Shumow CRYPTO Rump Session talk (their last slide explicitly said they were not suggesting a back door). Lest you think I'm saying something nice about DUAL_EC_DRBG, I'll repeat what I've said before, "Only an idiot would use it." It's slow, has biases in its output that hashes and ciphers don't, and cannot be proved secure. Let me rewind to the first public key based DRBG/PRNG -- Blum-Blum-Shub. (DRBG is the name NIST gave to what you and I would call a PRNG, it's Deterministic Random Bit Generator. If you think of a complete design of an RNG, you want at least three major sections -- "entropy" collection, entropy pool management, and conditioned output. A DRBG is the output stage.) Blub-Blum-Shub uses an iterated RSA-like operation to generate random bits. It was developed in 1986 and is a brilliant piece of mathematics. It was one of the very, very few bits of early crypto to have a sound theoretical basis. Many people who haven't thought it through have sung its praises over the years, mostly because they got seduced by the sound theoretic basis. Blum-Blum-Shub has two of the three flaws that DUAL_EC_DRBG has: it's slow, and you can't prove it secure. I'm sure you thinking, 'What do you mean, "can't be proved secure? Didn't you just say that it had a sound theoretical basis?"' Yup, and the sound theoretical basis gives you the good mathematical pseudo-randomness of the output. The slow part is pretty obvious. The inobvious part is that it can't be proven secure. As an iterated, RSA-like operation, the core of it is two prime numbers, p and q. The security resolves down to the secrecy of the two primes. And this leaves you with the question of how you get the primes. Well, if you generate them at run time, then you push the construction of your RNG down to the turtle below you. Your random number generator requires random p and q and you get those by using some other random number generator, one presumes. Alternatively, you could use a fixed p and q, and then you have the *exact* flaw as DUAL_EC_DRBG -- you have a fixed private key that can be used to jimmy the thing open. Matt Green wrote a great blog post last week at , which you should read. I'll summarize a bit and say that Micali and Shnorr did their own public-key based PRNG which also has Step 1 being "generate large primes p and q" and they helpfully gave test P and Q. I'm not merely being ironic. As someone who implemented the AES-CTR DRBG, having test vectors is really, really nice. NIST's test vectors for that are really, really annoying and I'll complain at length to anyone who cares. Anyway, Matt Green identifies the Micali-Shnorr generator as a precursor to DUAL_EC_DRBG in both design and having a fixed key that you use for whatever purporses, testing or compromise. I have a couple points: (Point 1) Any public-key based PRNG is going to have the issue that either you have a fixed key, or you have to generate a key using some other secure means. This is why I use terms as strong as "can't be proven to be secure" despite having a mathematical "sound theoretical basis." I think there's a huge security philosophy problem here -- security proofs that are mathematical can have underlying engineering assumptions that render them insecure to the point of being silly. I think that people get blinded by this as well, and if there's a mathematical proof they're blinded by it, if not cowed by the math and stop prodding at the engineering and operational security. Going back to Blum-Blum-Shub, look at the Wikipedia article on it at . There are some interesting statements there, like the first sentence of the security section: The generator is not appropriate for use in simulations, only for cryptography, because it is very slow. That makes me splutter. As an engineer, I'd argue that slow alone makes it not suitable for cryptography. I'm tempted to argue that for simulations, speed isn't an issue, but really, if you slow things down enough, it's not suitable for anything. I also have a long-standing twitch at *any* security discussion that brings in performance. Performance is not security, and many security sins have their root cause in a performance worry, usually an artificial one. The remainder of the section reads: However, there is a proof reducing its security to the computational difficulty of the Quadratic residuosity problem. Since the only known way to solve that problem requires factoring the modulus, the difficulty of Integer factorization is generally regarded as providing security. When the primes are chosen appropriately, and O(log log M) lower-order bits of each xn are output, then in the limit as M grows large, distinguishing the output bits from random should be at least as difficult as factoring M. If integer factorization is difficult (as is suspected) then B.B.S. with large M should have an output free from any nonrandom patterns that can be discovered with any reasonable amount of calculation. Thus it appears to be as secure as other encryption technologies tied to the factorization problem, such as RSA encryption. This is interesting because nowhere do they address the central engineering issue -- that a fixed p,q is not secure yet a variable one requires another RNG to seed the RNG. Also look at the section in the Handbook of Applied Cryptography on "Cryptographically secure pseudorandom bit generation": We find an RSA-based generator there along with Micali-Shnorr and Blum-Blum-Shub and *all* of these have a recipe that starts unironically with (essentially): 1. Setup. Generate two RSA-like secret primes, p and q. This is a blind spot that's been there forever -- two of the three flaws of DUAL_EC_DRBG have been staring us all in the face since 1986. Despite mathematical brilliance, the security of public-key based PRNGs have always been flawed with something that could be used as a back door. (Point 2) History looks different when you look backwards than when you look forwards. Everyone has a tendency to act as if things were predetermined when we analyze the decisions of the past. We also assign intent when we have to explain a WTF. Yet the usual answer to "What were you thinking?" is "They weren't." To quote the great philosopher David Byrne, "And you might say to yourself, 'My God, what have I done?'" The general flaws have been there forever, and in general we still don't see them. In specific, the documents on Micali-Shnorr and DUAL_EC_DRBG were up front about the flaw all along. Would the NSA exploit such a flaw? Hell, yes. We keep seeing this from leaked documents, over and over. It's clear that they have taken the hacker philosophy that nothing is out of scope or out of bounds to heart as an operating principle. You can see it in the recent ANT toy catalog, as well as the BULLRUN statement that sent us all into a tizzy. We have *assumed* that the BULLRUN statement that they're after damaging standards means that DUAL_EC_DRBG is backdoored. People have said it so loudly and so often that it's part of conventional wisdom now. Yet until BULLRUN, it was part of conventional wisdom that despite the speed problems, mathematics made public key PRNGs more secure. I know that one of my personal blind spots is that I'm a contrarian. I'm also a cynic who believes that stupidity is one of the fundamental forces of the universe. So I find myself in the ironic position of defending a thing I never liked because yes, really, people *can* be that stupid. We all defer to authorities, are cowed by proofs, and lose our critical thinking skills when faced with a standard. I am reminded of Markoff Chaney from Illuminatus! as well as Poe's Purloined Letter. If we want to look at this as a root-cause exercise, we can go back to Blum-Blum-Shub and see the kernel of the flaws and blindness of them. You can see that despite it being there from the start, we didn't *understand* it. You can see the progression through Micali-Shnorr through the ANSI X9 committee, and then on to NIST. I'm left wondering if something can really be a backdoor if it was there all along, we just didn't grok it. Was the purloined letter hidden? I can't help but feel that calling it a back door is just too cheap and easy and convenient. It wasn't that we were collectively stupid and snookered ourselves, it was demons and those in league with them. This leaves the question of what they *have* been doing with that $250M, which is a good question. I lean towards private standards like those used in telecom etc. In the public world, we're good at doing it to ourselves. Jon --Boundary_(ID_resG8UD9if42WWC1TmNTow) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable I = found my missive in question, and upon re-reading it, I think it bears = repeating here.

The thread starts = with

<http://www.metzdowd.com/pipermail/cryptography/2014-January/019423.= html>

and the message I quote from below = is

<http://www.metzdowd.com/pipermail/cryptography/2014-January/019426.= html>.

The = discussion started with the blog post <http://blog.0xbadc0de.be/ar= chives/155> which purports to show how DUAL_EC_DRBG *must* have = been backdoored from the start. That blog post is the antecedent of "it" = in the paragraph first paragraph.

----

It's nice work on a technical level, = but I think it fails at its goal, that is to be a piece of polemic = -- even mischaracterizing the Ferguson/Shumow CRYPTO Rump Session = talk (their last slide explicitly said they were not suggesting = a back door).

Lest you think I'm saying something nice = about DUAL_EC_DRBG, I'll repeat what I've said before, "Only an = idiot would use it." It's slow, has biases in its output that = hashes and ciphers don't, and cannot be proved secure.

Let me = rewind to the first public key based DRBG/PRNG -- Blum-Blum-Shub. = (DRBG is the name NIST gave to what you and I would call a PRNG, = it's Deterministic Random Bit Generator. If you think of a complete = design of an RNG, you want at least three major sections -- = "entropy" collection, entropy pool management, and conditioned = output. A DRBG is the output stage.)

Blub-Blum-Shub uses an = iterated RSA-like operation to generate random bits. It was = developed in 1986 and is a brilliant piece of mathematics. It was one = of the very, very few bits of early crypto to have a sound = theoretical basis.

Many people who haven't thought it through = have sung its praises over the years, mostly because they got = seduced by the sound theoretic basis. Blum-Blum-Shub has two of the = three flaws that DUAL_EC_DRBG has: it's slow, and you can't prove = it secure.

I'm sure you thinking, 'What do you mean, "can't be = proved secure? Didn't you just say that it had a sound theoretical = basis?"' Yup, and the sound theoretical basis gives you the good = mathematical pseudo-randomness of the output. The slow part is = pretty obvious. The inobvious part is that it can't be proven = secure.

As an iterated, RSA-like operation, the core of it is two = prime numbers, p and q. The security resolves down to the secrecy = of the two primes.

And this leaves you with the question of how = you get the primes. Well, if you generate them at run time, then = you push the construction of your RNG down to the turtle below you. = Your random number generator requires random p and q and you get = those by using some other random number generator, one = presumes.

Alternatively, you could use a fixed p and q, and then = you have the *exact* flaw as DUAL_EC_DRBG -- you have a fixed = private key that can be used to jimmy the thing open.

Matt = Green wrote a great blog post last week at <http://blog.cryptographye= ngineering.com>, which you should read. I'll summarize a bit = and say that Micali and Shnorr did their own public-key based PRNG = which also has Step 1 being "generate large primes p and q" and = they helpfully gave test P and Q. I'm not merely being ironic. As = someone who implemented the AES-CTR DRBG, having test vectors is = really, really nice. NIST's test vectors for that are really, = really annoying and I'll complain at length to anyone who = cares.

Anyway, Matt Green identifies the Micali-Shnorr generator = as a precursor to DUAL_EC_DRBG in both design and having a fixed = key that you use for whatever purporses, testing or = compromise.

I have a couple points:

(Point 1) Any = public-key based PRNG is going to have the issue that either = you have a fixed key, or you have to generate a key using some = other secure means. This is why I use terms as strong as "can't be = proven to be secure" despite having a mathematical "sound = theoretical basis."

I think there's a huge security philosophy = problem here -- security proofs that are mathematical can have = underlying engineering assumptions that render them insecure to the = point of being silly.

I think that people get blinded by this as = well, and if there's a mathematical proof they're blinded by it, if = not cowed by the math and stop prodding at the engineering and = operational security.

Going back to Blum-Blum-Shub, look at the = Wikipedia article on it at <http://en.wikipedia.o= rg/wiki/Blum_Blum_Shub>. There are some = interesting statements there, like the first sentence of the = security section:

The generator is not appropriate = for use in simulations, only for
cryptography, because = it is very slow.

That makes me splutter. As an engineer, I'd = argue that slow alone makes it not suitable for cryptography. I'm = tempted to argue that for simulations, speed isn't an issue, but = really, if you slow things down enough, it's not suitable for = anything. I also have a long-standing twitch at *any* security = discussion that brings in performance. Performance is not security, = and many security sins have their root cause in a performance = worry, usually an artificial one.

The remainder of the section = reads:

However, there is a proof reducing its = security to the
computational difficulty of the = Quadratic residuosity problem.
Since the only known way = to solve that problem requires factoring
the modulus, = the difficulty of Integer factorization is generally
= regarded as providing security. When the primes are = chosen
appropriately, and O(log log M) lower-order bits = of each xn are
output, then in the limit as M grows = large, distinguishing the
output bits from random should = be at least as difficult as
factoring M.

= If integer factorization is difficult (as is suspected) then = B.B.S.
with large M should have an output free from any = nonrandom patterns
that can be discovered with any = reasonable amount of calculation.
Thus it appears to be = as secure as other encryption technologies
tied to the = factorization problem, such as RSA encryption.

This is = interesting because nowhere do they address the central = engineering issue -- that a fixed p,q is not secure yet a variable = one requires another RNG to seed the RNG.

Also look at the = section in the Handbook of Applied Cryptography = on "Cryptographically secure pseudorandom bit = generation":

<http://books.google.com/books?id=3DnSzoG72E93MC&= lpg=3DPA185&dq=3DCryptographically%20secure%20pseudorandom%20bit%20gen= eration&pg=3DPA185#v=3Donepage>

We find an RSA-based = generator there along with Micali-Shnorr and Blum-Blum-Shub and *all* of = these have a recipe that starts unironically = with (essentially):

1. Setup. Generate two RSA-like secret = primes, p and q.

This is a blind spot that's been there forever = -- two of the three flaws of DUAL_EC_DRBG have been staring us all = in the face since 1986. Despite mathematical brilliance, the = security of public-key based PRNGs have always been flawed with = something that could be used as a back door.

(Point 2) History = looks different when you look backwards than when you = look forwards. Everyone has a tendency to act as if things were = predetermined when we analyze the decisions of the past. We also = assign intent when we have to explain a WTF. Yet the usual answer = to "What were you thinking?" is "They weren't." To quote the great = philosopher David Byrne, "And you might say to yourself, 'My God, = what have I done?'"

The general flaws have been there forever, = and in general we still don't see them. In specific, the documents = on Micali-Shnorr and DUAL_EC_DRBG were up front about the flaw all = along.

Would the NSA exploit such a flaw? Hell, yes. We keep = seeing this from leaked documents, over and over. It's clear that = they have taken the hacker philosophy that nothing is out of scope = or out of bounds to heart as an operating principle. You can see it = in the recent ANT toy catalog, as well as the BULLRUN statement = that sent us all into a tizzy.

We have *assumed* that the BULLRUN = statement that they're after damaging standards means that = DUAL_EC_DRBG is backdoored. People have said it so loudly and so = often that it's part of conventional wisdom now. Yet until BULLRUN, = it was part of conventional wisdom that despite the speed problems, = mathematics made public key PRNGs more secure.

I know that = one of my personal blind spots is that I'm a contrarian. I'm also = a cynic who believes that stupidity is one of the fundamental = forces of the universe. So I find myself in the ironic position of = defending a thing I never liked because yes, really, people *can* = be that stupid. We all defer to authorities, are cowed by proofs, = and lose our critical thinking skills when faced with a standard. I = am reminded of Markoff Chaney from Illuminatus! as well as Poe's = Purloined Letter.

If we want to look at this as a root-cause = exercise, we can go back to Blum-Blum-Shub and see the kernel of the = flaws and blindness of them. You can see that despite it being = there from the start, we didn't *understand* it. You can see the = progression through Micali-Shnorr through the ANSI X9 committee, = and then on to NIST.

I'm left wondering if something can = really be a backdoor if it was there all along, we just didn't grok = it. Was the purloined letter hidden?

I can't help but feel = that calling it a back door is just too cheap and easy and = convenient. It wasn't that we were collectively stupid and = snookered ourselves, it was demons and those in league with = them.

This leaves the question of what they *have* been doing = with that $250M, which is a good question. I lean towards private = standards like those used in telecom etc. In the public world, = we're good at doing it to ourselves.

Jon

= --Boundary_(ID_resG8UD9if42WWC1TmNTow)-- From nobody Mon Mar 17 10:15:31 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A451A0432 for ; Mon, 17 Mar 2014 10:15:14 -0700 (PDT) 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 9zXkTDHO9-bP for ; Mon, 17 Mar 2014 10:15:13 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E47521A01C0 for ; Mon, 17 Mar 2014 10:15:12 -0700 (PDT) Received: (qmail 22109 invoked by uid 0); 17 Mar 2014 17:15:05 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 17 Mar 2014 17:15:05 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id eoEy1n00T2UhLwi01oF1wa; Mon, 17 Mar 2014 18:15:03 -0600 X-Authority-Analysis: v=2.1 cv=Ht/lRSjS c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=U0GcV9K8lpYA:10 a=3NT3xRclEPMA:10 a=8nJEP1OIZ-IA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=N9f8vlzIAAAA:8 a=P-fCVmJAAAAA:8 a=vciZqZV3_5uKB1QQ6H4A:9 a=jRYIlFMb9d6w7NvS:21 a=2YR6F72-AmfIHhh6:21 a=wPNLvfGTeEIA:10 a=5zrRBKlu_boA:10 a=d2k7d80oREwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=U32WpdDnZO1P12aMmpbiCAIBjhgl4NKRx4tH9mUK6yI=; b=8Zvjjo/vIuFHoAUIo281MBSgdgrDNJhLyGSSBBqTyrViKkNLmHpMV299TDDECbbxouMuLYvic0YuLHF1sIfiuQMwZrNmV6rdetEDSkTjPtYO5WFSocF9UoKku2rT53Tv; Received: from [216.113.168.128] (port=4597 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1WPb7r-0003WZ-D8 for dsfjdssdfsd@ietf.org; Mon, 17 Mar 2014 11:14:59 -0600 Message-ID: <53272D91.1030001@KingsMountain.com> Date: Mon, 17 Mar 2014 10:14:57 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Pseudorandom Number Generator PRNG discussion list Content-Type: text/plain; charset=ISO-8859-1; 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} Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/KvrlCYhiu8Wvj0vGSKxQE1KmEt4 Subject: [dsfjdssdfsd] fyi: Revisiting iOS Kernel (In)Security: Attacking the early random() PRNG 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, 17 Mar 2014 17:15:14 -0000 Of possible interest... Attacking the iOS 7 early_random() PRNG http://blog.azimuthsecurity.com/2014/03/attacking-ios-7-earlyrandom-prng.html Revisiting iOS Kernel (In)Security: Attacking the early random() PRNG http://mista.nu/research/early_random-paper.pdf http://mista.nu/research/early_random-slides.pdf Abstract. iOS is by many considered to be one of the most secure mo- bile platforms due to its stringent security features and relatively strong focus on mitigation technology. In an eort to improve kernel security, iOS 6 introduced numerous mitigations including verication cookies and memory layout randomization. Conceptually, these mitigations seek to complicate kernel exploitation by leveraging non-predictable data and therefore require sucient entropy to be provided at boot time. In this paper, we evaluate the security of the early random pseudorandom num- ber generator. The early random PRNG is fundamental in supporting the mitigations leveraged by the iOS kernel. Notably, we show how an attacker can recover arbitrary outputs generated by the early random PRNG in iOS 7 without being assisted by additional vulnerabilities or having any prior knowledge about the kernel address space. Recovering these outputs essentially allows an attacker to bypass a variety of exploit mitigations, such as those designed to mitigate specic exploitation tech- niques or whole classes of vulnerabilities. In turn, this may allow trivial exploitation of vulnerabilities previously deemed non-exploitable. From nobody Mon Mar 17 17:42:27 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 597D31A0308 for ; Mon, 17 Mar 2014 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fU2toqDCp7ZA for ; Mon, 17 Mar 2014 17:42:23 -0700 (PDT) Received: from nk11p00mm-asmtp003.mac.com (nk11p00mm-asmtp003.mac.com [17.158.161.2]) by ietfa.amsl.com (Postfix) with ESMTP id 68D071A0303 for ; Mon, 17 Mar 2014 17:42:22 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from [192.168.1.134] (c-66-31-43-48.hsd1.ma.comcast.net [66.31.43.48]) by nk11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2L00EVIWMCJL70@nk11p00mm-asmtp003.mac.com> for dsfjdssdfsd@ietf.org; Tue, 18 Mar 2014 00:42:14 +0000 (GMT) From: Arnold Reinhold In-reply-to: <20140316171716.GD31988@thunk.org> Date: Mon, 17 Mar 2014 20:43:36 -0400 Content-transfer-encoding: quoted-printable Message-id: References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org> <56491888.20140315165037@gmail.com> <20140316171716.GD31988@thunk.org> To: tytso@mit.edu X-Mailer: Apple Mail (2.1874) x-icloud-spam-score: 34444444 f=me.com; e=me.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXREEbG1oaGkdHB0lGUkdDRl5PWBoaHxEKTEMXGx0EGx8SBBscHwQdGxAbHho fGhEKWE0XSxEKbX4XGhEKTFkXGxobGxEKWUkXEQpZXhdoY3kRCkNOF0sbGxpiTk0caBsdcBl4c wcYYxoaHhhvEhEKWFwXGQQaBB0HTUsdEkhJHEwFGx0EGx8SBBscHwQdGxAbHhofGxEKXlkXYXJ +WWgRCkxGF2xraxEKQ1oXHBwEGRsEHhkEHhIRCkRYFxkRCkRJFxgRCkJGF2x9TER+fWUTaV4TE QpCRRd6f314WmxMXkNiQBEKQk4XbHBgeUAdYlJpGmIRCkJMF21oe2BOY0UFBWFoEQpCbBdnfnB FRFl6SEF9HBEKQkAXZGZdZm5LfkscWV4RCnBoF2cTQmlgfWV6ZEtuEQpwaBdlS29rYExZen8BE xEKcGgXYG56eX0faxxFGkMRCnBoF2JtHRN+YERDWmUTEQpwaBdjElheQWVTZVwBHhEKcGwXbn9 kQ21zfkQebhMR Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/9WKgZycgeWvD-z3XBU_bFqt94hA Cc: =?windows-1252?Q?=22Kriszti=E1n_Pint=E9r_=40thunk=2Eorg=22?= , dsfjdssdfsd@ietf.org Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets 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, 18 Mar 2014 00:42:25 -0000 On Mar 16, 2014, at 1:17 PM, tytso@mit.edu wrote: > On Sun, Mar 16, 2014 at 11:18:29AM -0400, Arnold Reinhold wrote: >>=20 >> And note that not all the issues I raised are software >> related. Tempest, for example, is a very tricky business. The NSA >> specs for Tempest protection are not publicly available, but I have >> been told they require tight physical configuration control, as even >> a single wire change can destroy Tempest protection. Perhaps the >> best that can be achieved is to keep any attacker a safe distance >> from critical systems. A determined attacker might be willing to >> absorb the effort and risk to covertly penetrate physical security >> barriers if doing so will lead to a permanent compromise of a >> one-time-seeded PRNG, less so if the benefits will last only briefly >> as the PRNG reseeds after they leave. >=20 > One of the things which is not obvious is whether or not each > contributor has the same threat model in mind. (In fact, it seems > pretty obvious to me that we don't all share the same threat model, > but I'm trying to be polite. :-) >=20 > The sort of things that you might need to worry about if you are > trying to protect against pervasive monitoring are very different if > you are worried about a targetted attack. If someone is willing to > bring in a listening truck and park it outside your house, or coverly > penetrate physical security, there is a whole host of things that you > would need to protect against before you are fully protected against > that level of attack. >=20 > In particular, who cares about how carefully constructed your RNG > might be if the attacker can replace it (along with perhaps your > entire networking stack, and the monitoring tools that might allow you > to notice that something strange has happened to your system)? Or > just simply drop in some malware which leaks the session key after > your perfect RNG that meets with all of the academics' worries about > state compromise recovery=85. I agree completely that there are multiple threat models in play = regarding RNG and that this is a cause for much confusion. As I see it = there are two broad categories: 1. The corporate threat model, which focuses on facilitating e-commerce = and financial transections, complying with privacy regulations, (HIPPA, = SOX, EU Data Directive, etc.), avoiding potential legal liability and = protecting trade secrets. 2. The personal privacy threat model, which fears the mass surveillance = society, doesn=92t trust corporate vendors and certifying bodies, and = considers state actors principal threats. I=92d put Bitcoin and the like = here. Intel=92s RDrand instruction is a good example of the difference. It is = deeply distrusted by group 2, but would appear to meet the needs of = group 1 (except maybe for trade secret protection at non-US companies). Nonetheless, I would like to see future RNG standards address both = groups' concerns as far as reasonably possible. And I would not be = dismissive about =94exotic=94 attacks such as Tempest. What was once the = purview of state actors like NSA, e.g. massively parallel machines for = brute forcing passwords and keys, is now widely in use by the private = and criminal sectors. =20 The time interval between RFCs 1750 and 4086 is over ten years and = another ten are likely to have elapsed before a successor is adopted. A = lot can happen in ten years, so it seems to me the goal should be to = recommend the best available technology and to at least consider as many = threats and use cases as can be reasonably foreseen, making technical = compromises only when clearly needed after due consideration of = alternatives. Arnold Reinhold From nobody Mon Mar 17 19:39: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 EB8591A0353 for ; Mon, 17 Mar 2014 19:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylCNfqQHR-rR for ; Mon, 17 Mar 2014 19:39:46 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D81A023D for ; Mon, 17 Mar 2014 19:39:46 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1WPjwH-0005rk-J1; Tue, 18 Mar 2014 02:39:37 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 046375801E5; Mon, 17 Mar 2014 22:39:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1395110373; bh=5JbL/IwWxZi9S8qNhv0O10BF0MNyK5wHgCD/AiMUyow=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eCU5Yoot7WAPVoJL23tIEBo4zUx2S7bV0CtMGts/nUu0eBZsCC2RfBf+g1cw+h4ky AmS8vCiCFn2uYdF46OFCoZrzYZQ0XryL9k8RyvGjtdt68VqVF1b/U/0z4AaYizuZWA sXCAMghA6yp9+v05djPaEvQdZetj38O+Uiv9XoSc= Date: Mon, 17 Mar 2014 22:39:32 -0400 From: tytso@mit.edu To: Arnold Reinhold Message-ID: <20140318023932.GA7144@thunk.org> References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org> <56491888.20140315165037@gmail.com> <20140316171716.GD31988@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/PCeAOw1Ceushv0KRfv3hejwphIE Cc: =?iso-8859-1?B?QGdtYWlsLmNvbT4=?=@thunk.org, dsfjdssdfsd@ietf.org, =?iso-8859-1?B?IktyaXN6dGnhbiBQaW506XIgQHRodW5rLm9yZyIgPHBpbnRlcmty?=@thunk.org Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets 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, 18 Mar 2014 02:39:48 -0000 On Mon, Mar 17, 2014 at 08:43:36PM -0400, Arnold Reinhold wrote: > 2. The personal privacy threat model, which fears the mass > surveillance society, doesn’t trust corporate vendors and certifying > bodies, and considers state actors principal threats. I’d put > Bitcoin and the like here. ... and this also needs to separated into the "proof against a targetted attack" and "protect against mass surveillance". There's a big difference between NSA or FBI cutting a deal with AT&T so that they get to put an Carnivore style keyword monitoring device in a telephone closet at a fiber exchange point, and the FBI deciding to park a Tempest van outside of your house. Cheers, - Ted From nobody Tue Mar 18 09:15:01 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F4A1A06F5 for ; Tue, 18 Mar 2014 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, T_MONEY_PERCENT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8b46cgtkbN9 for ; Tue, 18 Mar 2014 09:14:33 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 22E151A041D for ; Tue, 18 Mar 2014 09:14:32 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 18 Mar 2014 12:14:21 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 18 Mar 2014 12:14:21 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 12:14:20 -0400 From: Dan Brown To: "'joncallas@icloud.com'" , "'dsfjdssdfsd@ietf.org'" Thread-Topic: [dsfjdssdfsd] provability & Dual_EC ... [was Blum-Blum-Shub ambiguity in 4086 ...] Thread-Index: Ac9CxQ+6tC49sxKRTUuOfSNE/YvxTA== Date: Tue, 18 Mar 2014 16:14:20 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C59E28@XMB116CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF5C59E28XMB116CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/JVEmwoMQE_f8rwP0QrUDc8zlQCs Subject: Re: [dsfjdssdfsd] provability & Dual_EC ... [was Blum-Blum-Shub ambiguity in 4086 ...] 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, 18 Mar 2014 16:14:52 -0000 --_000_810C31990B57ED40B2062BA10D43FBF5C59E28XMB116CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for forwarding your interesting email here. You raise the provability issue about BBS (which is different from the two = issues about BBS that I previously raised, which were some attacks), and al= so extend it to Dual_EC, and perhaps any "public-key" DRBG. Specifically, you say that no public-key DRBG/PRNG can be proved secure. By= contrast, BBS claim a security proof (but I have not reviewed the BBS proo= f at all). Gjosteen and I claim a security proof CRYPTO 2007 for Dual_EC. = Therefore, it would be interesting if we could find some common ground. T= o that end, I've taken some time to write a reactionary missive that I thin= k addresses your concerns. Firstly, the Dual_EC proof is only about its quality as a DRBG, PRNG, or PR= G. Specifically, any PRG, including HMAC_DRBG, CTR_DRBG, starts with an in= itially random fixed length secret seed, maintains a state, and outputs a l= ong stream, with the aim to provide some measure of indistinguishability fo= r the existing outputs even permitting the adversary to access the latest c= urrent state. Our claims ignored the threat of state compromise recovery (= aka prediction resistance). As usual, a security proof, like any proof, ha= s some hypotheses, and its conclusions are only as a strong as its hypothes= es. Also, it is implied by our CRYPTO 2007 paper, that what's required to = be initially short secret seed is not only the conventional running state s= , but also trapdoor-component of the state log_P(Q). To force log_P(Q) to = be random, one can just choose P and Q to be random. To do that, choose th= em yourself, derived from the same entropy source you needed for the runnin= g state, or else choose them as nothing up my sleeve numbers ideally perhap= s via NIST SP 800-90A alternative formulation. These techniques help to ma= ke log_P(Q) known to nobody at all. If log_P(Q) has been chosen by (or for)= you, by some authority, then the Dual_EC, according to the proof, seems se= cure against everybody but those who know both the running secret state and= the value of log_P(Q). Secondly, you also critique of Dual_EC and BBS that the p's and q's themsel= ves need a DRBG to be generated. But then so does any DRBG, once one insis= ts on uniform keys (like conventional security assmuptions for HMAC and AES= -CTR usually do). That's what entropy conditioners can help resolve, trans= itioning from biased raw entropy, to something more like the keys that conv= entional crypto algorithms usually expect. Also, a variable output-length = DRBG is not needed either, because the input states to DRBG are fixed lengt= h (with the exceptional of continuously reseeding DRBG). Maybe it's a gre= ater nuisance to generate the public-key DRBG seeds, but I don't see it as = some essential obstacle. That all said, I disagree {with /and perhaps even if} the conventional wisd= om {that / is} the public-key PRNGs are more secure, by some kind of defaul= t. Security should be measured by firstly (a) what attacks are known, and = by secondly (b) what the valid proofs claim and assume. It's still on my t= o-do list to review the security proof for HMAC_DRBG, and see what assumpti= ons it hypothesizes. It is also my hope that the somebody will prove the se= curity of CTR_DRBG, even if in the ideal cipher model (which may be necessa= ry because its backtracking resistance depends on related keys, and most st= andard assumptions about AES don't involve related keys). As far as I know= , there's no fundamental difference in being able to prove security of sche= mes built from symmetric and asymmetric primitives. The fixed version of D= ual_EC (i.e. truncated to 50% of bits per point and "verifiably random" P &= Q), the HMAC_DRBG and CTR_DRBG are free from any known attacks. It is also= good to have security proofs to complement the lack of attacks. I also sympathize with your general point that security proofs have the dan= ger of dazzling and, thereby, lulling some people into passive acceptance. = That's a psychological issue, and I don't have any kind of workaround for i= t. I think many other people have written lots on the general topic (see A= nother Look ...). I wonder how much other factors can induce similar effec= ts: implementations, advertising, publication, ... You rightly point out a commonality between some public-key DRBGs, namely D= ual_EC and BBS, and their potential for a private key to be abused as a bac= kdoor. That said, some differences between BBS and Dual_EC (only the insuf= ficiently truncated version and backdoored version) include a different in = impact upon adversarial knowledge of the private-key-like "trapdoor" (porti= on of the effective secret state): 1. Given also one output, Dual_EC allows computation of future states = (i.e. same consequence as state reveal for any DRBG), and distinguishing of= previous past output from random. 2. Given also one running secret state, BBS allows computation of futu= re and past states (and thus outputs). So arguably, the weak version Dual_EC improves on BBS slightly on the narro= w aspect of the backtracking resistance: only distinguishing is possible, n= ot computation. (To be fair, though, BBS is better on the aspect of semmin= g to require invasive access to the internal secret state before backtracki= ng.) The significance of this is that (computational) backtracking resista= nce is helpful, perhaps needed, for forward secrecy. Notice that there see= ms some growing demand for forward secrecy. This brings me back to my secon= d issue about BBS in my original email on this thread. Again the fully corrected version of Dual_EC does not have any known backtr= acking vulnerability at all, and like, HMAC_DRBG, even has a security proof= (under various reasonable assumptions). Its main disadvantages are being= relatively slow, and hard-to-explain differences between the possibly-back= doored version. Best regards, Dan From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Jon Ca= llas Sent: Monday, March 17, 2014 12:53 PM To: dsfjdssdfsd@ietf.org Cc: Jon Callas Subject: Re: [dsfjdssdfsd] Blum-Blum-Shub ambiguity in 4086 ... I found my missive in question, and upon re-reading it, I think it bears re= peating here. The thread starts with and the message I quote from below is . The discussion started with the blog post which purports to show how DUAL_EC_DRBG *must* have been backdoored = from the start. That blog post is the antecedent of "it" in the paragraph f= irst paragraph. ---- It's nice work on a technical level, but I think it fails at its goal, that= is to be a piece of polemic -- even mischaracterizing the Ferguson/Shumow = CRYPTO Rump Session talk (their last slide explicitly said they were not su= ggesting a back door). Lest you think I'm saying something nice about DUAL_EC_DRBG, I'll repeat wh= at I've said before, "Only an idiot would use it." It's slow, has biases in= its output that hashes and ciphers don't, and cannot be proved secure. Let me rewind to the first public key based DRBG/PRNG -- Blum-Blum-Shub. (D= RBG is the name NIST gave to what you and I would call a PRNG, it's Determi= nistic Random Bit Generator. If you think of a complete design of an RNG, y= ou want at least three major sections -- "entropy" collection, entropy pool= management, and conditioned output. A DRBG is the output stage.) Blub-Blum-Shub uses an iterated RSA-like operation to generate random bits.= It was developed in 1986 and is a brilliant piece of mathematics. It was o= ne of the very, very few bits of early crypto to have a sound theoretical b= asis. Many people who haven't thought it through have sung its praises over the y= ears, mostly because they got seduced by the sound theoretic basis. Blum-Bl= um-Shub has two of the three flaws that DUAL_EC_DRBG has: it's slow, and yo= u can't prove it secure. I'm sure you thinking, 'What do you mean, "can't be proved secure? Didn't y= ou just say that it had a sound theoretical basis?"' Yup, and the sound the= oretical basis gives you the good mathematical pseudo-randomness of the out= put. The slow part is pretty obvious. The inobvious part is that it can't b= e proven secure. As an iterated, RSA-like operation, the core of it is two prime numbers, p = and q. The security resolves down to the secrecy of the two primes. And this leaves you with the question of how you get the primes. Well, if y= ou generate them at run time, then you push the construction of your RNG do= wn to the turtle below you. Your random number generator requires random p = and q and you get those by using some other random number generator, one pr= esumes. Alternatively, you could use a fixed p and q, and then you have the *exact*= flaw as DUAL_EC_DRBG -- you have a fixed private key that can be used to j= immy the thing open. Matt Green wrote a great blog post last week at , which you should read. I'll summarize a bit and say that Mi= cali and Shnorr did their own public-key based PRNG which also has Step 1 b= eing "generate large primes p and q" and they helpfully gave test P and Q. = I'm not merely being ironic. As someone who implemented the AES-CTR DRBG, h= aving test vectors is really, really nice. NIST's test vectors for that are= really, really annoying and I'll complain at length to anyone who cares. Anyway, Matt Green identifies the Micali-Shnorr generator as a precursor to= DUAL_EC_DRBG in both design and having a fixed key that you use for whatev= er purporses, testing or compromise. I have a couple points: (Point 1) Any public-key based PRNG is going to have the issue that either = you have a fixed key, or you have to generate a key using some other secure= means. This is why I use terms as strong as "can't be proven to be secure"= despite having a mathematical "sound theoretical basis." I think there's a huge security philosophy problem here -- security proofs = that are mathematical can have underlying engineering assumptions that rend= er them insecure to the point of being silly. I think that people get blinded by this as well, and if there's a mathemati= cal proof they're blinded by it, if not cowed by the math and stop prodding= at the engineering and operational security. Going back to Blum-Blum-Shub, look at the Wikipedia article on it at . There are some interesting stateme= nts there, like the first sentence of the security section: The generator is not appropriate for use in simulations, only for cryptography, because it is very slow. That makes me splutter. As an engineer, I'd argue that slow alone makes it = not suitable for cryptography. I'm tempted to argue that for simulations, s= peed isn't an issue, but really, if you slow things down enough, it's not s= uitable for anything. I also have a long-standing twitch at *any* security = discussion that brings in performance. Performance is not security, and man= y security sins have their root cause in a performance worry, usually an ar= tificial one. The remainder of the section reads: However, there is a proof reducing its security to the computational difficulty of the Quadratic residuosity problem. Since the only known way to solve that problem requires factoring the modulus, the difficulty of Integer factorization is generally regarded as providing security. When the primes are chosen appropriately, and O(log log M) lower-order bits of each xn are output, then in the limit as M grows large, distinguishing the output bits from random should be at least as difficult as factoring M. If integer factorization is difficult (as is suspected) then B.B.S. with large M should have an output free from any nonrandom patterns that can be discovered with any reasonable amount of calculation. Thus it appears to be as secure as other encryption technologies tied to the factorization problem, such as RSA encryption. This is interesting because nowhere do they address the central engineering= issue -- that a fixed p,q is not secure yet a variable one requires anothe= r RNG to seed the RNG. Also look at the section in the Handbook of Applied Cryptography on "Crypto= graphically secure pseudorandom bit generation": We find an RSA-based generator there along with Micali-Shnorr and Blum-Blum= -Shub and *all* of these have a recipe that starts unironically with (essen= tially): 1. Setup. Generate two RSA-like secret primes, p and q. This is a blind spot that's been there forever -- two of the three flaws of= DUAL_EC_DRBG have been staring us all in the face since 1986. Despite math= ematical brilliance, the security of public-key based PRNGs have always bee= n flawed with something that could be used as a back door. (Point 2) History looks different when you look backwards than when you loo= k forwards. Everyone has a tendency to act as if things were predetermined = when we analyze the decisions of the past. We also assign intent when we ha= ve to explain a WTF. Yet the usual answer to "What were you thinking?" is "= They weren't." To quote the great philosopher David Byrne, "And you might s= ay to yourself, 'My God, what have I done?'" The general flaws have been there forever, and in general we still don't se= e them. In specific, the documents on Micali-Shnorr and DUAL_EC_DRBG were u= p front about the flaw all along. Would the NSA exploit such a flaw? Hell, yes. We keep seeing this from leak= ed documents, over and over. It's clear that they have taken the hacker phi= losophy that nothing is out of scope or out of bounds to heart as an operat= ing principle. You can see it in the recent ANT toy catalog, as well as the= BULLRUN statement that sent us all into a tizzy. We have *assumed* that the BULLRUN statement that they're after damaging st= andards means that DUAL_EC_DRBG is backdoored. People have said it so loudl= y and so often that it's part of conventional wisdom now. Yet until BULLRUN= , it was part of conventional wisdom that despite the speed problems, mathe= matics made public key PRNGs more secure. I know that one of my personal blind spots is that I'm a contrarian. I'm al= so a cynic who believes that stupidity is one of the fundamental forces of = the universe. So I find myself in the ironic position of defending a thing = I never liked because yes, really, people *can* be that stupid. We all defe= r to authorities, are cowed by proofs, and lose our critical thinking skill= s when faced with a standard. I am reminded of Markoff Chaney from Illumina= tus! as well as Poe's Purloined Letter. If we want to look at this as a root-cause exercise, we can go back to Blum= -Blum-Shub and see the kernel of the flaws and blindness of them. You can s= ee that despite it being there from the start, we didn't *understand* it. Y= ou can see the progression through Micali-Shnorr through the ANSI X9 commit= tee, and then on to NIST. I'm left wondering if something can really be a backdoor if it was there al= l along, we just didn't grok it. Was the purloined letter hidden? I can't help but feel that calling it a back door is just too cheap and eas= y and convenient. It wasn't that we were collectively stupid and snookered = ourselves, it was demons and those in league with them. This leaves the question of what they *have* been doing with that $250M, wh= ich is a good question. I lean towards private standards like those used in= telecom etc. In the public world, we're good at doing it to ourselves. Jon --_000_810C31990B57ED40B2062BA10D43FBF5C59E28XMB116CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

Thanks for forwarding = your interesting email here.

You raise the provabil= ity issue about BBS (which is different from the two issues about BBS that = I previously raised, which were some attacks), and also extend it to Dual_E= C, and perhaps any “public-key” DRBG.

Specifically, you say = that no public-key DRBG/PRNG can be proved secure. By contrast, BBS claim a= security proof (but I have not reviewed the BBS proof at all). Gjost= een and I claim a security proof CRYPTO 2007 for Dual_EC. Therefore, it would be interesting if we could find som= e common ground. To that end, I’ve taken some time to write a r= eactionary missive that I think addresses your concerns.<= /p>

Firstly, the Dual_EC p= roof is only about its quality as a DRBG, PRNG, or PRG. Specifically,= any PRG, including HMAC_DRBG, CTR_DRBG, starts with an initially random fi= xed length secret seed, maintains a state, and outputs a long stream, with the aim to provide some measure of indisti= nguishability for the existing outputs even permitting the adversary to acc= ess the latest current state. Our claims ignored the threat of state = compromise recovery (aka prediction resistance). As usual, a security proof, like any proof, has some hypotheses, and its c= onclusions are only as a strong as its hypotheses. Also, it is implie= d by our CRYPTO 2007 paper, that what’s required to be initially shor= t secret seed is not only the conventional running state s, but also trapdoor-component of the state log_P(Q). = To force log_P(Q) to be random, one can just choose P and Q to be random.&n= bsp; To do that, choose them yourself, derived from the same entropy source= you needed for the running state, or else choose them as nothing up my sleeve numbers ideally perhaps via NIST SP 80= 0-90A alternative formulation. These techniques help to make log_P(Q)= known to nobody at all. If log_P(Q) has been chosen by (or for) you, by so= me authority, then the Dual_EC, according to the proof, seems secure against everybody but those who know both the r= unning secret state and the value of log_P(Q).

Secondly, you also cri= tique of Dual_EC and BBS that the p’s and q’s themselves need a= DRBG to be generated. But then so does any DRBG, once one insists on= uniform keys (like conventional security assmuptions for HMAC and AES-CTR usually do). That’s what entropy conditio= ners can help resolve, transitioning from biased raw entropy, to something = more like the keys that conventional crypto algorithms usually expect. = ; Also, a variable output-length DRBG is not needed either, because the input states to DRBG are fixed length (with the except= ional of continuously reseeding DRBG). Maybe it’s a great= er nuisance to generate the public-key DRBG seeds, but I don’t see it= as some essential obstacle.

That all said, I disag= ree {with /and perhaps even if} the conventional wisdom {that / is} the pub= lic-key PRNGs are more secure, by some kind of default. Security shou= ld be measured by firstly (a) what attacks are known, and by secondly (b) what the valid proofs claim and assume.&nbs= p; It’s still on my to-do list to review the security proof for HMAC_= DRBG, and see what assumptions it hypothesizes. It is also my hope that the= somebody will prove the security of CTR_DRBG, even if in the ideal cipher model (which may be necessary because its back= tracking resistance depends on related keys, and most standard assumptions = about AES don’t involve related keys). As far as I know, there&= #8217;s no fundamental difference in being able to prove security of schemes built from symmetric and asymmetric primitives.&= nbsp; The fixed version of Dual_EC (i.e. truncated to 50% of bits per point= and “verifiably random” P & Q), the HMAC_DRBG and CTR_DRBG= are free from any known attacks. It is also good to have security proofs to complement the lack of attacks.<= /p>

I also sympathize with= your general point that security proofs have the danger of dazzling and, t= hereby, lulling some people into passive acceptance. That’s a psychol= ogical issue, and I don’t have any kind of workaround for it. I think many other people have written lots on th= e general topic (see Another Look …). I wonder how much other f= actors can induce similar effects: implementations, advertising, publicatio= n, …

You rightly point out = a commonality between some public-key DRBGs, namely Dual_EC and BBS, and th= eir potential for a private key to be abused as a backdoor. That said= , some differences between BBS and Dual_EC (only the insufficiently truncated version and backdoored version) include= a different in impact upon adversarial knowledge of the private-key-like &= #8220;trapdoor” (portion of the effective secret state):

1.&n= bsp; Given also one= output, Dual_EC allows computation of future states (i.e. same consequence= as state reveal for any DRBG), and distinguishing of previous past output = from random.

2.&n= bsp; Given also one= running secret state, BBS allows computation of future and past states (an= d thus outputs).

So arguably, the weak = version Dual_EC improves on BBS slightly on the narrow aspect of the backtr= acking resistance: only distinguishing is possible, not computation. = (To be fair, though, BBS is better on the aspect of semming to require invasive access to the internal secret state = before backtracking.) The significance of this is that (computational= ) backtracking resistance is helpful, perhaps needed, for forward secrecy.&= nbsp; Notice that there seems some growing demand for forward secrecy. This brings me back to my second issue about B= BS in my original email on this thread.

Again the fully correc= ted version of Dual_EC does not have any known backtracking vulnerability a= t all, and like, HMAC_DRBG, even has a security proof (under various reason= able assumptions). Its main disadvantages are being relatively slow, and hard-to-explain differences between the pos= sibly-backdoored version.

Best regards,

Dan<= /p>

From: dsfjdssd= fsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Jon Callas
Sent: Monday, March 17, 2014 12:53 PM
To: dsfjdssdfsd@ietf.org
Cc: Jon Callas
Subject: Re: [dsfjdssdfsd] Blum-Blum-Shub ambiguity in 4086 ...=

I found my missive in question, and upon re-reading = it, I think it bears repeating here.

= The thread starts with

= <http://www.metzdowd.com/pipermail/cryptography/2014-January/01= 9423.html>

= and the message I quote from below is

= <http://www.metzdowd.com/pipermail/cryptography/2014-January/01= 9426.html>.

= The discussion started with the blog post <http://blog.0xbadc0de.be/archives/155> which pu= rports to show how DUAL_EC_DRBG *must* have been backdoored from the start. That blog post is the antecedent of "it" in the = paragraph first paragraph.

= ----

It's nice work on a technical level, but I t= hink it fails at its goal, that is to be a piece of polemic -- even mi= scharacterizing the Ferguson/Shumow CRYPTO Rump Session talk (their last slide explicitly said they were not suggesting a bac= k door).

Lest you think I'm saying something nice about DUAL_EC_DRBG, I'll repeat wh= at I've said before, "Only an idiot would use it." It's slow= , has biases in its output that hashes and ciphers don't, and cannot b= e proved secure.

Let me rewind to the first public key based DRBG/PRNG -- Blum-Blum-Shub. (D= RBG is the name NIST gave to what you and I would call a PRNG, it's De= terministic Random Bit Generator. If you think of a complete design of= an RNG, you want at least three major sections -- "entropy" collection, entropy pool management, and condi= tioned output. A DRBG is the output stage.)

Blub-Blum-Shub uses an iterated RSA-like operation to generate random bits.= It was developed in 1986 and is a brilliant piece of mathematics. It = was one of the very, very few bits of early crypto to have a sound the= oretical basis.

Many people who haven't thought it through have sung its praises over the&n= bsp;years, mostly because they got seduced by the sound theoretic basis. Bl= um-Blum-Shub has two of the three flaws that DUAL_EC_DRBG has: it's slow, a= nd you can't prove it secure.

I'm sure you thinking, 'What do you mean, "can't be proved secure? Did= n't you just say that it had a sound theoretical basis?"' Yup, an= d the sound theoretical basis gives you the good mathematical pseudo-r= andomness of the output. The slow part is pretty obvious. The inobvious part is that it can't be proven secure.

As an iterated, RSA-like operation, the core of it is two prime numbers, p = and q. The security resolves down to the secrecy of the two primes.
And this leaves you with the question of how you get the primes. Well, if y= ou generate them at run time, then you push the construction of your R= NG down to the turtle below you. Your random number generator requires= random p and q and you get those by using some other random number generator, one presumes.

Alternatively, you could use a fixed p and q, and then you have the *exact*= flaw as DUAL_EC_DRBG -- you have a fixed private key that can be used= to jimmy the thing open.

Matt Green wrote a great blog post last week at <http://blog.cryptographyengineering.com>, which you should read. I'll summarize a bit and say that Mical= i and Shnorr did their own public-key based PRNG which also has Step 1 being "generate large primes p and q" and they&n= bsp;helpfully gave test P and Q. I'm not merely being ironic. As someone wh= o implemented the AES-CTR DRBG, having test vectors is really, really = nice. NIST's test vectors for that are really, really annoying and I'll complain at length to anyone who cares.

Anyway, Matt Green identifies the Micali-Shnorr generator as a precursor to= DUAL_EC_DRBG in both design and having a fixed key that you use for w= hatever purporses, testing or compromise.

I have a couple points:

(Point 1) Any public-key based PRNG is going to have the issue that either = you have a fixed key, or you have to generate a key using some other s= ecure means. This is why I use terms as strong as "can't be prove= n to be secure" despite having a mathematical "sound theoretical basis."

I think there's a huge security philosophy problem here -- security proofs = that are mathematical can have underlying engineering assumptions that= render them insecure to the point of being silly.

I think that people get blinded by this as well, and if there's a mathemati= cal proof they're blinded by it, if not cowed by the math and stop pro= dding at the engineering and operational security.

Going back to Blum-Blum-Shub, look at the Wikipedia article on it at &= lt;http://en.wikipe= dia.org/wiki/Blum_Blum_Shub>. There are some interesting statem= ents there, like the first sentence of the security section:

The generator is not appropriate for use in simulations, only = for
cryptography, because it is very slow.

That makes me splutter. As an engineer, I'd argue that slow alone makes it = not suitable for cryptography. I'm tempted to argue that for simulatio= ns, speed isn't an issue, but really, if you slow things down enough, = it's not suitable for anything. I also have a long-standing twitch at *any* security discussion that brings in pe= rformance. Performance is not security, and many security sins have th= eir root cause in a performance worry, usually an artificial one.

The remainder of the section reads:

However, there is a proof reducing its security to the
computational difficulty of the Quadratic residuosity problem.=
Since the only known way to solve that problem requires factor= ing
the modulus, the difficulty of Integer factorization is genera= lly
regarded as providing security. When the primes are chosen
appropriately, and O(log log M) lower-order bits of each xn ar= e
output, then in the limit as M grows large, distinguishing the=
output bits from random should be at least as difficult as
factoring M.

If integer factorization is difficult (as is suspected) then B= .B.S.
with large M should have an output free from any nonrandom pat= terns
that can be discovered with any reasonable amount of calculati= on.
Thus it appears to be as secure as other encryption technologi= es
tied to the factorization problem, such as RSA encryption.

This is interesting because nowhere do they address the central engineering= issue -- that a fixed p,q is not secure yet a variable one requires a= nother RNG to seed the RNG.

Also look at the section in the Handbook of Applied Cryptography on &q= uot;Cryptographically secure pseudorandom bit generation":

<http://books.google.com/books?id=3DnSzoG72E93MC&= amp;lpg=3DPA185&dq=3DCryptographically%20secure%20pseudorandom%20bit%20= generation&pg=3DPA185#v=3Donepage>

We find an RSA-based generator there along with Micali-Shnorr and Blum-Blum= -Shub and *all* of these have a recipe that starts unironically with (= essentially):

1. Setup. Generate two RSA-like secret primes, p and q.

This is a blind spot that's been there forever -- two of the three flaws of= DUAL_EC_DRBG have been staring us all in the face since 1986. Despite= mathematical brilliance, the security of public-key based PRNGs have = always been flawed with something that could be used as a back door.

(Point 2) History looks different when you look backwards than when you loo= k forwards. Everyone has a tendency to act as if things were predeterm= ined when we analyze the decisions of the past. We also assign intent = when we have to explain a WTF. Yet the usual answer to "What were you thinking?" is "They weren't.&= quot; To quote the great philosopher David Byrne, "And you might say t= o yourself, 'My God, what have I done?'"

The general flaws have been there forever, and in general we still don't se= e them. In specific, the documents on Micali-Shnorr and DUAL_EC_DRBG w= ere up front about the flaw all along.

Would the NSA exploit such a flaw? Hell, yes. We keep seeing this from leak= ed documents, over and over. It's clear that they have taken the hacke= r philosophy that nothing is out of scope or out of bounds to heart as= an operating principle. You can see it in the recent ANT toy catalog, as well as the BULLRUN statement that sen= t us all into a tizzy.

We have *assumed* that the BULLRUN statement that they're after damaging&nb= sp;standards means that DUAL_EC_DRBG is backdoored. People have said it so = loudly and so often that it's part of conventional wisdom now. Yet unt= il BULLRUN, it was part of conventional wisdom that despite the speed problems, mathematics made public key PRNGs mo= re secure.

I know that one of my personal blind spots is that I'm a contrarian. I'm al= so a cynic who believes that stupidity is one of the fundamental force= s of the universe. So I find myself in the ironic position of defendin= g a thing I never liked because yes, really, people *can* be that stupid. We all defer to authorities, are cowed b= y proofs, and lose our critical thinking skills when faced with a stan= dard. I am reminded of Markoff Chaney from Illuminatus! as well as Poe= 's Purloined Letter.

If we want to look at this as a root-cause exercise, we can go back to Blum= -Blum-Shub and see the kernel of the flaws and blindness of them. You can s= ee that despite it being there from the start, we didn't *understand* = it. You can see the progression through Micali-Shnorr through the ANSI X9 committee, and then on to NIST.

I'm left wondering if something can really be a backdoor if it was there al= l along, we just didn't grok it. Was the purloined letter hidden? = ;

I can't help but feel that calling it a back door is just too cheap and eas= y and convenient. It wasn't that we were collectively stupid and snook= ered ourselves, it was demons and those in league with them.

This leaves the question of what they *have* been doing with that $250M, wh= ich is a good question. I lean towards private standards like those us= ed in telecom etc. In the public world, we're good at doing it to ours= elves.

Jon

--_000_810C31990B57ED40B2062BA10D43FBF5C59E28XMB116CNCrimnet_-- From nobody Tue Mar 18 10:06:38 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1531A06F8 for ; Tue, 18 Mar 2014 10:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F29Ud1WDQDQX for ; Tue, 18 Mar 2014 10:06:33 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 962541A0721 for ; Tue, 18 Mar 2014 10:06:16 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id 7B1D56D52B; Tue, 18 Mar 2014 13:06:03 -0400 (EDT) Message-ID: <53287CF9.9050407@iang.org> Date: Tue, 18 Mar 2014 17:06:01 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dsfjdssdfsd@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/CHDfQ1C38Vx2ZB4dk0dSzb-vPhw Cc: Dan Brown , "joncallas@icloud.com" Subject: Re: [dsfjdssdfsd] provability & Dual_EC ... [was Blum-Blum-Shub ambiguity in 4086 ...] 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, 18 Mar 2014 17:06:35 -0000 Hi Dan, > You raise the provability issue about BBS (which is different from the two issues about BBS that I previously raised, which were some attacks), and also extend it to Dual_EC, and perhaps any "public-key" DRBG. I recently had built a DRBG or PRNG. I tasked an intern (3rd year comp sci) to do it. I instructed ChaCha. That was about it. I was able to do that because (a ) I know what ChaCha does, enough for this task, (b ) she was able to learn enough about it to write ChaCha from the paper and get it up and going, within 3 weeks, also a mixer and a collector, (c ) we're using it for crypto as well as RNGs, and (d ) if anything goes wrong with it we'll hear about it. Oh, and it comes with some pedigree, call that (e ). These are very simple engineering things. They give me confidence. And, none of the above characteristics are true of BBS or Dual_EC. Provability doesn't change that, it doesn't add to the list, and in my mind it makes it more suspicious, it gives it an air of mystique and salesmanship. This isn't saying anything that Jon didn't say, it's just adding some anecdotal flesh -- out in the coding world we'll do what is practical as engineers, we add tires on so we can kick them. We typically wouldn't touch things we don't understand with a barge pole. It's really a pragmatic approach I suppose, very humdrum, but it is what we do. iang From nobody Tue Mar 18 10:21:47 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607281A06F3 for ; Tue, 18 Mar 2014 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 YoZsBgOKIqX2 for ; Tue, 18 Mar 2014 10:21:42 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id EF2341A0728 for ; Tue, 18 Mar 2014 10:21:22 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 18 Mar 2014 13:21:06 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 13:21:06 -0400 From: Dan Brown To: "dsfjdssdfsd@ietf.org" Thread-Topic: Should we/4086 focus on key generation, and defer key derivation and key streaming to elsewhere? Thread-Index: Ac9CzlkkvLlGCzN4TiODOz6M+NoFrA== Date: Tue, 18 Mar 2014 17:21:05 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C59ED3@XMB116CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0049_01CF42AC.EAFD2320" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/hstfQmtdFDJnRpMk5RaPZTC9cSg Subject: [dsfjdssdfsd] Should we/4086 focus on key generation, and defer key derivation and key streaming to elsewhere? 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, 18 Mar 2014 17:21:45 -0000 ------=_NextPart_000_0049_01CF42AC.EAFD2320 Content-Type: multipart/related; boundary="----=_NextPart_001_004A_01CF42AC.EAFEA9C0" ------=_NextPart_001_004A_01CF42AC.EAFEA9C0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_004B_01CF42AC.EAFEA9C0" ------=_NextPart_002_004B_01CF42AC.EAFEA9C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Random List Members, What classes of "RNGs" are useful (or just used) in cryptography? / Should 4086bis cover them? I provide my three answers to these questions below, but am also interested in others' answers. Key streams. / No. Key streams take a short shared secret and generate a long key stream apparently indistinguishable from random. RFC 4086 seems to also cover key stream (cipher) generation, in Section 6.2 (third paragraph xor'ing one-time pads) , but it seems too far out of scope for 4086. CFRG, or each individual IETF WGs, now covers stream cipher, at least when as one-time pads. Beyond one-time pads, key streams may be useful for side-channel protection, i.e. blinding (or for general purpose non-crypto applications, in which case, they not crypto security properties may be required). My thought; let's exclude key streaming applications from 4086bis and instead the focus on the more fundamental task of key generation (further below, after derivation). Key derivation. / No. Key derivation function take a (shared or not) short secret key, derive yet more short keys, often customized for a single purpose. Examples: from TLS master_key to encryption key; DH raw shared secret conversion to a session key; perhaps even private DH keys to session keys; passwords to key conversion via slow, costly function; -- perhaps also even key wrap as in S/MIME, nonce generation, and even ephemeral secret key generation. These seem to be covered by various other specs, so ought not to be included in 4086. Again, 4086bis ought best to focus of key generation (below). Key generation. / Yes. With no pre-existing short key, this is a task that actually requires some genuine secret entropy gathering, and perhaps a persistent state (whereas the streams and derivations are stateless functions). The output here could be quite short, since streaming and derivation can easily generate more keys. I think it would be good for 4086bis to focus more on this task. The term "generation" is a little awkward, because it is does not distinguish itself well from key derivation. Note that key derivation and key streaming already rely on good key generation, so key generation is unavoidable, and fundamental. /// The approach above is task-oriented. An opposite approach would be tool-oriented: describe RNGs as a general purpose tool, and how to build them well and so on, and try to target every possible security goal. That approach may have poorly defined (or at least poorly prioritized) set of requirements, but may also have more realistic implementability. Perhaps both approaches should be pursued, but I'd hope for at least a clearly defined set of task-oriented requirements that is especially careful about key generation. An approach similar to the tool-oriented approach is an attack-oriented approach, which has been started already in a different thread here, by Nick M. Best regards, Daniel Brown Research In Motion Limited ------=_NextPart_002_004B_01CF42AC.EAFEA9C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Random List Members,

What classes of “RNGs” = are useful (or just used) in cryptography? / Should 4086bis cover = them?

I provide my three answers to these questions below, but am = also interested in others’ answers.

Key streams. / = No.

Key streams take a short shared secret and generate a long = key stream apparently indistinguishable from random. RFC 4086 seems to = also cover key stream (cipher) generation, in Section 6.2 (third = paragraph xor’ing one-time pads) , but it seems too far out of = scope for 4086. CFRG, or each individual IETF WGs, now covers = stream cipher, at least when as one-time pads. Beyond = one-time pads, key streams may be useful for side-channel protection, = i.e. blinding (or for general purpose non-crypto applications, in which = case, they not crypto security properties may be required). = My thought; let’s exclude key streaming applications = from 4086bis and instead the focus on the more fundamental task of key = generation (further below, after derivation).

Key derivation. / = No.

Key derivation function take a (shared or not) short secret = key, derive yet more short keys, often customized for a single = purpose. Examples: from TLS master_key to encryption key; DH raw = shared secret conversion to a session key; perhaps even private DH keys = to session keys; passwords to key conversion via slow, costly function; = -- perhaps also even key wrap as in S/MIME, nonce generation, and even = ephemeral secret key generation. These seem to be covered by = various other specs, so ought not to be included in 4086. Again, = 4086bis ought best to focus of key generation = (below).

Key generation. / Yes.

With no pre-existing short key, = this is a task that actually requires some genuine secret entropy = gathering, and perhaps a persistent state (whereas the streams and = derivations are stateless functions). The output here could be = quite short, since streaming and derivation can easily generate more = keys. I think it would be good for 4086bis to focus more on this = task. The term “generation” is a little awkward, = because it is does not distinguish itself well from key = derivation. Note that key derivation and key streaming already = rely on good key generation, so key generation is unavoidable, and = fundamental.

///

The approach above is task-oriented. =

An opposite approach would be tool-oriented: describe RNGs = as a general purpose tool, and how to build them well and so on, and try = to target every possible security goal. That approach may have = poorly defined (or at least poorly prioritized) set of requirements, but = may also have more realistic implementability. Perhaps both = approaches should be pursued, but I’d hope for at least a clearly = defined set of task-oriented requirements that is especially careful = about key generation.

An approach similar to the tool-oriented approach is an = attack-oriented approach, which has been started already in a different = thread here, by Nick M.

Best regards,

Da= niel Brown

= Research In Motion Limited =

------=_NextPart_002_004B_01CF42AC.EAFEA9C0-- ------=_NextPart_001_004A_01CF42AC.EAFEA9C0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAArALADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3qW6t 4W2yzxRn0dwKV7iGOMSPNGqN0YsADXjPxI8IXfibxi88HifSrRFjSJLaa42up75Ge9TeLfBN4fB/ h/QD4nsLeSzDSSS3c+wy59OeQKAPYY5Y5l3RSI6+qtkU+vI9GY/CHwJLqWpXw1b7VcqI0tnynOcb Sf1rpvAfxHtPHUt3DBYzWslsoZvMIIIP0oA7aivPPGfxWtPB+vLpLabPdyGISFomAxk9KydN+O+k XOpRWl7pd3ZrIwXzXIIXPqKAPWaK4vxD8Q7XQvFWk6ClnJdTaiFKSRsNqhjgZ/nXaUAFFFFABRRX GWXxBgv/AIhXHhOCxlLQAl7ncNnAz0/SgDs6Kiup1tbSa4f7sSM5+gGa8gHx/sn3GPQLx1B+8GFA HslFcV4I+JeleNpZbaCKW1vI13GGUglh6giu1oAKKKKACiiigAooooA8W174Jahr/iu91abWYI47 q4MuBEdyL6A034heB7PX9bs4pfFOnWn2C0S1WG5OX47n3Ne115F4l+C03iTxLd6vNrpi+0uGKCLO 0DoPyoGU/Et1o/w38JaHoGo6emvrIXlBkfaqkY5A9OeK7H4Yaro2teH5LzSNFXSh5mySMc7j6g9x WzL4M0G8tLODUNNgvjaxCKN7hNzACtW00+102yFrYW8VtCoOxI1wBQI+cNZ8SiH4x3+srp7anFbS FEhUZ6ADP55pdQ1h/ip4t0vTYrC00gI3O/Cs3PI9zxwKl8MeIG+HXirXjrGj3U91PKQuIzwNxOQf fIqxp76n8R/ijZ6vZ6S1jb2zIzuUIAC9ycDJPSgZsWMK6z+0CsK5e10uEIhPbYgx+tT/ABAuvEWo eJ3srvxDZaBoyEiM/aPncf3io5z7Vh+CtafRPiV4ghvLS6bU9RleG1IjzscscE56L05rntDvtF07 WdUfxnpF/qWomU+VGwJBbJ+8PfjmgDf8CeI7zQvH66ZB4gl1bR/Kd5ZWBwQqkkgEk8VNBL4v+Lmu Xz2Wovp+kwMVTa5VQO3Tkk1V+GmlDxD4w190shYL9hlWGEIVWPflcc+maTwR42uPhi2o6Hq2lzuv mFl2rg7hx+IPFAHReC7jxt4R8YPo+tRXd5pG1t1wRuRAASGDfhXFeHvHMXhzXfEeteWbjUbtmSyB HyqSx5J9MYrsrLx54u1zw94i1a/t4rfRYrdkhRYCHZm+UKD3wD1rmtH+Gg1H4T3GvIkp1QHzIVOR +7XqMdyeaANubQte03wLq3inxPqly19PFm2tPNIVS3dh647Vzngzx6PB3h6W2bw39s82Qv8AaHUb c4x6dK6DVNT1Lxn8Dkjgile+02dFu02ncyKCN2O/b8qjtfira6f4Mh0O18OTSzLbeQTJGdpYjBPT nmgCv4GkXRrPXPiLO9tvVXigs4T0dz0I7dKzbSXU/GMc2sar48tdMuC58m2knKnjtgEbR+danhrw Hrdx8L/EMr28kU16yTW9uy4LBMngds5/Sub0y+8G2uiGDWPDl/LrUeVAViqOe2e4oA9E+G3xGvjo muw61OLttIhMyT5z5ijIxnv04+tYeiw+L/HS3Pi271x7PTbaUuI1YgMqHJQAflz61VurRNN+FWoa nBob6ZcanLHBFGXZ2kjB5OMcV192G8N/s9rEkbJc3FsBtC8h3OTx9KAMDQovGHxU1K41NdYfT9Jg m2pGpI4/ugD271e+FPiWfTV8V/21fSyRaf8AODM5OACw7+vFdp8IdMbTfh3YCRNksxaVwR6nj9K8 U8R6PqFz8UNW8O6c7gX12FZVPBXg5P05oA9E+Fv9seLPEmo+LNRubhbESMtrb7zsyfbuAOK9irO0 HRrbw/olrpdooEVugXOPvHuT7k1o0CCiiigAooooAhms7a4YNNbxSMOhdAafFDFAmyGNI1/uouBT 6KAKzafZvdi6a0gNwOkpjG4fj1psml6fNci5lsrd5wc+Y0QLfnVuigCGO1t4pWljgjSRvvMqAE/j UVzplheuHurK3ncDAaSMMR+dW6KAIfstv9nFv5EfkjgR7Bt/KnpDHFEIo41WMDAVRgflT6KAIYbW 3t93kwRx7vvbEAz9ajGm2IYMLO3DA5B8sVaooAKpSaRps05nl0+1eUnJdolJz9cVdooAiltoJ0CT QxyKvQOoIFElvBLEIpIY3jHRWUEflUtFAFDVJriw0e4k060E1xHGfJgXgM3YfSvPPhb4J1PTtQ1D xH4khK6tdSEIrNuKKepz78D8K9SooAKKKKAP/9k= ------=_NextPart_001_004A_01CF42AC.EAFEA9C0-- ------=_NextPart_000_0049_01CF42AC.EAFD2320 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE4 MTcyMTA2WjAjBgkqhkiG9w0BCQQxFgQUJKX5kPLVUZASLhupkAZJBG/qOJEwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgC8SWVadiy55 ZOgQ/WM9t++cIMvEIwOdsDQGDJsVeIIrQnjwrlzsKnq1O1P5I5OjpMqemUSF6zGAp3z9RrQtXEaL WIKtaDxl4LkJJw0ethSB08T6fYliCF6ewg+DnGFQcnGnzpqL2HBxvlQgligtRH7yGcU3swx/hl/m AkzIwLlqAAAAAAAA ------=_NextPart_000_0049_01CF42AC.EAFD2320-- From nobody Tue Mar 18 13:57:38 2014 Return-Path: X-Original-To: dsfjdssdfsd@ietfa.amsl.com Delivered-To: dsfjdssdfsd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62C91A0427 for ; Tue, 18 Mar 2014 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 KzZCdjvvWbj8 for ; Tue, 18 Mar 2014 13:57:35 -0700 (PDT) Received: from nk11p00mm-asmtp001.mac.com (nk11p00mm-asmtp001.mac.com [17.158.161.0]) by ietfa.amsl.com (Postfix) with ESMTP id 76A3E1A0125 for ; Tue, 18 Mar 2014 13:57:34 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from [192.168.1.134] (c-66-31-43-48.hsd1.ma.comcast.net [66.31.43.48]) by nk11p00mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2N00HCUGVO8V60@nk11p00mm-asmtp001.mac.com> for dsfjdssdfsd@ietf.org; Tue, 18 Mar 2014 20:57:26 +0000 (GMT) From: Arnold Reinhold In-reply-to: <20140318023932.GA7144@thunk.org> Date: Tue, 18 Mar 2014 16:57:25 -0400 Content-transfer-encoding: quoted-printable Message-id: <642B9BBD-A39E-4842-AE84-FEB71545F631@me.com> References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org> <56491888.20140315165037@gmail.com> <20140316171716.GD31988@thunk.org> <20140318023932.GA7144@thunk.org> To: tytso@mit.edu X-Mailer: Apple Mail (2.1874) x-icloud-spam-score: 34444444 f=me.com; e=me.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXREEbG1oaGkdHB0lGUkdDRl5PWBoaGBEKTEMXGx0EGx8SBBscHwQdHhAbHho fGhEKWE0XSxEKbX4XGhEKTFkXGxobGxEKWUkXEQpZXhdoY3kRCkNOF0sbHhpiTk0ZBBtCQxl4c wcYYxgaHx17ExEKWFwXGQQaBB0HTUsdEkhJHEwFGx0EGx8SBBscHwQdHhAbHhofGxEKXlkXYXJ GTHgRCkxGF2xraxEKQ1oXHBwEGRsEHhkEHhIRCkRYFxkRCkRJFxgRCkJGF2x9TER+fWUTaV4TE QpCRRd6f314WmxMXkNiQBEKQk4XbHBgeUAdYlJpGmIRCkJMF21oe2BOY0UFBWFoEQpCbBdnfnB FRFl6SEF9HBEKQkAXZGZdZm5LfkscWV4RCnBoF2FwGl15YnNlGXxGEQpwaBdpRW9DAUYfSH4eR REKcGgXbERbY2xjXRNrGmMRCnBoF2BHZWB4fEsSZl5JEQpwaBdjbWgSRUNHQnxJZREKcGwXbn9 kQ21zfkQebhMR Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/b4I2jC7LMIg0R_Y3SF9IIwTcTfs Cc: dsfjdssdfsd@ietf.org, =?windows-1252?Q?=22Kriszti=E1n_Pint=E9r_=40thunk=2Eorg=22?= Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets 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, 18 Mar 2014 20:57:37 -0000 On Mar 17, 2014, at 10:39 PM, tytso@mit.edu wrote: > On Mon, Mar 17, 2014 at 08:43:36PM -0400, Arnold Reinhold wrote: >> 2. The personal privacy threat model, which fears the mass >> surveillance society, doesn=92t trust corporate vendors and = certifying >> bodies, and considers state actors principal threats. I=92d put >> Bitcoin and the like here. >=20 > ... and this also needs to separated into the "proof against a > targetted attack" and "protect against mass surveillance". >=20 > There's a big difference between NSA or FBI cutting a deal with AT&T > so that they get to put an Carnivore style keyword monitoring device > in a telephone closet at a fiber exchange point, and the FBI deciding > to park a Tempest van outside of your house. >=20 > Cheers, >=20 > - Ted What used to require a Tempest van, today probably fits in a briefcase = or even a shirt pocket. And the hardware, in terms of of wide band = digitizing and signal processing is now widely available and = inexpensive.=20 The targeted attack vs mass surveillance/war = driving/bang-on-every-exposed-port model should be another dimension to = the threat model, but the former shouldn=92t be ignored. Trillions of = dollars already flow through financial systems daily and the Internet of = Things is just getting started. There will be ever more high value = systems to attack, and increasingly sophisticated evil-doers with the = means to go after them. (My nightmare sees drug cartels wishing to = develop new revenue streams to replace market share lost to legalization = and following Sutton=92s Law in its most literal sense.) Before eliminating any capability, such as rapid recovery from PRNG = state compromise, based on a claim that the requirement is unreasonable = under the threat models being addressed, those threat models (and the = claim) should be made fully explicit and subjected to review like any = other aspect of the proposed standard. Arnold Reinhold= From nobody Fri Mar 28 13:33:27 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 4456D1A0303 for ; Fri, 28 Mar 2014 13:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 aAVzch3DUCS8 for ; Fri, 28 Mar 2014 13:33:23 -0700 (PDT) Received: from mail-yh0-f61.google.com (mail-yh0-f61.google.com [209.85.213.61]) by ietfa.amsl.com (Postfix) with ESMTP id E68D41A0177 for ; Fri, 28 Mar 2014 13:33:22 -0700 (PDT) Received: by mail-yh0-f61.google.com with SMTP id f73so1227658yha.6 for ; Fri, 28 Mar 2014 13:33:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=vOLJ2rqRWW73NoZge5tRVmSag/wuEZkhQ3TFJpEIt1s=; b=W4zqKi6oHipkjU1gJW3lNLYfE5luW9fRM065UJKCI4n+En/iDv0+X0Z8v1SkGNAJZX jeR6rUMUbgeVCNERkqwvJs6pX8HWiQne58+Kuv4Yo10QQZ2JG4z9pU23qcV2MAmzqUXj uNrmu+C6ZU2FuuD+BbHtjOjWDuHTa/2GdPEJykaQWVkAl4ufeJbH+biayvsaH1x614Pv mPI0ExxDMk8UMk9ghoLPVUTNo6ObWpCCIewVT4IACo44x5hE9PiJ+D/QlqDCpDcVgoHd F+2D0SrD2XpGoE1pzuKX6c+wiMLYpW66U4jLYvruhJjtgz4vObOFetYq7ZsHZ5e/iVWA ZNPw== X-Received: by 10.140.97.117 with SMTP id l108mr82701qge.1.1396038800606; Fri, 28 Mar 2014 13:33:20 -0700 (PDT) X-Google-Doc-Id: 19dbf5bf4fd173cf X-Google-Web-Client: true Date: Fri, 28 Mar 2014 13:33:19 -0700 (PDT) From: Arnold Reinhold To: randomness-generation@googlegroups.com Message-Id: <1cff5bc9-ef0e-4cdd-bf12-f2f10a397976@googlegroups.com> In-Reply-To: <20140318231731.12700.qmail@cr.yp.to> References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org> <56491888.20140315165037@gmail.com> <20140318231731.12700.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_983_4332624.1396038799692" X-Google-Token: EI-515kFtpzPk97PGj00 X-Google-IP: 66.31.43.48 Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/X8_va4oE5PJxrV3pf6wOavPMmdY Cc: dsfjdssdfsd@ietf.org, djb@cr.yp.to Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets 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, 28 Mar 2014 20:33:25 -0000 ------=_Part_983_4332624.1396038799692 Content-Type: multipart/alternative; boundary="----=_Part_984_5305979.1396038799692" ------=_Part_984_5305979.1396038799692 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 18, 2014 7:17:31 PM UTC-4, D. J. Bernstein wrote: > > Arnold Reinhold writes:=20 > > A determined attacker might be willing to absorb the effort and risk=20 > > to covertly penetrate physical security barriers if doing so will lead= =20 > > to a permanent compromise of a one-time-seeded PRNG=20 > > You misunderstand the argument that you're responding to.=20 > > The argument, in the case of side-channel attacks, is _not_ "Don't worry= =20 > about side-channel attacks---you aren't being targeted by those."=20 > > The argument is "When a side-channel attacker is stealing your long-term= =20 > PGP key, your long-term SSH key, your long-term SSL key, etc., what=20 > exactly do you think you're accomplishing by dribbling fresh entropy=20 > into your RNG? It's too late! You've already lost! Try paying attention= =20 > to the actual problem: go back to the system design and start applying=20 > side-channel countermeasures."=20 > > There's an extensive public literature on side-channel attacks and=20 > defenses, notably in the proceedings of the top-tier Cryptographic=20 > Hardware and Embedded Systems conference series. The attacks are much=20 > more expensive for RNGs than for long-term keys (RNG state has far less= =20 > interaction with attacker-controlled input, and each state is used only= =20 > once), and the defenses are correspondingly easier; anyone capable of=20 > protecting the long-term keys is also capable of protecting the RNG.=20 > > Similar comments apply to other "RNG state compromise" attacks. Sure,=20 > there have been security failures that allowed attackers to read the=20 > system's RNG state, but those failures also allowed attackers to read=20 > long-term keys, and that's a much worse problem. Viewing this as an RNG= =20 > issue, and trying to "recover" from it by complicating the RNG, doesn't= =20 > make any sense. What makes sense is to address the underlying security=20 > failures, protecting _all_ of the secrets stored in the system.=20 > > > We now have something we never had before, an apparently thorough=20 > > rigorous analysis of the reseeding issue.=20 > > I see no connection between "the reseeding issue" and actual security.=20 > > ---Dan=20 > I was answering what I perceived as skepticism about the Tempest attack=20 threat, but I would like to respond to your broader point.=20 A random number generator (RNG) is a component of security systems.=20 Electronic signature, symmetric and asymmetric encryption algorithms are=20 other components. The argument seems to be that component A need not be=20 resistant to attack X because critical component B is even more susceptible= =20 to X than A is. A counter position is that we should make component A as=20 resistant to X as it can safely be, with reasonable effort, and also try to= =20 improve the resistance of component B to X.=20 It=E2=80=99s at least conceivable that credentials can be made less subject= to side=20 channel attack. One might, for example, use multi-layer credentials, with= =20 the operational credentials changed regularly. Transactions would be signed= =20 and encrypted using working keys with a short lifespan. The top level=20 credential would be used very infrequently, limiting its exposure to side= =20 channels. The top level credential might also subject to further=20 protections, perhaps stored in a separate module, or encrypted after=20 signing second level credentials, perhaps using a public key of some remote= =20 station. That station might then authorize decryption for signing only when= =20 the system is under direct supervision. Such a system could recover from a= =20 compromise of its short term and intermediate term keys, perhaps in in a=20 time frame comparable to an RNG recovery or even synchronized with the RNG= =20 reseeds. It might be argued that any credential compromise is damaging, but the=20 damage from a short term compromise can be limited. A seed-only-once RNG=20 can never recover from a state compromise.=20 The context here is a proposed revision for RFC 4086 Randomness=20 Requirements for Security. If all goes smoothly the new RFC might come out= =20 in 2015 or 2016. Any new RNG recommendations it makes will take several=20 years to appear in common operating systems and crypto libraries. Secure=20 systems based on those components will then likely be in the field for a=20 decade or more. That means systems influenced by the new RFC will be=20 operating well into the 2030s. I don=E2=80=99t think we can predict all the= uses=20 for unpredictable quantities and possible attacks in that long a time=20 frame.=20 The Dodis paper suggests a sound basis for designing RNGs that recover from= =20 state compromise. It remains to be seen if flaws in their reasoning surface= =20 and if practical code based on their ideas will emerge free of intellectual= =20 property restrictions. But I think it is much too soon to rule out=20 inclusion of such a scheme in the proposed RFC. Arnold Reinhold=20 ------=_Part_984_5305979.1396038799692 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, March 18, 2014 7:17:31 PM UTC-4, D. J.= Bernstein wrote:

Arnold Reinho= ld writes:
> A determined attacker might be willing to absorb the effort and ri= sk
> to covertly penetrate physical security barriers if doing so will = lead
> to a permanent compromise of a one-time-seeded PRNG

You misunderstand the argument that you're responding to.

The argument, in the case of side-channel attacks, is _not_ "Don't worr= y
about side-channel attacks---you aren't being targeted by those."

The argument is "When a side-channel attacker is stealing your long-ter= m
PGP key, your long-term SSH key, your long-term SSL key, etc., what
exactly do you think you're accomplishing by dribbling fresh entropy
into your RNG? It's too late! You've already lost! Try paying attention
to the actual problem: go back to the system design and start applying
side-channel countermeasures."

There's an extensive public literature on side-channel attacks and
defenses, notably in the proceedings of the top-tier Cryptographic
Hardware and Embedded Systems conference series. The attacks are much
more expensive for RNGs than for long-term keys (RNG state has far less
interaction with attacker-controlled input, and each state is used only
once), and the defenses are correspondingly easier; anyone capable of
protecting the long-term keys is also capable of protecting the RNG.

Similar comments apply to other "RNG state compromise" attacks. Sure,
there have been security failures that allowed attackers to read the
system's RNG state, but those failures also allowed attackers to read
long-term keys, and that's a much worse problem. Viewing this as an RNG
issue, and trying to "recover" from it by complicating the RNG, doesn't
make any sense. What makes sense is to address the underlying security
failures, protecting _all_ of the secrets stored in the system.

> We now have something we never had before, an apparently thorough
> rigorous analysis of the reseeding issue.

I see no connection between "the reseeding issue" and actual security.

---Dan

I was answering what I perceived as skepticism about the T= empest attack threat, but I would like to respond to your broader point.&nb= sp;

A random nu= mber generator (RNG) is a component of security systems. Electronic signatu= re, symmetric and asymmetric encryption algorithms are other components. Th= e argument seems to be that component A need not be resistant to attack X b= ecause critical component B is even more susceptible to X than A is. A coun= ter position is that we should make component A as resistant to X as it can= safely be, with reasonable effort, and also try to improve the resistance = of component B to X.

It=E2=80=99s at least conceivable that credentials can be made = less subject to side channel attack. One might, for example, use mult= i-layer credentials, with the operational credentials changed regularly. Tr= ansactions would be signed and encrypted using working keys with a short li= fespan. The top level credential would be used very infrequently, limiting = its exposure to side channels. The top level credential might also subject = to further protections, perhaps stored in a separate module, or encrypted a= fter signing second level credentials, perhaps using a public key of some r= emote station. That station might then authorize decryption for signing onl= y when the system is under direct supervision. Such a system could recover = from a compromise of its short term and intermediate term keys, perhaps in = in a time frame comparable to an RNG recovery or even synchronized with the= RNG reseeds.

I= t might be argued that any credential compromise is damaging, but the damag= e from a short term compromise can be limited. A seed-only-once RNG can nev= er recover from a state compromise.

The context here is a proposed revision for RFC = 4086 Randomness Requirements for Security. If all goes smoothly the ne= w RFC might come out in 2015 or 2016. Any new RNG recommendations it makes = will take several years to appear in common operating systems and crypto li= braries. Secure systems based on those components will then likely be in th= e field for a decade or more. That means systems influenced by the new RFC = will be operating well into the 2030s. I don=E2=80=99t think we can predict= all the uses for unpredictable quantities and possible attacks in that lon= g a time frame.

The Dodis paper suggests a sound basis for designing RNGs that recov= er from state compromise. It remains to be seen if flaws in their reasoning= surface and if practical code based on their ideas will emerge free of int= ellectual property restrictions. But I think it is much too soon to rule ou= t inclusion of such a scheme in the proposed RFC.

Arnold Reinhold

------=_Part_984_5305979.1396038799692-- ------=_Part_983_4332624.1396038799692--