- cypherpunks - lists.cpunks.org

Re: [tor-talk] NIST approved crypto in Tor?
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Gregory Maxwell <gmaxwell(a)gmail.com> ----- Date: Sun, 8 Sep 2013 06:44:57 -0700 From: Gregory Maxwell <gmaxwell(a)gmail.com> To: "This mailing list is for all discussion about theory, design, and development of Onion Routing." <tor-talk(a)lists.torproject.org> Subject: Re: [tor-talk] NIST approved crypto in Tor? Reply-To: tor-talk(a)lists.torproject.org On Sat, Sep 7, 2013 at 8:09 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote: > On Sat, Sep 7, 2013 at 4:08 PM, anonymous coward > <anonymous.coward(a)posteo.de> wrote: >> Bruce Schneier recommends *not* to use ECC. It is safe to assume he >> knows what he says. > > I believe Schneier was being careless there. The ECC parameter sets > commonly used on the internet (the NIST P-xxxr ones) were chosen using > a published deterministically randomized procedure. I think the > notion that these parameters could have been maliciously selected is a > remarkable claim which demands remarkable evidence. Okay, I need to eat my words here. I went to review the deterministic procedure because I wanted to see if I could repoduce the SECP256k1 curve we use in Bitcoin. They don't give a procedure for the Koblitz curves, but they have far less design freedom than the non-koblitz so I thought perhaps I'd stumble into it with the "most obvious" procedure. The deterministic procedure basically computes SHA1 on some seed and uses it to assign the parameters then checks the curve order, etc.. wash rinse repeat. Then I looked at the random seed values for the P-xxxr curves. For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90. _No_ justification is given for that value. The stated purpose of the "veritably random" procedure "ensures that the parameters cannot be predetermined. The parameters are therefore extremely unlikely to be susceptible to future special-purpose attacks, and no trapdoors can have been placed in the parameters during their generation". Considering the stated purpose I would have expected the seed to be some small value like ... "6F" and for all smaller values to fail the test. Anything else would have suggested that they tested a large number of values, and thus the parameters could embody any undisclosed mathematical characteristic whos rareness is only bounded by how many times they could run sha1 and test. I now personally consider this to be smoking evidence that the parameters are cooked. Maybe they were only cooked in ways that make them stronger? Maybe???? SECG also makes a somewhat curious remark: "The elliptic curve domain parameters over (primes) supplied at each security level typically consist of examples of two different types of parameters — one type being parameters associated with a Koblitz curve and the other type being parameters chosen verifiably at random — although only verifiably random parameters are supplied at export strength and at extremely high strength." The fact that only "verifiably random" are given for export strength would seem to make more sense if you cynically read "verifiably random" as backdoored to all heck. (though it could be more innocently explained that the performance improvements of Koblitz wasn't so important there, and/or they considered those curves weak enough to not bother with the extra effort required to produce the Koblitz curves). -- 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] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from "Jeffrey I. Schiller" <jis(a)mit.edu> ----- Date: Sat, 7 Sep 2013 19:52:44 -0400 From: "Jeffrey I. Schiller" <jis(a)mit.edu> To: Gregory Perry <Gregory.Perry(a)govirtual.tv> Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com>, Phillip Hallam-Baker <hallam(a)gmail.com>, ianG <iang(a)iang.org> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mutt/1.5.21 (2010-09-15) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Sep 07, 2013 at 09:14:47PM +0000, Gregory Perry wrote: > And this is exactly why there is no real security on the Internet. > Because the IETF and standards committees and working groups are all > in reality political fiefdoms and technological monopolies aimed at > lining the pockets of a select few companies deemed "worthy" of > authenticating user documentation for purposes of establishing > online credibility. > ... > Encrypting IPv6 was initially a mandatory part of the spec, > but then it somehow became discretionary. The nuts and bolts of > strong crypto have been around for decades, but the IETF and related > standards "powers to be" are more interested in creating a global > police state than guaranteeing some semblance of confidential and > privacy for Internet users. I’m sorry, but I cannot let this go unchallenged. I was there, I saw it. For those who don’t know, I was the IESG Security Area Director from 1994 - 2003. (by myself until 1998 after which we had two co-AD’s in the Security Area). During this timeframe we formed the TLS working group, the PGP working group and IPv6 became a Draft Standard. Scott Bradner and I decided that security should be mandatory in IPv6, in the hope that we could drive more adoption. The IETF was (and probably still is) a bunch of hard working individuals who strive to create useful technology for the Internet. In particular IETF contributors are in theory individual contributors and not representatives of their employers. Of course this is the theory and practice is a bit “noisier” but the bulk of participant I worked with were honest hard working individuals. Security fails on the Internet for three important reasons, that have nothing to do with the IETF or the technology per-se (except for point 3). 1. There is little market for “the good stuff”. When people see that they have to provide a password to login, they figure they are safe... In general the consuming public cannot tell the difference between “good stuff” and snake oil. So when presented with a $100 “good” solution or a $10 bunch of snake oil, guess what gets bought. 2. Security is *hard*, it is a negative deliverable. You do not know when you have it, you only know when you have lost it (via compromise). It is therefore hard to show return on investment with security. It is hard to assign a value to something not happening. 2a. Most people don’t really care until they have been personally bitten. A lot of people only purchase a burglar alarm after they have been burglarized. Although people are more security aware today, that is a relatively recent development. 3. As engineers we have totally and completely failed to deliver products that people can use. I point out e-mail encryption as a key example. With today’s solutions you need to understand PK and PKI at some level in order to use it. That is likely requiring a driver to understand the internal combustion engine before they can drive their car. The real world doesn’t work that way. No government conspiracy required. We have seen the enemy and it is... -Jeff _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room E17-110A, 32-392 Cambridge, MA 02139-4307 617.910.0259 - Voice jis(a)mit.edu http://jis.qyv.name _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSK7xM8CBzV/QUlSsRApyUAKCB6GpP/hUHxtOQNGjSB5FDZS8hFACfVec6 pPw4Xvukq3OqPEkmVZKl0c8= =9/UP -----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] Random number generation influenced, HW RNG
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from "James A. Donald" <jamesd(a)echeque.com> ----- Date: Sun, 08 Sep 2013 15:22:58 +1000 From: "James A. Donald" <jamesd(a)echeque.com> To: Thor Lancelot Simon <tls(a)panix.com> Cc: cryptography(a)randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: jamesd(a)echeque.com On 2013-09-08 1:25 PM, Thor Lancelot Simon wrote: >> Access to the raw output would have made it possible to determine >> that the random numbers were in fact generated by the physical >> process described, since it is hard and would cost a lot of silicon >> to simulate the various subtle offwhite characteristics of a well >> described actual physical process. > I am extremely skeptical of this claim. Intel shows a circuit that should in theory output near random bits. If the bits are actually coming from this circuit, we would expect to see some long term anti correlation - an unusually long stream of zeros should have a higher than random percent chance of being followed by an unusually long stream of ones, and some short term correlation - a zero should have a higher than fifty percent chance of being followed by another zero, and a lower than fifty percent chance of being followed by a one. If we don't see that, we are not getting the raw unwhitened output, or there is no hardware true randomness for us to get. Conversely, if we do see that, we can be pretty sure that the circuit exists and is producing true randomness, though of course we don't know if that true randomness is necessarily being fed into the whitener. But then we don't need to use the output of the whitener, we can feed the off white output into a software whitener. _______________________________________________ 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: [linux-elitists] Surveillance
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Mark van Walraven <mvw(a)wave.co.nz> ----- Date: Sun, 8 Sep 2013 17:09:32 +1200 From: Mark van Walraven <mvw(a)wave.co.nz> To: linux-elitists(a)zgp.org Subject: Re: [linux-elitists] Surveillance User-Agent: Mutt/1.5.21 (2010-09-15) On Sat, Sep 07, 2013 at 09:14:31PM -0700, Greg KH wrote: > But what else needs to be worked on? What gaps do people feel we have > that are cauing problems that we can solve with technological measures, > not just legal ones? How can I trust my hardware and the firmware therein? If it's so hard to check that Huawei haven't embedded snooping mechanisms in the chips and use covert channels to export the data, how can I trust Intel or AMD or Broadcom or Marvell? Covert channels can be subtle and during the cold war the intelligence agencies did some amazing work in detecting data embedded in what seemed to noise. Is there some way to crowd-source counter-espionage? Can we automate "many eyes" to detect snooping? Open hardware with quartz windows on the IC packages would be nice, but then I'd still want a way to validate that what I had was the same as what some transparent authority had declared to be a clean implementation. Difficult with commonly-available equipment, but perhaps it could be common enough to make spy(hard)ware difficult and risky to deploy. My life and work are undoubtedly painfully uninteresting to any intelligence service, but the disrespect for my privacy rankles me; I would pay significantly extra for a clean platform. Cheers, Mark. _______________________________________________ Do not Cc: anyone else on mail sent to this list. The list server is set for maximum one recipient. linux-elitists mailing list linux-elitists(a)zgp.org http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists ----- 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: [linux-elitists] Surveillance
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Marc MERLIN <marc(a)merlins.org> ----- Date: Sat, 7 Sep 2013 22:03:01 -0700 From: Marc MERLIN <marc(a)merlins.org> To: linux-elitists(a)zgp.org Subject: Re: [linux-elitists] Surveillance X-Mailer: Some Outlooks can't quote properly without this header User-Agent: Mutt/1.5.13 (2006-08-11) On Sat, Sep 07, 2013 at 08:00:04PM -0700, Seth David Schoen wrote: > Marc MERLIN writes: > > > On Sat, Sep 07, 2013 at 06:59:48PM -0700, Don Marti wrote: > > > > > Can you build on localhost and have it come out > > > identical to what comes down from the build farm? > > > > Yes. > > Do you think you could help distributors help other users achieve the > same result? That's awesome. There is no magic involved, it's just time consuming and virtually no companies have staff they are willing to spend on it. Also, that's a server distribution with fewer than 200 packages. My laptop: gandalfthegreat:~$ dpkg --list | wc -l 3061 server #1: magic:~$ dpkg --list | wc -l 1195 server #2: gargamel:~# dpkg --list | wc -l 2685 You get the point, it's time consuming, especially if you're checking / stripping each package first, including fixing parts that make the package non invariant on rebuilds. We also had a package diff-er that accounted for zipped man pages, pyc files, and other files that changed each time you rebuilt them. But really, not rocket science. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ _______________________________________________ Do not Cc: anyone else on mail sent to this list. The list server is set for maximum one recipient. linux-elitists mailing list linux-elitists(a)zgp.org http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists ----- 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

[Cryptography] Speaking of EDH (GnuTLS interoperability)
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Viktor Dukhovni <cryptography(a)dukhovni.org> ----- Date: Sun, 8 Sep 2013 04:31:28 +0000 From: Viktor Dukhovni <cryptography(a)dukhovni.org> To: cryptography(a)metzdowd.com Subject: [Cryptography] Speaking of EDH (GnuTLS interoperability) User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: cryptography(a)metzdowd.com Some of you may have seen my posts to postfix-users and openssl-users, if so, apologies for the duplication. http://archives.neohapsis.com/archives/postfix/2013-09/thread.html#80 http://www.mail-archive.com/openssl-users@openssl.org/index.html#71903 The short version is that while everyone is busily implementing EDH, they may run into some interoperability issues. GnuTLS clients by default insist on a minimum EDH prime size that is not generally interoperable (2432 bits). Since the TLS protocol only negotiates the use of EDH, but not the prime size (the EDH parameters are unilaterally announced by the server), this setting, while cryptographically sound, is rather poor engineering. The context in which this was discovered is also "amusing". Exim uses GnuTLS and has a work-around to drop the DH prime floor to 1024-bits, which is interoperable in practice. Debian however wanted to "improve" Exim to make it more secure, so the floor was raised to 2048-bits in a Debian patch. As a result STARTTLS from Debian's Exim (before sanity was restored in Exim 4.80-3 in Debian wheezy, AFAIK it is still broken in Debian squeeze) fails with Postfix, Sendmail, and other SMTP servers. In all probability this "stronger" version of Exim then needlessly sends mail without TLS, since with SMTP TLS is typically opportunistic, and likely after TLS fails delivery is retried in the clear! -- Viktor. P.S. shameless off-topic plug: If you want better than opportunistic TLS for email, consider adopting DNSSEC for your domains and publishing TLSA RRs for your SMTP servers. Postfix supports DANE as of 2.11-20130825. See https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 http://www.postfix.org/TLS_README.html#client_tls_dane Make sure to publish either "IN TLSA 3 1 1" or "IN TLSA 2 1 1" certificate associations. _______________________________________________ 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] Why prefer symmetric crypto over public key crypto?
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Tony Arcieri <bascule(a)gmail.com> ----- Date: Sat, 7 Sep 2013 15:40:08 -0700 From: Tony Arcieri <bascule(a)gmail.com> To: Ray Dillinger <bear(a)sonic.net> Cc: Crypto <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Why prefer symmetric crypto over public key crypto? On Sat, Sep 7, 2013 at 1:01 PM, Ray Dillinger <bear(a)sonic.net> wrote: > And IIRC, pretty much every asymmetric ciphersuite (including all public- > key crypto) is vulnerable to some transformation of Shor's algorithm that > is in fact practical to implement on such a machine. Lattice-based (NTRU) or code-based (McEliece/McBits) public key systems are still considered "post-quantum" algorithms. There are no presently known quantum algorithms that work against these sorts of systems. See http://pqcrypto.org/ -- Tony Arcieri _______________________________________________ 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] Bruce Schneier has gotten seriously spooked
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Gregory Perry <Gregory.Perry(a)govirtual.tv> ----- Date: Sat, 7 Sep 2013 19:58:50 +0000 From: Gregory Perry <Gregory.Perry(a)govirtual.tv> To: Brian Gladman <brg(a)gladman.plus.com> Cc: Cryptography Mailing List <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Bruce Schneier has gotten seriously spooked On 09/07/2013 02:46 PM, Brian Gladman wrote: > Because NSA and GCHQ are much more interested in attacking communictions > in transit rather than attacking endpoints. > > Endpoint attacks cost more to undertake, only give access to a limited > amount of data and involve much greater risks that their attack will > either be discovered or their means of attack will leave evidence of > what they have done and how they have done it. The internal bueaucratic > costs of gaining approval for (adverarial) endpoint attacks also makes > it a more costly process than the use of network based interception. > > There is significant use of open source encryption software in end to > end encryption solutions, in file archivers, in wifi and network > routers, and in protecing the communications used to manage and control > such components when at remote locations. The open source software is > provided in source code form and is compiled from source in a huge > number of applications and this means that the ability to covertly > substitute broken source code could provide access to a huge amount of > traffic without the risks involved in endpoint attacks. I would submit that the exact inverse is the real target - endpoint devices. There is simply too much volume of Internet traffic to realistically analyze and process, even with the next big datacenter in Utah and multi gigabit wire rate capable deep content inspection blades. It's the endpoint devices that the FBI is after for targeted intrusions (for both domestic and foreign targets), and the NSA used to have a very legitimate charter with a culture dedicated to protecting U.S. communications at all costs. For decades the FBI were literally the spies that couldn't shoot straight, as was evidenced by CALEA (lets put backdoors into every phone switch), and Comverse Infosys (then lets outsource all of our wiretap operations). But even with all of those idiotic mistakes, the FBI got their amended FISA 2008 and the Patriot Acts passed which in effect repealed the Posse Comitatus Act and gave the FBI their political power play to gain control over all of the NSA's signals intelligence capabilities, for domestic spying and wiretapping here on U.S. soil without any judicial oversight whatsoever. I would even wager that Herr Bob Mueller himself arranged this Snowden debacle with the Crown of England and his Chinese and Russian counterparts, to guarantee Snowden safe asylum once he absconded with the NSA crown jewels. A simple reading of the international media chatter shows that the NSA (and the USA by proxy) are the bad guys now, with nary a mention of the FBI being involved at any level of this with their own domestic spying operation that is many orders of magnitude more powerful than anything the NSA and/or DoD had ever even dreamed of accomplishing with foreign signals intelligence gathering. _______________________________________________ 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] Why prefer symmetric crypto over public key crypto?
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Bill Stewart <bill.stewart(a)pobox.com> ----- Date: Sat, 07 Sep 2013 11:07:39 -0700 From: Bill Stewart <bill.stewart(a)pobox.com> To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] Why prefer symmetric crypto over public key crypto? X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 > On 7/09/13 09:05 AM, Jaap-Henk Hoepman wrote: >>> Public-key cryptography is less well-understood than >>> symmetric-key cryptography. It is also tetchier than >>> symmetric-key crypto, and if you pay attention to us talking >>> about issues with nonces, counters, IVs, chaining modes, and >>> all that, you see that saying that it's tetchier than that is a >>> warning indeed. >> >> You have the same issues with nonces, counters, etc. with >> symmetric crypto so I don't see how that makes it preferable over >> public key crypto. At 12:57 AM 9/7/2013, ianG wrote: > It's a big picture thing. At the end of the day, symmetric crypto > is something that good software engineers can master, and > relatively well, in a black box sense. Public key crypto not so > easily, that requires real learning. I for one am terrified of it. Public-key crypto requires learning math, and math is hard (or at least ECC math is hard, and even prime-number-group math has some interesting tricks in it.) Symmetric-key crypto is easy in a black-box sense, because most algorithms come with rules that say "You need to do this and not do that", yet the original PPTP did half a dozen things wrong with RC4 even though the only rule is "never use the same state twice." But if you want to look inside the black box, most of what's there is a lot of bit-twiddling, maybe in a Feistel network, and while you can follow the bits around and see what changes, there can still be surprises like the discovery of differential cryptanalysis. Public-key crypto lets you use math to do the analysis, but [vast over-simplification] symmetric-key mostly lets you play around and decide if it's messy enough that you can't follow the bits. But there are other traps that affect people with either kind of system. Once PGP got past the Bass-o-matic stage, the biggest security problems were mostly things like variable-precision numbers that were trying so hard to save bits that you could trick the program into interpreting them differently and accepting bogus information. Fortunately we'd never have problems like that today (yes, ASN.1 BER/DER, I'm looking at you....), and nobody ever forgets to check array bounds (harder in modern languages than in C or Fortran, but still quite possible), or fails to validate input before using it (SQL injections), etc. _______________________________________________ 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

[Cryptography] Protecting Private Keys
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from "Jeffrey I. Schiller" <jis(a)mit.edu> ----- Date: Sat, 7 Sep 2013 10:20:52 -0400 From: "Jeffrey I. Schiller" <jis(a)mit.edu> To: cryptography(a)metzdowd.com Subject: [Cryptography] Protecting Private Keys User-Agent: Mutt/1.5.21 (2010-09-15) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While we worry about symmetric vs. public key ciphers, we should not forget the risk of compromise of our long-term keys. How are they protected? One of the most obvious ways to compromise a cryptographic system is to get the keys. This is a particular risk in TLS/SSL when PFS is not used. Consider a large scale site (read: Google, Facebook, etc.) that uses SSL. The private keys of the relevant certificates needs to be literally on hundreds if not thousands of systems. Chances are they are not encrypted on those systems so those systems can auto-restart without human intervention. Those systems also break periodically. What happens to the broken pieces, say a broken hard drive? If one of these private keys is compromised, all pre-recorded traffic can now be decrypted, as long as PFS was not used (and as we know, it is rarely used). Encrypted email is also at great risk because we have no PFS in any of these systems. Our private keys tend to last a long time (just look at the age of my private key!). If I was the NSA, I would be scavenging broken hardware from “interesting” venues and purchasing computers for sale in interesting locations. I would be particularly interested in stolen computers, as they have likely not been wiped. The bottom line here is that the NSA has upped the game (and probably did so quite a while ago, but we are just learning about it now). This means that commercial organizations that truly want to protect their customers from the NSA, and other national actors whom I am sure are just as skilled and probably more brazen, need to up their game, by a lot! - -Jeff P.S. I am very careful about which devices my private key touches and what happens to it when I am through with it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFSKzZE8CBzV/QUlSsRAqTsAJ4xJymTj04zCGF7v9OaZ4vJC3WoMgCfU1Qd 960tkxkWdrzz4ymCksyaKog= =0JHf -----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