September 2013 - cypherpunks - lists.cpunks.org

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

09 Sep '13

----- Forwarded message from coderman <coderman(a)gmail.com> ----- Date: Sun, 8 Sep 2013 22:35:02 -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] urandom vs random On Sun, Sep 8, 2013 at 9:57 PM, David Johnston <dj(a)deadhat.com> wrote: > ... > 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. this is a good analogy :) > ... The natural size for the state > shrinks to the block size of the crypto function being used for entropy > extraction for best effective performance, it seems memory bus(es) constrains the optimal transmission unit size. 4k extended instructions providing more throughput than repeated instructions at 512bit chunks. the worst case scenarios, you're passing entropy directly into AES native instructions, and/or onward to PCIe lanes... > 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) you keep coming back to this assumption that RDRAND is entirely trusted and always available. consider adding additional entropy sources like USB keys, scavengers like Dakarand or Haveged, and so forth. conversely to your argument, there is no harm in aggressively mixing a large pool with a high rate hardware entropy source. if you are one of the worst case scenarios, like seeding an entire new volume for full disk encryption with entropy, then you can manage accordingly and cut out the OS level, kernel pool middle man, system call boundary, and other overhead accordingly. > A consequence of Linux having a big pool is that the stirring algorithm is > expensive because it has to operate over a many bits. but not effectively expensive! again, i find very few the situations in which my modern processor is unable to keep a properly refilled aggressively reseeded /dev/random up to any demanded rate of consumption for high speed network services, common client side uses, most key generation, and so forth. if you are one of the worst case scenarios, like seeding an entire new volume for full disk encryption with entropy, then you can manage accordingly and cut out the OS level, kernel pool middle man, system call boundary, and other overhead > 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. fair enough, but consider the inverse, particularly for a skeptical audience knowing what we do now: why not mix aggressively with multiple sources if you have the CPU budget? why not provide access to the raw, un-mixed, un-encrypted, un-whitened, un-obfuscated state of the raw entropy bits for those so inclined to use it in such a manner? efforts to drive RDRAND into direct use instead of the kernel entropy pool in the linux kernel, efforts to steadfast refuse access to the raw entropy stream, are thus viewed with elements of suspicion and provide an air of lack of credibility. even with all of these concerns, i have publicly said and will continue to assert, using RDRAND is better than nothing. the current state of entropy on most operating systems and especially virtual machine environments on these operating systems, is very poor. it is just a shame this resource cannot be used to greater utility and confidence, as would be provided, were raw access be available. best regards, _______________________________________________ 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

[liberationtech] Pew: Anonymity, Privacy, and Security Online
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Collin Anderson <collin(a)averysmallbird.com> ----- Date: Mon, 9 Sep 2013 01:24:15 -0400 From: Collin Anderson <collin(a)averysmallbird.com> To: "liberationtech(a)lists.stanford.edu" <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] Pew: Anonymity, Privacy, and Security Online Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> This was linked to in the FP piece on Alexander, and should hopefully be of interest to many here in privacy and CFAA work (14% have used VPNs, Tor, etc). - Collin --- http://pewinternet.org/Reports/2013/Anonymity-online/Summary-of-Findings.as… Most internet users would like to be anonymous online at least occasionally, but many think it is not possible to be completely anonymous online. New findings in a national survey show: - 86% of internet users have taken steps online to remove or mask their digital footprints—ranging from clearing cookies to encrypting their email, from avoiding using their name to using virtual networks that mask their internet protocol (IP) address. - 55% of internet users have taken steps to avoid observation by specific people, organizations, or the government - Still, 59% of internet users do not believe it is possible to be completely anonymous online, while 37% of them believe it is possible. A section of the survey looking at various security-related issues finds that notable numbers of internet users say they have experienced problems because others stole their personal information or otherwise took advantage of their visibility online—including hijacked email and social media accounts, stolen information such as Social Security numbers or credit card information, stalking or harassment, loss of reputation, or victimization by scammers. - 21% of internet users have had an email or social networking account compromised or taken over by someone else without permission. - 13% of internet users have experienced trouble in a relationship between them and a family member or a friend because of something the user posted online. - 12% of internet users have been stalked or harassed online. - 11% of internet users have had important personal information stolen such as their Social Security Number, credit card, or bank account information. - 6% of internet users have been the victim of an online scam and lost money. - 6% of internet users have had their reputation damaged because of something that happened online. - 4% of internet users have been led into physical danger because of something that happened online. - 1% of internet users have lost a job opportunity or educational opportunity because of something they posted online or someone posted about them. Some 68% of internet users believe current laws are not good enough in protecting people’s privacy online and 24% believe current laws provide reasonable protections. Most internet users know that key pieces of personal information about them are available online—such as photos and videos of them, their email addresses, birth dates, phone numbers, home addresses, and the groups to which they belong. And growing numbers of internet users (50%) say they are worried about the amount of personal information about them that is online—a figure that has jumped from 33% who expressed such worry in 2009. People would like control over their information, saying in many cases it is very important to them that only they or the people they authorize should be given access to such things as the content of their emails, the people to whom they are sending emails, the place where they are when they are online, and the content of the files they download. -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. -- 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: [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