- cypherpunks - lists.cpunks.org

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from coderman <coderman(a)gmail.com> ----- Date: Sun, 8 Sep 2013 22:05:33 -0700 From: coderman <coderman(a)gmail.com> To: David Johnston <dj(a)deadhat.com> Cc: Discussion of cryptography and related <cryptography(a)randombit.net> Subject: Re: [cryptography] [liberationtech] Random number generation being influenced - rumors On Sun, Sep 8, 2013 at 9:26 PM, David Johnston <dj(a)deadhat.com> wrote: > ... > #1) Maintaining a strong security boundary. > ... > #2) FIPS compliance. > ... > #3) Robust engineering. [trust us entirely] > ... > #4) Software solutions have been a demonstrable failure. [trust us instead] none of these are compelling reasons to not release raw access to the entropy stream from hardware noise sources.* clearly you have done your homework, and the design, _if trusted_, is a good one. however, denying access to the raw sources prevents any evaluation that the entropy sources are indeed operating as designed, and prevents any mode of operation where independent entropy estimates, mixing, and host/application pool seeding is possible. and surely you, when considering the point of view of an attacker, can recognize the immense value of modes (RDRAND, RDSEED) which provide only the obfuscated output to callers of these instructions. last but not least, you take these criticisms as personal attack. i have not seen anyone attack you personally. in fact, you simply do not have the clearance nor indoctrination to be trusted with such a backdoor. as per the leaked documents, early access to these designs is used to develop backdoors, exploits, and other surreptitious access available when the product is. keeping you in the dark, and enjoying your passionate rebuttals to claims of compromise, is more effective, isn't it? _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] urandom vs random
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from David Johnston <dj(a)deadhat.com> ----- Date: Sun, 08 Sep 2013 21:57:43 -0700 From: David Johnston <dj(a)deadhat.com> To: cryptography(a)randombit.net Subject: Re: [cryptography] urandom vs random User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 8/17/2013 9:39 AM, Sandy Harris wrote: > Papers like Yarrow with respected authors argue convincingly that > systems with far smaller state can be secure. I've argued in private (and now here) that a large entropy pool is a natural response to entropy famine and uneven supply, just like a large grain depot guards against food shortages and uneven supply. If you've got lots of good quality random data available, you don't need a large state. You can just stir lots on raw data into a small state and the small state will become fully entropic. The natural size for the state shrinks to the block size of the crypto function being used for entropy extraction. Once the value is formed and fully entropic, you spit it out and start again. This is one of the things that drove the design decisions in the RdRand DRNG. With 2.5Gbps of 95% entropic data, there is no value in stirring the data into a huge pool (E.G. like Linux) so that you can live off that pool for a long time, even though the user isn't wiggling the mouse or whatever. There will be more random data along in under 300ps, so prepare another 256 bits from a few thousand raw bits and reseed. A consequence of Linux having a big pool is that the stirring algorithm is expensive because it has to operate over a many bits. So an LFSR is used because it's cheaper than a hash or MAC. An LFSR may be a good entropy extractor, but I don't know of any math that shows that to be the case. We do have that math for hashes, CBC-MACs and various GF arithmetic methods. When I count my raw data in bits per second, rather than gigabits per second, I am of course going to use them efficiently and mix up a large pot of state, so I can get maximum utility. With the RdRand DRNG, the bus is the limiting factor, not the supply or the pool size. DJ _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from David Johnston <dj(a)deadhat.com> ----- Date: Sun, 08 Sep 2013 21:26:24 -0700 From: David Johnston <dj(a)deadhat.com> To: cryptography(a)randombit.net Subject: Re: [cryptography] [liberationtech] Random number generation being influenced - rumors User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 9/7/2013 6:11 PM, James A. Donald wrote: > On 2013-09-07 9:14 PM, Eugen Leitl wrote: >> That's the claimed design, yes. I see no particular reason to believe >> that the hardware in my server implements the design. I can't even test >> that the AES whitening does what it is documented to do, because Intel >> refused to provide access to the prewhitened input. > > On chip whitening is extremely suspicious behavior. Since the need > for random numbers is low bandwidth, on chip whitening is a waste > of silicon. > > Despite repeated requests, the decision to do whitening on chip has > never been explained. > I answered this once before many months ago, the last time you asked. There is no 'whitener'. It is a CBC-MAC based entropy extractor, as per the spec in the current SP800-90B draft. You can call it a whitener, but that would risk confusing it with things like the Von Neumann or Yuval Peres whiteners, which are a different class of algorithm with different constraints. The reasons for it are: #1) Maintaining a strong security boundary. We don't want an attacker to be able to infer the seed values by exposing them to all sorts of classes of attack by letting the values get into the system state accessible by the microprocessor SW. #2) FIPS compliance. Which is more or less #1 restated. It wants stuff to happen within a well defined boundary. #3) Robust engineering. Our goal is to make the lack-of-entropy problem go away on intel based products. Reseeding the DRBG 2 million times a second is a good way of making it hard to infer the state of the DRBG. This is one of several stages of mitigation design, intended to make the DRBG robust even if a problem should arise with any one of the stages. You can't do that in software. In general, once attackers have got a foot in the door of a software system, it is game over. #4) Software solutions have been a demonstrable failure. At least this hardware solution remains robust. #5) A non-goal is making James A Donald satisfied. Sorry, but no solution compatible with security and manufacturing realities is going to satisfy the demands you have made. DJ _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from "Jeffrey I. Schiller" <jis(a)mit.edu> ----- Date: Sun, 8 Sep 2013 21:23:33 -0400 From: "Jeffrey I. Schiller" <jis(a)mit.edu> To: John Gilmore <gnu(a)toad.com> Cc: Cryptography <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mutt/1.5.21 (2010-09-15) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Sep 06, 2013 at 05:22:26PM -0700, John Gilmore wrote: > Speaking as someone who followed the IPSEC IETF standards committee > pretty closely, while leading a group that tried to implement it and > make so usable that it would be used by default throughout the > Internet, I noticed some things: > ... Speaking as one of the Security Area Directors at the time... I have to disagree with your implication that the NSA intentionally fouled the IPSEC working group. There were a lot of people working to foul it up! I also don’t believe that the folks who participated, including the folks from the NSA, were working to weaken the standard. I suspect that the effort to interfere in standards started later then the IPSEC work. If the NSA was attempting to thwart IETF security standards, I would have expected to also see bad things in the TLS working group and the PGP working group. There is no sign of their interference there. The real (or at least the first) problem with the IPSEC working group was that we had a good and simple solution, Photuris. However the document editor on the standard decided to claim it (Photuris) as his intellectual property and that others couldn’t recommend changes without his approval. This effectively made Photuris toxic in the working group and we had to move on to other solutions. This is one of the events that lead to the IETF’s “Note Well” document and clear policy on the IP associated with contributions. Then there was the ISAKMP (yes, an NSA proposal) vs. SKIP. As Security AD, I eventually had to choose between those two standards because the working group could not generate consensus. I believed strongly enough that we needed an IPSEC solution so I decided to choose (as I promised the working group I would do if they failed to!). I chose ISAKMP. I posted a message with my rationale to the IPSEC mailing list, I’m sure it is still in the archives. I believe that was in 1996 (I still have a copy somewhere in my personal archives). At no point was I contacted by the NSA or any agent of any government in an attempt to influence my decision. Folks can choose to believe this statement, or not. IPSEC in general did not have significant traction on the Internet in general. It eventually gained traction in an important niche, namely VPNs, but that evolved later. IPSEC isn’t useful unless all of the end-points that need to communicate implement it. Implementations need to be in the OS (for all practical purposes). OS vendors at the time were not particularly interested in encryption of network traffic. The folks who were interested were the browser folks. They were very interested in enabling e-commerce, and that required encryption. However they wanted the encryption layer someplace where they could be sure it existed. An encryption solution was not useful to them if it couldn’t be relied upon to be there. If the OS the user had didn’t have an IPSEC layer, they were sunk. So they needed their own layer. Thus the Netscape guys did SSL, and Microsoft did PCT and in the IETF we were able to get them to work together to create TLS. This was a *big deal*. We shortly had one deployed interoperable encryption standard usable on the web. If I was the NSA and I wanted to foul up encryption on the Internet, the TLS group is where the action was. Yet from where I sit, I didn’t see any such interference. If we believe the Edward Snowden documents, the NSA at some point started to interfere with international standards relating to encryption. But I don’t believe they were in this business in the 1990’s at the IETF. -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSLSMV8CBzV/QUlSsRAigkAKCU6erw1U7FOt7A1QdItlGbFRfo+gCfeMg1 0Woyz0FyKqKYqS+gZFQWEf0= =yWOw -----END PGP SIGNATURE----- _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Techniques for malevolent crypto hardware
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Kent Borg <kentborg(a)borg.org> ----- Date: Sun, 08 Sep 2013 20:34:55 -0400 From: Kent Borg <kentborg(a)borg.org> To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] Techniques for malevolent crypto hardware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 On 09/08/2013 06:16 PM, John Kelsey wrote: > I don't think you can do anything useful in crypto without some > good source of random bits. I don't see the big worry about how hard it is to generate random numbers unless: a) You need them super fast (because you are Google, trying to secure your very high-speed long lines), or b) You are some embedded device that is impoverished for both sources of entropy and non-volatile storage, and you need good random bits the moment you boot. On everything in between, there are sources of entropy. Collect them, hash then together and use them to feed some good cryptography. If you seem short of entropy, look for more in your hardware manual. Hash in any local unique information. Hash in everything you can find! (If the NSA knows every single bit you are hashing in, no harm, hash them in anyway, but...if the NSA has misunderestimated any one of your bits...then you scored a bit! Repeat as necessary.) I am thinking pure HW RNGs are more sinful than pure SW RNGs, because real world entropy is colored and hardware is the wrong place to fix that. So don't buy HW RNGs, buy HW entropy sources (or find them in your current HW) and feed them into a good hybrid RNG. On a modern multi-GHz CPU the exact LSB of your highspeed system counters, when the interrupt hits your service routine, has uncertainty that is quite real once the you push the NSA a few centimeters from your CPU or SoC. Just sit around until you have a few network packets and you can have some real entropy. Wait longer for more entropy. In case you did notice, I am a fan of hybrid HW/SW RNGs. -kb P.S. Entropy pools that are only saved on orderly shutdowns are risking crash-and-playback attacks. Save regularly, or something like that. P.P.S. Don't try to estimate entropy, it is a fool's errand, get as much as you can (within reason) and feed it into some good cryptography. P.P.P.S. Have an independent RNG? If it *is* independent, no harm in XORing it in. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

IETF: Security and Pervasive Monitoring
by Eugen Leitl 09 Sep '13

09 Sep '13

http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ Security and Pervasive Monitoring The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use. So the reports about large-scale monitoring of Internet traffic and users disturbs us greatly. We knew of interception of targeted individuals and other monitoring activities, but the scale of recently reported monitoring is surprising. Such scale was not envisaged during the design of many Internet protocols, but we are considering the consequence of these kinds of attacks. Of course, it is hard to know for sure from current reports what attack techniques may be in use. As such, it is not so easy to comment on the specifics from an IETF perspective. Still, the IETF has some long standing general principles that we can talk about, and we can also talk about some of the actions we are taking. In 1996, RFC 1984 articulated the view that encryption is an important tool to protect privacy of communications, and that as such it should be encouraged and available to all. In 2002, we decided that IETF standard protocols must include appropriate strong security mechanisms, and established this doctrine as a best current practice, documented in RFC 3365. Earlier, in 2000 the IETF decided not to consider requirements for wiretapping when creating and maintaining IETF standards, for reasons stated in RFC 2804. Note that IETF participants exist with positions at all points of the privacy/surveillance continuum, as seen in the discussions that lead to RFC 2804. As privacy has become increasingly important, the Internet Architecture Board (IAB) developed guidance for handling privacy considerations in protocol specifications, and documented that in RFC 6973. And there are ongoing developments in security and privacy happening within the IETF all the time, for example work has just started on version 1.3 of the Transport Layer Security (TLS, RFC 5246) protocol which aims to provide better confidentiality during the early phases of the cryptographic handshake that underlies much secure Internet traffic. Recent days have also seen an extended and welcome discussion triggered by calls for the IETF to build better protections against wide-spread monitoring. As that discussion makes clear, IETF participants want to build secure and deployable systems for all Internet users. Indeed, addressing security and new vulnerabilities has been a topic in the IETF for as long as the organisation has existed. Technology alone is, however, not the only factor. Operational practices, laws, and other similar factors also matter. First of all, existing IETF security technologies, if used more widely, can definitely help. But technical issues outside the IETF’s control, for example endpoint security, or the properties of specific products or implementations also affect the end result in major ways. So at the end of the day, no amount of communication security helps you if you do not trust the party you are communicating with or the devices you are using. Nonetheless, we’re confident the IETF can and will do more to make our protocols work more securely and offer better privacy features that can be used by implementations of all kinds. So with the understanding of limitations of technology-only solutions, the IETF is continuing its mission to improve security in the Internet. The recent revelations provide additional motivation for doing this, as well as highlighting the need to consider new threat models. We should seize this opportunity to take a hard look at what we can do better. Again, it is important to understand the limitations of technology alone. But here are some examples of things that are already ongoing: We’re having a discussion as part of the development of HTTP/2.0 as to how to make more and better use of TLS, for example to perhaps enable clients to require the use of security and not just have to react to the HTTP or HTTPS URLs chosen by servers. We’re having discussions as to how to handle the potentially new threat model demonstrated by the recent revelations so that future protocol designs can take into account potential pervasive monitoring as a known threat model. We’re considering ways in which better use can be made of existing protocol features, for example, better guidance as to how to deploy TLS with Perfect Forward Secrecy, which makes applications running over TLS more robust if server private keys later leak out. We’re constantly updating specifications to deprecate older, weaker cryptographic algorithms and allocate code points for currently strong algorithm choices so those can be used with Internet protocols. And we are confident that discussions on this topic will motivate IETF participants to do more work on these and further related topics. But don’t think about all this just in terms of the recent revelations. The security and privacy of the Internet in general is still a challenge even ignoring pervasive monitoring, and if there are improvements from the above, those will be generally useful for many reasons and for many years to come. Perhaps this year’s discussions is a way to motivate the world to move from “by default insecure” communications to “by default secure”. Publicity and motivation are important, too. There is plenty to do for all of us, from users enabling additional security tools to implementors ensuring that their products are secure. In the Vancouver IETF meeting, there will be time dedicated to discuss this, and we ask that those interested in working on this topic contribute to the analysis and develop proposals in this area. Those contributions are very welcome and can start now and continue in Vancouver and beyond. Relevant mailing lists (from most specific to most general) include: The perpass mailing list (perpass(a)ietf.org) recently set up to consider how the IETF ought react to pervasive monitoring The ietf security area mailing list (saag(a)ietf.org) for general security topics The ietf main mailing list (ietf(a)ietf.org) for general discussion Jari Arkko, Chair of the IETF and Stephen Farrell, IETF Security Area Director This entry was posted in IETF on 2013/09/07.

1 0

Re: [liberationtech] Random number generation being influenced - rumors
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from coderman <coderman(a)gmail.com> ----- Date: Sun, 8 Sep 2013 16:44:43 -0700 From: coderman <coderman(a)gmail.com> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Random number generation being influenced - rumors Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Sat, Sep 7, 2013 at 10:26 AM, Eugen Leitl <eugen(a)leitl.org> wrote: > ... > There is a hardware RNG in the AMD Geode LX. I tried very hard to > find any documentation, but found effectively nothing. > > Am I that bad at searching, or this really a black box? the only decent on-die RNG i have used was XSTORE[0] from VIA Padlock which allowed you very high speed access to the raw, unwhitened output of the hardware RNG sourece(s). you could read from both at twice the rate for maximum throughput. it was then up to a user-space daemon to read this raw source and perform cursory and long-lived checks, even benchmarks against large volumes of TBytes of output for extended confirmation (looking at you DIEHARDER). the user-space daemon, having then verified the hardware entropy sources, performs computation blinding and compression (e.g. hashing or bocl ciphering) and mixes this obfuscated entropy with the kernel entropy pool via write to /dev/random. RDRAND/RDSEED can not be used a trusted manner with access to the unwhitened, raw output. the AMD768 RNG has not produced a detailed design like XSTORE and cryopgraphy research, nor does it support the raw mode like needed, always reading some "4 bytes:" of randomness (IIRC). there are USB and other external sources for entropy if your CPU does not support it, of course. these are useful to augment any userspace entropy daemons like Havegd. 0. "Evaluation of C3 Nehemiah Random Number Generator" http://www.cryptography.com/public/pdf/VIA_rng.pdf -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [tor-talk] Many more Tor users in the past week?
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from mirimir <mirimir(a)riseup.net> ----- Date: Mon, 09 Sep 2013 07:13:33 +0000 From: mirimir <mirimir(a)riseup.net> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] Many more Tor users in the past week? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 Reply-To: tor-talk(a)lists.torproject.org This <http://blog.trendmicro.com/trendlabs-security-intelligence/the-mysterious-m…> explains the Israel anomaly, I think. > The Mysterious Mevade Malware > Published on September 5th, 2013 > Written by: Feike Hacquebord (Senior Threat Researcher) > > ... > > Yesterday, Fox-IT published evidence for this plausible explanation. > The Mevade malware family downloaded a Tor component, possibly as a > backup mechanism for its C&C communications. (We will release a > second blog post describing in more detail the behavior of the > Mevade variants we have encountered.) > > Feedback provided by the Smart Protection Network shows that the > Mevade malware was, indeed, downloading a Tor module in the last > weeks of August and early September. Tor can be used by bad actors > to hide their C&C servers, and taking down a Tor hidden service is > virtually impossible. > > The actors themselves, however, have been a bit less careful about > hiding their identities. They operate from Kharkov, Ukraine and > Israel and have been active since at least 2010. One of the main > actors is known as “Scorpion”. Another actor uses the nickname > “Dekadent”. Together, they are part of a well organized and > probably well financed cybercrime gang. > > ... -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] In the face of "cooperative" end-points, PFS doesn't help
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from james hughes <hughejp(a)mac.com> ----- Date: Sun, 08 Sep 2013 16:16:57 -0700 From: james hughes <hughejp(a)mac.com> To: "Marcus D. Leech" <mleech(a)ripnet.com> Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] In the face of "cooperative" end-points, PFS doesn't help X-Mailer: iPhone Mail (10B350) On Sep 7, 2013, at 8:16 PM, "Marcus D. Leech" <mleech(a)ripnet.com> wrote: > But it's not entirely clear to me that it will help enough in the scenarios under discussion. If we assume that mostly what NSA are doing is acquiring a site > RSA key (either through "donation" on the part of the site, or through factoring or other means), then yes, absolutely, PFS will be a significant roadblock. > If, however, they're getting session-key material (perhaps through back-doored software, rather than explicit cooperation by the target website), the > PFS does nothing to help us. And indeed, that same class of compromised site could just as well be leaking plaintext. Although leaking session > keys is lower-profile. I think we are growing closer to agreement, PFS does help, the question is how much in the face of cooperation. Let me suggest the following. With RSA, a single quiet "donation" by the site and it's done. The situation becomes totally passive and there is no possibility knowing what has been read. The system administrator could even do this without the executives knowing. With PFS there is a significantly higher profile interaction with the site. Either the session keys need to be transmitted in bulk, or the RNG cribbed. Both of these have a significantly higher profile, higher possibility of detection and increased difficulty to execute properly. Certainly a more risky think for a cooperating site to do. PFS does improve the situation even if cooperation is suspect. IMHO it is just better cryptography. Why not? It's better. It's already in the suites. All we have to do is use it... I am honestly curious about the motivation not to choose more secure modes that are already in the suites? _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Doug Barton <dougb(a)dougbarton.us> ----- Date: Sun, 08 Sep 2013 15:44:05 -0700 From: Doug Barton <dougb(a)dougbarton.us> To: nanog(a)nanog.org Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 On 09/08/2013 02:25 AM, Eugen Leitl wrote: > ----- Forwarded message from Gregory Perry <Gregory.Perry(a)govirtual.tv> ----- > > Date: Sat, 7 Sep 2013 21:14:47 +0000 > From: Gregory Perry <Gregory.Perry(a)govirtual.tv> > To: Phillip Hallam-Baker <hallam(a)gmail.com> > Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com>, ianG <iang(a)iang.org> > Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" > > On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote: > > Good theory only the CA industry tried very hard to deploy and was prevented from doing so because Randy Bush abused his position as DNSEXT chair to prevent modification of the spec to meet the deployment requirements in .com. > > DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF followed the clear consensus of the DNSEXT working group and approved the OPT-IN proposal. The code was written and ready to deploy. > > I told the IESG and the IAB that the VeriSign position was no bluff and that if OPT-IN did not get approved there would be no deployment in .com. A business is not going to spend $100million on deployment of a feature that has no proven market demand when the same job can be done for $5 million with only minor changes. I was also there in 2003, and for a long time before that, and was also one of the voices that was saying that we needed opt-in, and protection from zone walking, or else the thing wouldn't fly. I don't recall that any 1 person was the reason those things didn't happen sooner than they did; in fact I recall near-universal sentiment that zone walking was a non-issue, and that opt-in defeated the very nature of what DNSSEC was trying to accomplish. Fast forward to my time at IANA in 2004 and after considerable behind the scenes organization a coalition of TLD registries came forward and said that they would not deploy DNSSEC without those 2 features, and were willing to dedicate the resources to create them. So it was not 1 person who stopped DNSSEC deployment, and it wasn't 1 person who made it happen. Your larger point about fiefdoms and oligarchies in the IETF is, however, tragically accurate. The blindness of the DNSSEC literati to the real-world needs was a huge part of what caused the delay in deployment on the authoritative side, and the malaise caused by the decade+ of fighting to get it out the door is a big contributor to what's preventing any real solution to the last mile problem (which is what it takes to make DNSSEC really useful). Doug ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0