Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Tue, Sep 10, 2013 at 2:04 PM, Joe Abley jab...@hopcount.ca wrote: As an aside, I see CAs with Chinese organisation names in my browser list. I wouldn't pick on/fear/call out the Chinese specifically. Also, be aware that browsers must transitively trust all the issuers that the known trust anchors have issued issuing certificates for. That's a much bigger set, and is not currently fully knowable. (Another reason to crave Certificate Transparency.) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Mon, Sep 09, 2013 at 06:41:23AM -0700, Andreas Davour wrote: So there *is* a BTNS implementation, after all. Albeit only for OpenBSD -- but this means FreeBSD is next, and Linux to follow. I might add that as far as I know, this work has not been picked up yet by neither FreeBSD, nor Linux, so if you feel like giving the project a hand pushing it into the mainstream, I'm pretty sure mc would be very happy. I.e. I don't think anything is following on this work unless someone reading this helps making that happen. Personally I have neither the skills nor the contacts needed. To use btns, you need iked installed: from http://hack.org/mc/projects/btns/howto.html Please note: The BTNS implementation is currently very experimental and should be used with caution. Doesn't sound like this is production ready? It isn't. Thus my addition to Eugen's suggestion that other operating system implementations are to follow, and my suggestion that you might want to hack on the project. But, I wanted to let people engaged by the topic of btns know of an implementaion, since at least there is a start! /andreas -- My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me. -- Edward Snowden's Father ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote: ➢ then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret ➢ services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. How would this work, in practice? Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing the plaintext through with interception is then straightforward. This would be detectable by Bob by the visible client address, but that could be obfuscated (Mallory could exit the session through something tor-like, for example, to avoid advertising their topological location; this would just make it look like Alice is using tor). In the case where Alice is presenting a certificate specifically trusted by Bob, this wouldn't work so well. But my observation is that many TLS-protected streams used by consumers don't use client certificate authentication. As an aside, I see CAs with Chinese organisation names in my browser list. I don't know how to distinguish between enterprises and government from this side of the Pacific (so, presumably, assume they are all government). I had always assumed that this was already happening at the Great Firewall, as a working example of government-sponsored TLS interception with no requirement for expensive crunching of large integers. Joe ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Tue, 10 Sep 2013 17:04:51 -0400 Joe Abley jab...@hopcount.ca wrote: On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote: then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. How would this work, in practice? Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Note that the apparent attacks against Petrobras, SWIFT and others disclosed a few days ago appear to have used precisely this attack. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 10 September 2013 22:04, Joe Abley jab...@hopcount.ca wrote: Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing the plaintext through with interception is then straightforward. CT makes this impossible to do undetected, of course. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Hi Jeffery, On 8/09/13 02:52 AM, Jeffrey I. Schiller wrote: The IETF was (and probably still is) a bunch of hard working individuals who strive to create useful technology for the Internet. Granted! I do not want to say that the IETF people are in a conspiracy with someone or each other, or that they are not hard workers [0]. But, I do want to say that, when it comes to security, we now have enough history and experience to suggest: the committee may be part of the problem [1], *and* it is not clear that it can ever be part of the solution. Insultingly; those who've spent a decade or so devoting themselves to this process will not take to that notion kindly. It's sad and frustrating -- I also spent a lot of time money pushing OpenPGP code -- but that does not change the basic economic data we have in front of us. In the 1990s we had little or no real data about Internet security. Now we're 20 years on. We have real data. 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” The notion that employees are there as individuals is noble but unrealistic, naive. That's to ignore business and politics, h/t to John Young. Individuals without funded interests are rare, and tend to only be around for brief periods [2]. It is the case that the IETF has done better than other industry groups by insisting on open access and rough consensus [3]. But the IETF has done nothing to change the laws of economics: Being on a committee costs a huge amount of time. Only corporates who are engaged in making money off of the results can typically re-invest that money, and only individuals committed to working *that job* from corporates would spend that time on their own dime. So, naturally, the corporates dominate the committees. To argue anything else is to argue against economics, perhaps the strongest force in human nature. but the bulk of participant I worked with were honest hard working individuals. There's nothing dishonest or lazy about defending ones job. 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. Although it is nicely logical and oft received wisdom, this is not historically supported. Skype, SSH, Bitcoin, OTR, iMessage are successful security products. There is clearly a market for good stuff but we the engineers don't see how to get there, and corporates don't either. Putting us in a committee doesn't improve that, and probably makes it worse. 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). 2. counter-points in abundance: transaction databases, protocols, monies, browsers, webservers, file sharing, p2p chats, office, languages, registries, source control, kernels, etc. These are all hard. We have a long list of projects and systems where we (the non-committee'd internet) have produced very difficult things. It is therefore hard to show return on investment with security. It is hard to assign a value to something not happening. ROI: a. it is hard to show quality at any points behind the screen. The only things that are easy to show are pretty widgets on screens. Everything else is hard. b. I often show ROI models as to why security saves money. (The model derives from support costs, if anyone doubts this. Also, see Lynn Wheeler's discussion of credit card fees for the basic economics.) Which is to say, the problems the net face in security are somewhat distinct from them being just hard hard to show; correlation maybe but causality? 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. 2a., I agree! I now feel bitten by Skype, and damn them to hell! 3. As engineers we have totally and completely failed to deliver products that people can use. Right. (It is a slow-moving nightmare moving all our people to OTR, which is dominated at the usability level by Skype.) 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
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
➢ then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret ➢ services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. How would this work, in practice? How would knowing a CA's private key give them knowledge of my key? Or if they issued a fake certificate and keypair, how does that help? They'd also have to suborn DNS and IP traffic such that it would, perhaps eventually or perhaps quickly, become obvious. What am I missing? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
From: Eugen Leitl eu...@leitl.org Forwarded with permission. [snip] http://hack.org/mc/projects/btns/ So there *is* a BTNS implementation, after all. Albeit only for OpenBSD -- but this means FreeBSD is next, and Linux to follow. I might add that as far as I know, this work has not been picked up yet by neither FreeBSD, nor Linux, so if you feel like giving the project a hand pushing it into the mainstream, I'm pretty sure mc would be very happy. I.e. I don't think anything is following on this work unless someone reading this helps making that happen. Personally I have neither the skills nor the contacts needed. /andreas -- My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me. -- Edward Snowden's Father ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
* NSA employees participted throughout, and occupied leadership roles in the committee and among the editors of the documents Slam dunk. If the NSA had wanted it, they would have designed it themselves. The only conclusion for their presence that is rational is to sabotage it [3]. No. One mission of the NSA is to protect US government secrets. Since the government can no longer afford to specify their own security products all the time (or rather that the computer market has become commoditized), the NSA has an interest in making standard COTS products be secure. I do not know if the NSA worked to subvert IETF specifications, but participation isn't proof of it. /r$ Flaming Carrot!... Do you see Communists behind every bush? No... but SOMETIMES they hide there. -- Principal Security Engineer Akamai Technology Cambridge, MA ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
First, DNSSEC does not provide confidentiality. Given that, it's not clear to me why the NSA would try to stop or slow its deployment. DNSSEC authenticates keys that can be used to bootstrap confidentiality. And it does so in a globally distributed, high performance, high reliability database that is still without peer in the world. It was never clear to me why DNSSEC took so long to deploy, though there was one major moment at an IETF in which a member of the IESG told me point blank that Jim Bidzos had made himself so hated that the IETF would never approve a standard that required the use of the RSA algorithm -- even despite a signed blanket license for use of RSA for DNSSEC, and despite the expiration of the patent. I thought it was an extreme position, and it was very forcefully expressed -- but it was apparently widely enough shared that the muckety-mucks did force the standard to go back to the committee and have a second algorithm added to it (which multiplied the interoperability issues considerably and caused several years of further delay). John PS: My long-standing domain registrar (enom.com) STILL doesn't support DNSSEC records -- which is why toad.com doesn't have DNSSEC protection. Can anybody recommend a good, cheap, reliable domain registrar who DOES update their software to support standards from ten years ago? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 09/06/2013 05:58 PM, Jon Callas wrote: We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. I've seen this assertion several times in this thread, but I cannot help thinking that it depends on what *kind* of backdoor you're talking about, because there are some cases in which as a crypto amateur I simply cannot see how the construction of an asymmetric cipher could be accomplished. As an example of a backdoor that doesn't obviously permit an asymmetric-cipher construction, consider a broken cipher that has 128-bit symmetric keys; but one of these keys (which one depends on an IV in some non-obvious way that's known to the attacker) can be used to decrypt any message regardless of the key used to encrypt it. However, it is not a valid encryption key; no matter what you encrypt with it you get the same ciphertext. There's a second key (also known to the attacker, given the IV) which is also an invalid key; it has the property that no matter what you encrypt or decrypt, you get the same result (a sort of hash on the IV). How would someone construct an asymmetric cipher from this? Or is there some mathematical reason why such a beast as the hypothetical broken cipher I describe, could not exist? Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Let's suppose I design a block cipher such that, with a randomly generated key and 10,000 known plaintexts, I can recover that key. For this to be useful in a world with relatively sophisticated cryptanalysts, I must have confidence that it is extremely hard to find my trapdoor, even when you can look closely at my cipher's design. At this point, what I have is a trapdoor one-way function. You generate a random key K and then compute E(K,i) for i = 1 to 1. The output of the one-way function is the ciphertext. The input is K. If nobody can break the cipher, then this is a one-way funciton. If only I, who designed it, can break it, then it's a trapdoor one-way function. At this point, I have a perfectly fine public key encryption system. To send me a message, choose a random K, use it to encrypt 1 through 1, and then send me the actual message encrypted after that in K. If nobody but me can break the system, then this cipher works as my public key. The assumption that matters here is that you know enough cryptanalysis that it would be hard to hide a practical attack from you. If you don't know about differential cryptanalysis, I can do the master key cryptosystem, but only until you learn about it, at which point you will break my cipher. But if you can, say, hide the only good linear characteristics for some cipher in its S-boxes in a way that is genuinely intractible for anyone else to find, then you have a public key cryptosystem. You can publish the algorithm for hiding new linear characteristics in an S-box--this becomes the keypair generation algorithm. The private key is the linear characteristic that lets you break the cipher with (say) 1 known plaintexts, the public key is the cipher definition. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 8:53 PM, Gregory Perry gregory.pe...@govirtual.tvwrote: On 09/07/2013 07:52 PM, Jeffrey I. Schiller wrote: 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. The IETF mandates the majority of the standards used on the Internet today. No they do not. There is W3C and OASIS both of which are larger now. And there has always been IEEE. And they have no power to mandate anything. In fact one of the things I have been trying to do is to persuade people that the Canute act commanding the tides to turn is futile. People need to understand that the IETF does not have any power to mandate anything and that stakeholders will only follow standards proposals if they see a value in doing so. If the IETF were truly serious about authenticity and integrity and confidentiality of communications on the Internet, then there would have been interim ad-hoc link layer encryption built into SMTP communications since the end of U.S. encryption export regulations. Like STARTTLS which has been in the standards and deployed for a decade now? There would have been an IETF-mandated requirement for Voice over IP transport encryption, to provide a comparable set of confidentiality with VoIP communications that are inherent to traditional copper-based landline telephones. There would at the very least be ad-hoc (read non-PKI integrated) DNSSEC. What on earth is that? DNS is a directory so anything that authenticates directory attributes is going to be capable of being used as a PKI. And then there is this Bitcoin thing. I say this as an individual that doesn't even like Bitcoin. For the record and clearly off topic, I hate Bitcoin with a passion and I believe that the global economic crisis could be easily averted by returning to a precious metal standard with disparate local economies and currencies, all in direct competition with each other for the best possible GDP. The value of all the gold in the world ever mined is $8.2 trillion. The NASDAQ alone traded $46 trillion last Friday. There are problems with bitcoin but I would worry rather more about the fact that the Feds have had no trouble at all shutting down every prior attempt at establishing a currency of that type and the fact that there is no anonymity whatsoever. So how does Bitcoin exist without the IETF? In its infancy, millions of dollars of transactions are being conducted daily via Bitcoin, and there is no IETF involved and no central public key infrastructure to validate the papers of the people trading money with each other. How do you counter this Bitcoin thing, especially given your tenure and experience at the IETF? Umm I would suggest that it has more to do with supply and demand and the fact that there is a large amount of economic activity that is locked out of the formal banking system (including the entire nation of Iran) that is willing to pay a significant premium for access to a secondary. Nonsense. Port 25 connects to another port 25 and exchanges a public key. Then a symmetrically keyed tunnel is established. This is not a complex thing, and could have been written into the SMTP RFC decades ago. RFC 3702 published in 2002. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 10:35 PM, Gregory Perry gregory.pe...@govirtual.tvwrote: On 09/07/2013 09:59 PM, Phillip Hallam-Baker wrote: Anyone who thinks Jeff was an NSA mole when he was one of the main people behind the MIT version of PGP and the distribution of Kerberos is talking daft. I think that the influence was rather more subtle and was more directed at encouraging choices that would make the crypto hopelessly impractical so people would not use it than in adding backdoors. One of the lessons of PRISM is that metadata is very valuable. In particular social network analysis. If I know who is talking to whom then I have pretty much 90% of the data needed to wrap up any conspiracy against the government. So lets make sure we all use PGP and sign each other's keys... 1) At the core of the initial PGP distribution authored by Philip R. Zimmermann, Jr. was the RSA public key encryption method 2) At that time, the Clinton administration and his FBI was advocating widespread public key escrow mechanisms, in addition to the inclusion of the Clipper chip to all telecommunication devices to be used for remote lawful intercepts 3) Shortly after the token indictment of Zimmerman (thus prompting widespread use and promotion of the RSA public key encryption algorithm), the Clinton administration's FBI then advocated a relaxation of encryption export regulations in addition to dropping all plans for the Clipper chip 4) On September 21, 2000, the patent for the RSA public key encryption algorithm expired, yet RSA released their open source version of the RSA encryption algorithm two weeks prior to their patent's expiry for use within the public domain 5) Based upon the widespread use and public adoption of the RSA public key encryption method via the original PGP debacle, RSA (now EMC) could have easily adjusted the initial RSA patent term under the auspice of national security, which would have guaranteed untold millions (if not billions) of additional dollars in revenue to the corporate RSA patent holder You do the math This is seriously off topic here but the idea that the indictment of Phil Zimmerman was a token effort is nonsense. I was not accusing Phil Z. of being a plant. Not only was Louis Freeh going after Zimmerman for real, he went against Clinton in revenge for the Clipper chip program being junked. He spent much of Clinton's second term conspiring with Republicans in Congress to get Clinton impeached. Clipper was an NSA initiative that began under Bush or probably even earlier. They got the incoming administration to endorse it as a fait accompli. Snowden and Manning on the other hand... Well I do wonder if this is all some mind game to get people to secure the Internet against cyberattacks. But the reason I discount that as a possibility is that what has been revealed has completely destroyed trust. We can't work with the Federal Government on information security the way that we did in the past any more. I think the administration needs to make a downpayment on restoring trust. They could begin by closing the gulag in Guantanamo. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 9:50 PM, John Gilmore g...@toad.com wrote: First, DNSSEC does not provide confidentiality. Given that, it's not clear to me why the NSA would try to stop or slow its deployment. DNSSEC authenticates keys that can be used to bootstrap confidentiality. And it does so in a globally distributed, high performance, high reliability database that is still without peer in the world. It was never clear to me why DNSSEC took so long to deploy, though there was one major moment at an IETF in which a member of the IESG told me point blank that Jim Bidzos had made himself so hated that the IETF would never approve a standard that required the use of the RSA algorithm -- even despite a signed blanket license for use of RSA for DNSSEC, and despite the expiration of the patent. I No, that part is untrue. I sat at the table with Jeff Schiller and Burt Kaliski when Burt pitched S/MIME at the IETF. He was Chief Scientist of RSA Labs at the time. Jim did go after Phil Z. over PGP initially. But Phil Z. was violating the patent at the time. That led to RSAREF and the MIT version of PGP. DNSSEC was (and is) a mess as a standard because it is an attempt to retrofit a directory designed around some very tight network constraints and with a very poor architecture to make it into a PKI. PS: My long-standing domain registrar (enom.com) STILL doesn't support DNSSEC records -- which is why toad.com doesn't have DNSSEC protection. Can anybody recommend a good, cheap, reliable domain registrar who DOES update their software to support standards from ten years ago? The Registrars are pure marketing operations. Other than GoDaddy which implemented DNSSEC because they are trying to sell the business and more tech looks kewl during due diligence, there is not a market demand for DNSSEC. One problem is that the Registrars almost invariably sell DNS registrations at cost or at a loss and make the money up on value added products. In particular SSL certificates. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 7, 2013, at 11:45 PM, John Kelsey wrote: Let's suppose I design a block cipher such that, with a randomly generated key and 10,000 known plaintexts, I can recover that key At this point, what I have is a trapdoor one-way function. You generate a random key K and then compute E(K,i) for i = 1 to 1. The output of the one-way function is the ciphertext. The input is K. If nobody can break the cipher, then this is a one-way funciton. If only I, who designed it, can break it, then it's a trapdoor one-way function At this point, I have a perfectly fine public key encryption system. To send me a message, choose a random K, use it to encrypt 1 through 1, and then send me the actual message encrypted after that in K. If nobody but me can break the system, then this cipher works as my public key. OK, let's look at this another way. The broader argument being made here breaks down into three propositions: 1. If you have a way to spike a block cipher based on embedding a secret in it, you can a way to create something with the formal properties of a public key cryptosystem - i.e., there is a function E(P) which anyone can compute on any plaintext P, but given E(P), only you can invert to recover P. 2. Something with the formal properties of a public key cryptosystem can be used as a *practical* public key cryptosystem. 3. A practical public-key cryptosystem is much more valuable than a way to embed a secret in a block cipher, so if anyone came up with the latter, they would certainly use it to create the former, as it's been the holy grail of cryptography for many years to come up with a public key system that didn't depend on complex mathematics with uncertain properties. If we assume these three propositions, and looks around us and observe the lack of the appropriate kinds of public key systems, we can certainly conclude that no one knows how to embed a secret in a block cipher. Proposition 1, which is all you specifically address, is certainly true. I claim that Propositions 2 and 3 are clearly false. In fact, Proposition 3 isn't even vaguely mathematical - it's some kind of statement about the values that cryptographers assign to different kinds of primitives and to publication. It's quite true that if anyone in the academic world were to come up with a way to create a practical public key cryptosystem without a dependence on factoring or DLP, they would publish to much acclaim. (Of course, there *are* a couple of such systems known - they were published years ago - but no one uses them for various reasons. So acclaim ... well, maybe.) Then again, an academic cryptographer who discovered a way to hide a secret in a block cipher would certainly publish - it would be really significant work. So we never needed this whole chain of propositions to begin with: It's self-evidently true that no one in the public community knows how to embed a secret in a block cipher. But ... since we're talking *values*, what are NSA's values? Would *they* have any reason to publish if they found a way to embed a secret in a block cipher? Hell, no! Why would they want to give away such valuable knowledge? Would they produce a private-key system based on their breakthrough? Maybe, for internal use. How would we ever know? But let's talk mathematics, not psychology and politics. You've given a description of a kind of back door that *would* produce a practical public key system. But I've elsewhere pointed out that there are all kinds of back doors. Suppose that my back door reduces the effective key size of AES to 40 bits. Even 20+ years ago, NSA was willing to export 40-bit crypto; presumably they were willing to do the brute-force computation to break it. Today, it would be a piece of cake. But would a public-key system that requires around 2^40 operations to encrypt be *practical*? Even today, I doubt it. And if you're willing to do 2^40 operations, are you willing to do 2^56? With specialized hardware, that, too, has been easy for years. NSA can certainly have that specialized hardware for code breaking - will you buy it for encryption? The assumption that matters here is that you know enough cryptanalysis that it would be hard to hide a practical attack from you. If you don't know about differential cryptanalysis, I can do the master key cryptosystem, but only until you learn about it, at which point you will break my cipher. In fact, this is an example I was going to give: In a world in which differential crypto isn't known, it *is* a secret that's a back door. Before DC was published, people seriously proposed strengthening DES by using a 448-bit (I think that's the number) key - just toss the round key computation mechanism and provide all the keying for all the rounds. If that had been widely used, NSA would have been able to break it use DC. Of course we know about DC. But the only
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Hi, http://www.youtube.com/watch?v=K8EGA834Nok Is DNSSEC is really the right solution? Daniel ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 6:50 PM, John Gilmore g...@toad.com wrote: PS: My long-standing domain registrar (enom.com) STILL doesn't support DNSSEC records -- which is why toad.com doesn't have DNSSEC protection. Can anybody recommend a good, cheap, reliable domain registrar who DOES update their software to support standards from ten years ago? PIR (the .org registry) has a field in their registrar list indicating if the registrar supports DNSSEC: http://www.pir.org/get/registrars?order=field_dnssec_valuesort=desc If you exclude all the name.com and Go Daddy shell registrars, you still have more than 30 to choose from. I would be shocked if they didn't all offer .com in addition to .org. Thanks, Peter ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
3) Shortly after the token indictment of Zimmerman (thus prompting widespread use and promotion of the RSA public key encryption algorithm), the Clinton administration's FBI then advocated a relaxation of encryption export regulations in addition to dropping all plans for the Clipper chip I need to correct some facts, especially since I'm seeing this continue to get repeated. Phil was never charged, indicted, sued, or anything else. He was *investigated*. He was investigated for export violations, not for anything else. Being investigated is bad enough, but that's what happened. The government dropped the investigation in early 1996. The government started the investigation because they were responding to a complaint from RSADSI that Phil and team violated export control. As Phill noted, there was the secondary issue of the dispute over the RSA patent license, but that was a separate issue. RSADSI filed the complaint with the government that started the investigation. Jon PGP.sig Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-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@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013, Phillip Hallam-Baker wrote: * Allowing deployment of DNSSEC to be blocked in 2002(sic) by blocking a technical change that made it possible to deploy in .com. As an opponent of DNSSEC opt-in back in the day, I think this is a poor example of NSA influence in the standards process. I do not challenge PHB's theory that the NSA has plants in the IETF to discourage moves to strong crypto, particularly given John Gilmore's recent message on IPSEC, but I doubt that the NSA had any real influence on the DNSSEC opt-in debacle of 2003. First, DNSSEC does not provide confidentiality. Given that, it's not clear to me why the NSA would try to stop or slow its deployment. Second, as I look at the people who opposed opt-in and the IETF working group chairs who made the decision to kill it, I don't see likely NSA stooges. The list of opponents during working group last call was so short [1] (as compiled by PHB, back in the day) that I thought the working group chairs got the consensus call wrong. The DNSEXT chairs were Randy Bush and Olafur Gudmundsson. In previous years, Olafur had worked for TIS Labs, which had taken plenty of DoD money over the years. Even so, I do not suspect he was influenced by the NSA. Randy has taken money from DHS in more recent years, but I'm even more convinced he was not an NSA stooge. (Randy was the chair issuing the opt-in last call and writing the summary.) Third, many of the opt-in opponents in 2003 seemed to be pretty convinced that the lowered security guarantees and extra complexity of opt-in were nothing more than a subsidy for Verisign, which could just as well throw more money at the problem of signing its large zones. One might plausibly argue that Verisign's push for opt-in (and its later push for NSEC3) was itself a stalling tactic. One might even go further and say that Verisign initiated such stalling at the behest of the NSA. I would not make that argument, but it is at least as plausible as an argument that the opt-in opponents or WG chairs were NSA stooges. Lastly, the US DoD was funding some amount of work on DNSSEC at the time (i.e., my own participation). During that timeframe, significant progress was being made on the deployability of DNSSEC, and I think the DoD funding helped. Depending on your whims, you could either credit DoD for helping or blame them for not providing even more funding, which might have made for faster progress. So, again, while PHB's general theory might have merit, I think the DNSSEC opt-in example is not on point. Disclosures: I was deeply involved in the IETF's DNSEXT working group during this time, and my funding came from non-NSA bits of DoD. I am not aware of any NSA influence in my funding, and I felt no NSA pressure in the work I was doing. I was a vocal opponent of opt-in, but in the end I chose to step aside and let it advance.[2] -- Samuel Weiler [1] http://marc.info/?l=namedroppersm=105145468327451w=2 [2] http://marc.info/?l=namedroppersm=104874927417175w=2 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
As an opponent of DNSSEC opt-in back in the day, I think this is a poor example of NSA influence in the standards process. I do not challenge PHB's theory that the NSA has plants in the IETF to discourage moves to strong crypto, particularly given John Gilmore's recent message on IPSEC, but I doubt that the NSA had any real influence on the DNSSEC opt-in debacle of 2003. First, DNSSEC does not provide confidentiality. Given that, it's not clear to me why the NSA would try to stop or slow its deployment. Insecure DNS deployments are probably in the top five attack vectors for remotely compromising internal network topologies, even those sporting split DNS configurations. As you were ...deeply involved in the IETF's DNSEXT working group then I presume you know this. For example, DNS cache poisoning attacks, local ARP cache spoofing attacks to redirect DNS queries and responses, redirection of operating system update and patching services that map to fully qualified domain names such as windowsupdate.microsoft.com, etc. Correct me if I am wrong, but in my humble opinion the original intent of the DNSSEC framework was to provide for cryptographic authenticity of the Domain Name Service, not for confidentiality (although that would have been a bonus). Lastly, the US DoD was funding some amount of work on DNSSEC at the time (i.e., my own participation). During that timeframe, significant progress was being made on the deployability of DNSSEC, and I think the DoD funding helped. Depending on your whims, you could either credit DoD for helping or blame them for not providing even more funding, which might have made for faster progress. There are many different camps within the DoD. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 7/09/13 01:51 AM, Peter Gutmann wrote: ianG i...@iang.org writes: And, controlling processes is just what the NSA does. https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html How does '(a) Organizations and Conferences' differ from SOP for these sorts of things? In principle, it doesn't -- which is why SOPs are saboteur's tools of preference. They are used against you, as the lesser experienced people can't see the acts behind [1] The point is one of degree. SOPs are there to resolve real disputes. They can also be used to cause disputes, and to turn any innocent thing into a fight. So do that, and keep doing that! Pretty soon the org becomes a farce. In contrast, strong leadership (the chair) knows when to put the lid on such trivialities and move on. So, part of the overall strategy is to neutralise the strong chair [2]. As John just reported: * NSA employees participted throughout, and occupied leadership roles in the committee and among the editors of the documents Slam dunk. If the NSA had wanted it, they would have designed it themselves. The only conclusion for their presence that is rational is to sabotage it [3]. iang [0] SOPs is standard operating procedures. [1] This is the flaw in don't attribute to malice what can be explained by incompetence. Explaining by incompetence does not eliminate that malice inspired incompetence. Remember, we are all innoculated against malice, so we prefer to see benign causes. [2] this is not to say that committees are ill-intentioned or people are bad, but that it only takes a few with malicious intent and expertise to bring the whole game to a halt. Cartels such as IETF WGs are fundamentally and inescapably fragile. [3] as a sort of summer-flu-shot, I present that document to each new board as their SOPs. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 7/09/13 03:58 AM, Jon Callas wrote: Could an encryption algorithm be explicitly designed to have properties like this? I don't know of any, but it seems possible. I've long suspected that NSA might want this kind of property for some of its own systems: In some cases, it completely controls key generation and distribution, so can make sure the system as fielded only uses good keys. If the algorithm leaks without the key generation tricks leaking, it's not just useless to whoever grabs onto it - it's positively hazardous. The gun that always blows up when the bad guy tries to shoot it We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. I'm not as yet seeing that a block cipher with a backdoor is a public key system, but I really like the mental picture this is trying to create. In order to encrypt to that system, one needs the (either) key. If everyone has it (either) the system is ruined. A public key system is an artiface where one can distribute the public key, and not have to worry about the system being ruined; it's still perfectly usable. Whereas with a symmetric system with two keys, either key being distributed ruins the system. One could argue that the adversary would prefer the cleaner, more complete semantics of the public key system -- maybe that is what the theorem assumes? But if I was the NSA I'd be happy with the compromise. I'm good at keeping *my key secret* at least. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, Sep 06, 2013 at 09:19:07PM -0400, Derrell Piper wrote: ...and to add to all that, how about the fact that IPsec was dropped as a 'must implement' from IPv6 sometime after 2002? Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption mode for IPsec) implementations, and even the authors of the RFC are not aware of any. Obviously, having a working OE BTNS implementation in Linux/*BSD would be a very valuable thing, as an added, transparent protection layer against passive attacks. There are many IPsec old hands here, it is probably just a few man-days worth of work. It should be even possible to raise some funding for such a project. Any takers? signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 7/09/13 10:15 AM, Gregory Perry wrote: Correct me if I am wrong, but in my humble opinion the original intent of the DNSSEC framework was to provide for cryptographic authenticity of the Domain Name Service, not for confidentiality (although that would have been a bonus). If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. How much more obvious does it get [1] ? iang [0] If one is a finance geek, one can even calculate how much money the opponents are willing to spend. [1] As an aside, NSA/DoD have invested significant capital in the PKI as well. Sufficient that they will be well aligned with the CA mission, and sufficient that they will approve of any effort to keep the CAs in business. But this part is far less obvious. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 7, 2013, at 12:31 AM, Jon Callas wrote: I'm sorry, but this is just nonsense. You're starting with informal, rough definitions and claiming a mathematical theorem. Actually, I'm doing the opposite. I'm starting with a theorem and arguing informally from there Actually, if you look at the papers cited, *they* are themselves informal. The fundamental thing they are lacking is a definition of what would constitute a master key. Let's see if we can formalize this a bit: We're given a block cipher E(K,P) and a corresponding decryption algorithm D(K,C). The system has a master key M such that D(E(K,P),M) == P. This is what a master key does in a traditional lock-and-key system, so unless we see some other definition, it's what we have to start with. Is there such a system? Sure, trivially. Given any block cipher E'/D', I simply define E(K,P) = E'(M,K) || E'(K,P). (I can optimize the extra length by leaking one randomly chosen bit of E'(M,K) per block. It won't take long for the whole key to be transmitted.) OK, where's the public key system? So maybe there isn't *one* master key, but let's go to the extreme and say there is one unique master per user key, based on some secret information S. That is: Given K, there is a function F(S,K) which produces a *different* key K', with the property that D(K,C) == D(K',C). Or maybe, as in public key systems, you start with S and some random bits and produce a matched pair K and K' But how is this a master key system? If I wasn't present at the birth of the K that produced the cyphertext I have in hand ... to get K' now, I need K (first form) or S and the random bits (second form), which also gives me K directly. So what have I gained? I can construct a system of the first form trivially: Just use an n-bit key but ignore the first bit completely. There are now two keys, one with a leading 0, one with a leading 1. Constructing a system of the second form shouldn't be hard, though I haven't done it. In either case, it's uninteresting - my master key is as hard to get at as the original key. I'm not sure exactly where to go next. Let's try to modify some constraints. Eliminate directly hiding the key in the output by requiring that E(K,.) be a bijection. There can't possibly be a single master key M, since if there were, what could D(M,E(M,0...0)) be? It must be E(K,0...0) for any possible K, so E(K,0...0) must be constant - and in fact E must be constant. Not very interesting. In fact, a counting argument shows that there must be as many M's as there are K's. It looks as we're back to the two-fold mapping on keys situation. But as before ... how could this work? In fact, it *could* work. Suppose I use a modified form of E() which ignores all but the first 40 bits of K - but I don't know that E is doing this. I can use any (say, 128-bit) key I like, and to someone not in on the secret, a brute force attack is impossible. But someone who knows the secret simply sets all but the first 40 bits to 0 and has an easy attack. *Modified forms (which hid what was happening to some degree) of such things were actually done in the days of export controls!* IBM patented and sold such a thing under the name CDMF (http://domino.research.ibm.com/tchjr/journalindex.nsf/600cc5649e2871db852568150060213c/a453914c765e690085256bfa0067f9f4!OpenDocument). I worked on adding cryptography to a product back in those days, and we had to come up with a way to be able to export our stuff. I talked to IBM about licensing CDMF, but they wanted an absurd amount of money. (What you were actually paying for wasn't the algorithm so much as that NSA had already approved products using it for export.) We didn't want to pay, and I designed my own algorithm to do the same thing. It was a silly problem to have to solve, but I was rather proud of the solution - I could probably find my spec if anyone cares. It was also never implemented, first because this was right around the time the crypto export controls got loosened; a nd second because we ended up deciding we didn't need crypto anyway. We came back and did it very differently much later. My two fun memories from the experience: (a) Receiving a FAX from NSA - I still have it somewhere; (b) being told at one point that we might need someone with crypto clearance to work on this stuff with NSA, and one of my co-workers chiming in with Well, I used to have it. Unfortunately it was from the KGB. Anyway ... yes, I can implement such a thing - but there's still no public key system here. So ... would *you* like to take a stab at pinning down a definition relative to which the theorem you rely on makes sense? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. How much more obvious does it get [1] ? The PKI industry has been a sham since day one, and several root certs have been compromised by the proverbial bad guys over the years (for example, the Flame malware incident used to sign emergency Windows Update packages which mysteriously only affected users in Iran and the Middle East, or the Diginotar debacle, or the Tunisian Ammar MITM attacks etc). This of course is assuming that the FBI doesn't already have access to all of the root CAs so that on domestic soil they can sign updates and perform silent MITM interception of SSL and IPSEC-encrypted traffic using transparent inline layer-2 bridging devices that are at every major Internet peering point and interconnect, because that would be crazy talk. However, some form of authenticity and integrity is better than zero, which is what the majority of the current DNS system offers, and it is point and click trivial to perform MITM attacks with unauthenticated DNS, especially on local area network segments which are rarely protected with more than the Windows firewall. Even without a centralized PKI, stateless port 53 UDP DNS could benefit from some type of cryptographic security, but as with any standard seemingly related to privacy or confidentiality we are left with this DNSSEC quagmire of meetings and proposed meetings to talk about the next meeting to discuss how the committee will propose the next request for comment, ad nauseum. Bitcoin for example doesn't need hundreds of private companies with elaborate PKI documentation authentication services which are in reality just mental placebos for Joe Consumer when he updates his monthly Brazzers subscription, and it's doing just fine as the runner up for the next global world monetary standard. So with that said, I would still place my wager on the FBI being the source of these various privacy enhancing service delays and not some secret cabal of PKI execs that are engaging in standards committee subterfuge. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 2:19 AM, ianG i...@iang.org wrote: On 7/09/13 10:15 AM, Gregory Perry wrote: Correct me if I am wrong, but in my humble opinion the original intent of the DNSSEC framework was to provide for cryptographic authenticity of the Domain Name Service, not for confidentiality (although that would have been a bonus). If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. How much more obvious does it get [1] ? iang I proposed essentially this idea around 10 years ago on the capabilities list, using custom TXT records and some hackish things that are/were sub-optimal due to DNSSEC being more of a pipedream then than it is now to deliver public keys for any arbitrary purpose. I only went so far as to kick around design ideas on and off-list back then under the tag-line of objectdns (as in being able to locate and connect to any arbitrary object via a public key crypto connection) and registering the domain objectdns.com. Things stalled out there due to my lack of copious free time. David Mercer - http://dmercer.tumblr.com IM: AIM: MathHippy Yahoo/MSN: n0tmusic Facebook/Twitter/Google+/Linkedin: radix42 FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 09/07/13 05:19, ianG wrote: If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. unfortunately as far as SSL domain name certificate ... the domain name infrastructure is the authoritative agency for domain name ownership ... the SSL domain name certification agencies have to rely on the domain name infrastructure to validate true ownership for SSL domain name applications. As I've repeatedly referenced ... this puts the CAs in catch22 ... they need improved integrity of domain name infrastructure (attacks on ownership records of domain name ownership and then being issued valid SSL certificate) ... which comes with lots of DNSSEC ... but that also eliminates much of the need for SSL domain certificates. as per prior reference about original working on SSL for electronic commerce ... at least for the financial industry I've repeatedly shown that digital certificates were redundant and superfluous. I also shown that at the time, the addition of digital certificates increased the payload size by two orders of magnitude (besides being redundant and superfluous). That apparently motivated the compressed digital certificate financial standard effort ... trying to reduce digital certificates so that the payload bloat was only ten times (instead of hundred times) ... in large part by eliminating all information that the processing institution already had. I demonstrated that processing institution would have all information and therefor digital certificates could be reduced to zero bytes ... so instead of eliminating redundant and superfluous digital certificates ... it was possible to mandate that zero byte certificates be appended to every transaction (it would be possible to digitally sign a payment transaction for authentication ... and rely on the individual's financial institution to have registered the person's public key ... w/o having to increase the size of every payment transaction in the world by 100 times just to transmit a redundant and superfluous appended digital certificate). I like the interchange at panel discussion in early 90s ACM SIGMOD ballroom open session, somebody in the audience asked what was all this x.5xx stuff about and one of the panelists said it was a bunch of networking engineers trying to reinvent 1960s database technology. there was some amount of participation by the information assurance directorate in financial industry standards meetings. at various times there were references to rifts between IA and SIGINT ... but for all I know that may be kabuki theater. I was fairly vocal about any backdoors could put financial industry at risk for bad guys discovering the vulnerabilities ... and wanted KISS applied to as much as possible (and backdoors forbidden) there are other agendas in much of this. at the start of the century there were several safe internet payment products pitched to major merchants (accounting for 70% of internet transactions) which got high acceptance. Merchants have been indoctrinated for decades that a large part of interchange fee is proportional to associated fraud rate ... and the merchants were expecting an order of magnitude reduction in their fees (with the safe products). Then came the cognitive dissonance when the banks told the merchants that rather than major reduction in interchange fees with the safe payment products ... there would effectively be a surcharge added to the highest fee that they were already paying (and all the safe efforts collapse). Part of the issue was that the bottom line for large issuing banks was 40%-60% from these fees and an order of magnitude reduction in those fees would be a big hit to their bottom line (the size of fees in part justified by fraud rates). The safe products going a long way to eliminating most fraud and commoditizing the payment transaction business ... which would also lower the bar for entry by competition. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 09/07/2013 04:20 PM, Phillip Hallam-Baker wrote: Before you make silly accusations go read the VeriSign Certificate Practices Statement and then work out how many people it takes to gain access to one of the roots. The Key Ceremonies are all videotaped from start to finish and the auditors have reviewed at least some of the ceremonies. So while it is not beyond the realms of possibility that such a large number of people were suborned, I think it drastically unlikely. Add to which Jim Bizdos is not exactly known for being well disposed to the NSA or key escrow. Hacking CAs is a poor approach because it is a very visible attack. Certificate Transparency is merely automating and generalizing controls that already exist. But we can certainly add them to S/MIME, why not. VeriSign is one single certificate authority. There are many, many more certificate authorities spread across the world, and unless you can guarantee an air-gapped network with tightly constrained physical security controls and a secret videotaped bohemian ceremony such as the one you reference above at each and every one of those CAs, then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. To whit: ...Mozilla maintains a list of at least 57 trusted root CAs, though multiple commercial CAs or their resellers may share the same trusted root). [http://en.wikipedia.org/wiki/Certificate_authority]http://en.wikipedia.org/wiki/Certificate_authority Another relevant read: http://www.quora.com/SSL-Certificates/How-many-intermediate-Certificate-Authorities-are-there# ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 5:19 AM, ianG i...@iang.org wrote: On 7/09/13 10:15 AM, Gregory Perry wrote: Correct me if I am wrong, but in my humble opinion the original intent of the DNSSEC framework was to provide for cryptographic authenticity of the Domain Name Service, not for confidentiality (although that would have been a bonus). If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. How much more obvious does it get [1] ? 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. CAs do not make their money in the ways you imagine. If there was any business case for DNSSEC I will have no problem at all finding people willing to pay $50-100 to have a CA run their DNSSEC for them because that is going to be a lot cheaper than finding a geek with the skills needed to do the configuration let alone do the work. One reason that PGP has not spread very far is that there is no group that has a commercial interest in marketing it. At the moment revenues from S/MIME are insignificant for all the CAs. Comodo gives away S/MIME certs for free. Its just not worth enough to try to charge for right now. If we can get people using secure email or DNSSEC on a large scale then CAs will figure out how to make money from it. But right now nobody is making a profit from either. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
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. 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. There is no reason for any of this, and I would once again cite to Bitcoin as an example of how an entire secure online currency standard can be created and maintained in a decentralized fashion without the need for complex hierarchies of quasi-political commercial interests. Encrypting SMTP is trivial, it's all about the standard to make it happen. 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. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Sep 07, 2013 at 09:14:47PM +, 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 j...@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@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
I don't see what problem would actually be solved by dropping public key crypto in favor of symmetric only designs. I mean, if the problem is that all public key systems are broken, then yeah, we will have to do something else. But if the problem is bad key generation or bad implementations, those will be with us even after we abandon all the public key stuff. And as Jon said, the trust problems get harder, not easier. With only symmetric crypto, whoever acts as the introducer between Alice and Bob can read their traffic passively and undetectably. With public key crypto, the introducer can do a man in the middle attack (an active attack) and risks detection, as Alice and Bob now have things signed by the introducer associating the wrong keys with Bob and Alice, respectively. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 05, 2013 at 04:11:57PM -0400, Phillip Hallam-Baker wrote: If a person at Snowden's level in the NSA had any access to information Snowden didn't have clearance for that information. He's being described as 'brilliant' and purportedly was able to access documents far beyond his level by impersonating (using stolen/falsified secrets) higher level officials. Culling admins and adding the two-eyes rule will cripple the TLAs more than it will accomplish anything. We're still missing the information which cyphers are now legacy, and which are still considered useful. I keep seeing PFS being touted, but there is no evidence yet we can trust PFS to be yet unbroken though it appears plausible. Others are suggesting that public key encryption methods are suspect, while symmetric encryption has a better story. I'm personally becoming quite interested in a reliable way to produce secure one-time pads, using physical entropy sources which have been validated. It would be interesting to physically/securely exchanging large one-time pads in one's social network, and reaching farther recipients in a Retroshare-like (turtle router) model. It might be useful to combine one-time pads with symmetric encryption, automatically rekeying every large block of data for high-volume transfers (e.g. mesh routers) to stretch a one-time pad without completely losing its properties. The question is how large a block can be before it leaks enough information about the key. that indicated the existence of any program which involved the successful cryptanalysis of any cipher regarded as 'strong' by this community then the Director of National Intelligence, the Director of the NSA and everyone involved in those decisions should be fired immediately and lose their pensions. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, 6 Sep 2013 01:19:10 -0400 John Kelsey crypto@gmail.com wrote: I don't see what problem would actually be solved by dropping public key crypto in favor of symmetric only designs. I mean, if the problem is that all public key systems are broken, then yeah, we will have to do something else. But if the problem is bad key generation or bad implementations, those will be with us even after we abandon all the public key stuff. Not necessarily. A bad implementation of a block cipher will be probably spotted quickly if you need it to interoperate with a good implementation; a bad implementation of a public key cipher might interoperate just fine with good implementations. Public key systems often have parameters or requirements that affect security without affecting the correctness of encryption or decryption. ElGamal encryption might appear to work even though you are using a group where the DDH assumption does not hold. Elliptic curve systems have even more parameters that need to be set correctly for security. I am not saying that we should abandon public key cryptography, I am just saying that there a number of ways for public key systems to go wrong that do not apply to symmetric ciphers. Just my 2 cents, Ben -- Benjamin R Kreuter UVA Computer Science brk...@virginia.edu KK4FJZ -- If large numbers of people are interested in freedom of speech, there will be freedom of speech, even if the law forbids it; if public opinion is sluggish, inconvenient minorities will be persecuted, even if laws exist to protect them. - George Orwell signature.asc Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
5. sep. 2013 kl. 23:14 skrev Tim Dierks t...@dierks.org: I believe it is Dual_EC_DRBG. The ProPublica story says: Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” This appears to describe the NIST SP 800-90 situation pretty precisely. I found Schneier's contemporaneous article to be good at refreshing my memory: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 As a co-author of an analysis of Dual-EC-DRBG that did not emphasize this problem (we only stated that Q had to be chosen at random, Ferguson co were right to emphasize this point), I would like to ask: Has anyone, anywhere ever seen someone use Dual-EC-DRBG? I mean, who on earth would be daft enough to use the slowest possible DRBG? If this is the best NSA can do, they are over-hyped. (If you really do want to use Dual-EC-DRBG: truncate more than 16 bits, and don't use NSA's points, choose your own - at random.) -- Kristian Gjøsteen ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Perhaps it's time to move away from public-key entirely! We have a classic paper - Needham and Schroeder, maybe? - showing that private key can do anything public key can; it's just more complicated and less efficient. Not really. The Needham-Schroeder you're thinking of is the essence of Kerberos, and while Kerberos is a very nice thing, it's hardly a replacement for public key. If you use a Needham-Schroeder/Kerberos style system with symmetric key systems, you end up with all of the trust problems, but on steroids I don't think we're really in disagreement here. Much of what you say later in the message is that the way we are using symmetric-key systems (CA's and such), and the way browsers work, are fundamentally wrong, and need to be changed. And that's really the point: The system we have is all of a piece, and incremental changes, sadly, can only go so far. We need to re-think things from the ground up. And I'll stand by my contention that we need to re-examine things we think we know, based on analyses done 30 years ago. Good theorems are forever, but design choices apply those theorems to real-world circumstances. So much has changed, both on the technical front and on non-technical fronts, that the basis for those design choices has fundamentally changed. Getting major changes fielded in the Internet is extremely difficult - see IPv6. If it can be done at all, it will take years. But the alternative of continuing on the path we're on seems less desirable every day. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 6, 2013, at 7:28 AM, Jerry Leichter wrote: ...Much of what you say later in the message is that the way we are using symmetric-key systems (CA's and such)... Argh! And this is why I dislike using symmetric and asymmetric to describe cryptosystems: In English, the distinction is way too brittle. Just a one-letter difference - and in including or not the letter physically right next to the s. -- Jerry :-) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, Sep 6, 2013 at 3:03 AM, Kristian Gjøsteen kristian.gjost...@math.ntnu.no wrote: Has anyone, anywhere ever seen someone use Dual-EC-DRBG? I mean, who on earth would be daft enough to use the slowest possible DRBG? If this is the best NSA can do, they are over-hyped. It's implemented in Windows and in a number of other libraries*; I can't find any documentation on which points these implementations use. But I agree that there's little technical reason to use it—however, who is to know that a vendor couldn't be influenced to choose it? In pursuing the list NIST validations, there's aa number of cases where Dual_EC_DRBG is the only listed mode, but all of them (with one exception) are issued to companies where they have other validations, generally on similar products, so it just looks like they got multiple validations for different modes. The one exception is Lancope, validation #288, which validated their use of Dual_EC_DRBG, but no other modes. So it looks like there's at least one implementation at use in the wild. - Tim * - The implementors that NIST listshttp://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html are: RSA, Certicom, Cisco, Juniper, BlackBerry, OpenPeak, OpenSSL, Microsoft, Mocana, ARX, Cummings Engineering Consultants, Catbird, Thales e-Security, SafeLogic, Panzura, SafeNet, Kony, Riverbed, and Symantec. (I excluded validations where the implementation clearly appears to be licensed, but people can name it anything they want, and some of the above are probably just OpenSSL forks, etc.) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 6/09/13 04:50 AM, Peter Gutmann wrote: Perry E. Metzger pe...@piermont.com writes: At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. It isn't the whiners that are the NSA plants, but the people behind them, egging them on, while also mounting attacks on the competent honest ones to confuse and bewilder them. I think you're ascribing way too much of the usual standards committee crapification effect to enemy action. The general process is first to push the group into crap, and then to influence it with competence. In order to influence, the group's own competence must be neutralised first. For example I've had an RFC draft for a trivial (half a dozen lines of code) fix for a decade of oracle attacks and whatnot on TLS sitting there for ages now and can't get the TLS WG chairs to move on it (it's already present in several implementations because it's so simple, but without a published RFC no-one wants to come out and commit to it). Does that make them NSA plants? There's drafts for one or two more fairly basic fixes to significant problems from other people that get stalled forever, while the draft for adding sound effects to the TLS key exchange gets fast-tracked. It's just what standards committees do. And, controlling processes is just what the NSA does. https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html The process of an inside takeover is well known in *certain* circles. It only takes one or two very smart competent people to take down an entire organisation. The mechanisms might well be described as crapification then exploitation. This is not to say that the IETF WG chairs are NSA plants, nor that all or any particular IETF committee is sunk. Rather, it is to say that it is very difficult to stop a committee being hopeless, and it's rather easy to tip a good committee into it. (If anyone knows of a way of breaking the logjam with TLS, let me know). In contrast, it is not well known how to repair the damage once done. The normal method is to abandon ship, swim away, build another ship with 1 or 2 others. Peter. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 2013-09-06 12:31 PM, Jerry Leichter wrote: Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. Elsewhere, enabling access and exploiting systems of interest and inserting vulnerabilities. These are all side-channel attacks. I see no other reference to cryptanalysis, so I would take this statement at face value: NSA has techniques for doing cryptanalysis on certain algorithms/protocols out there, but not all, and they would like to steer public cryptography into whatever areas they have attacks against. This makes any NSA recommendation *extremely* suspect. As far as I can see, the bit push NSA is making these days is toward ECC with some particular curves. The mathematics of ECC is such that one would expect that curves with backdoors that are difficult to find, or impossible to find except through construction, exist. Therefore, one should never employ a particular curve recommended by NSA, but rather a random or arbitrary curve. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 6/09/13 11:32 AM, ianG wrote: And, controlling processes is just what the NSA does. https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html Oops, for those unfamiliar with CAcert's peculiar use of secure browsing, drop the 's' in the above URL. Then it will securely load. (thanks Joe!) iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, 6 Sep 2013 09:03:27 +0200 Kristian Gjøsteen kristian.gjost...@math.ntnu.no wrote: As a co-author of an analysis of Dual-EC-DRBG that did not emphasize this problem (we only stated that Q had to be chosen at random, Ferguson co were right to emphasize this point), I would like to ask: Has anyone, anywhere ever seen someone use Dual-EC-DRBG? I mean, who on earth would be daft enough to use the slowest possible DRBG? If this is the best NSA can do, they are over-hyped. (If you really do want to use Dual-EC-DRBG: truncate more than 16 bits, and don't use NSA's points, choose your own - at random.) I have re-read the NY Times article. It appears to only indicate that this was *a* standard that was sabotaged, not that it was the only one. In particular, the Times merely indicates that they can now confirm that this particular standard was sabotaged, but presumably it was far from the only target. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
ianG i...@iang.org writes: And, controlling processes is just what the NSA does. https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html How does '(a) Organizations and Conferences' differ from SOP for these sorts of things? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Following up on my own posting: [The NSA] want to buy COTS because it's much cheap, and COTS is based on standards. So they have two contradictory constraints: They want the stuff they buy secure, but they want to be able to break in to exactly the same stuff when anyone else buys it. [Y]ou have to explain how the goal in NSA's budget [of influencing the commercial crypto community to move in directions NSA can attack] could be carried out in a way consistent with the two constraints. So here's a thought experiment for a particular approach: Imagine that it's the case that half of all possible AES keys are actually pseudo-weak, in the sense that if you use one of them, some NSA cryptanalytic technique can recover the rest of your key with acceptable (to NSA) effort. Their attack fails for the other half of all possible keys. Further, imagine that NSA has a recognizer for pseudo-weak keys. Then their next step is simple: Get the crypto industry to use AES with good, randomizing key generation techniques. Make sure that there is more than one approved key generation technique, ideally even a way for new techniques to be added in later versions of the standard, so that approved implementations have to allow for a choice, leading them to separate key generation from key usage. For the stuff *they* use, add another choice, which starts with one of the others and simply rejects pseudo-weak keys (or modifies them in some way to produce strong keys.) T hen: - Half of all messages the world sends are open to attack by NSA until the COTS producers learn of the attack and modify their fielded systems; - All messages NSA is responsible for are secure, even if the attack becomes known to other cryptanalytic services. I would think NSA would be very happy with such a state of affairs. (If they could arrange it that 255/256 keys are pseudo-weak - well, so much the better.) Is such an attack against AES *plausible*? I'd have to say no. But if you were on the stand as an expert witness and were asked under cross-examination Is this *possible*?, I contend the only answer you could give is I suppose so (with tone and body language trying to signal to the jury that you're being forced to give an answer that's true but you don't in your gut believe it). Could an encryption algorithm be explicitly designed to have properties like this? I don't know of any, but it seems possible. I've long suspected that NSA might want this kind of property for some of its own systems: In some cases, it completely controls key generation and distribution, so can make sure the system as fielded only uses good keys. If the algorithm leaks without the key generation tricks leaking, it's not just useless to whoever grabs onto it - it's positively hazardous. The gun that always blows up when the bad guy tries to shoot it -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 6/09/13 08:04 AM, John Kelsey wrote: It is possible Dual EC DRBG had its P and Q values generated to insert a trapdoor, though I don't think anyone really knows that (except the people who generated it, but they probably can't prove anything to us at this point). It's also immensely slower than the other DRBGs, and I have a hard time seeing why anyone would use it. (But if you do, you should generate your own P and Q.) Think bigger picture, think about the intervention possibilities. E.g., when the NSA goes to a major commercial supplier who is about to ship some product that is SP 800-90, they can agree to indeed do that, but switch around to the Dual EC DBRG. And still maintain their standards compliance. As it is likely a closed source, hush-hush area, it can even be done without the adversary (who was once called the customer) knowing. ... Where do the world's crypto random numbers come from? My guess is some version of the Windows crypto api and /dev/random or /dev/urandom account for most of them. I'm starting to think that I'd probably rather type in the results of a few dozen die rolls every month in to my critical servers and let AES or something similar in counter mode do the rest. A d20 has a bit more than 4 bits of entropy. I can get 256 bits with 64 die rolls, or, if I have eight dice, 16 rolls of the group. If I mistype when entering the info, no harm is caused. The generator can be easily tested for correct behavior if it is simply a block cipher. If you're trying to solve the problem of not trusting your entropy source, this is reasonable, but it doesn't exactly scale to normal users. Entropy collection in software is a pain in the ass, and my guess is that the overwhelming majority of developers are happy to punt and just use the OS' random numbers. Right. If you don't care, just use what the OS provides. /dev/urandom or CAPI or whatever. If you do care, you should implement a collector-mixer-DRBG design yourself. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 6, 2013, at 4:42 AM, Jerry Leichter leich...@lrw.com wrote: Argh! And this is why I dislike using symmetric and asymmetric to describe cryptosystems: In English, the distinction is way too brittle. Just a one-letter difference - and in including or not the letter physically right next to the s. This is why I try to say public key and symmetric key whenever possible. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKnGAsTedWZOD3gYRAhWzAJ9HfLc3nVuzIGMrywrY83vi63AlLgCeJdhJ NytYPZWee7tNMqdjI5TMkhQ= =vdDZ -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 6, 2013, at 6:23 AM, Jerry Leichter leich...@lrw.com wrote: Is such an attack against AES *plausible*? I'd have to say no. But if you were on the stand as an expert witness and were asked under cross-examination Is this *possible*?, I contend the only answer you could give is I suppose so (with tone and body language trying to signal to the jury that you're being forced to give an answer that's true but you don't in your gut believe it). I'd be happy to give a different answer, like -- almost certainly not. Could an encryption algorithm be explicitly designed to have properties like this? I don't know of any, but it seems possible. I've long suspected that NSA might want this kind of property for some of its own systems: In some cases, it completely controls key generation and distribution, so can make sure the system as fielded only uses good keys. If the algorithm leaks without the key generation tricks leaking, it's not just useless to whoever grabs onto it - it's positively hazardous. The gun that always blows up when the bad guy tries to shoot it We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. To me, it's like getting a cheap supply of gold and then deciding you'll make bullets out of it instead of lead. To riff on that analogy, it feels like you're suggesting that they would shoot themselves in the foot because they know that the bullet fragments will hurt their opponent. That's why I say almost certainly not. It suggests irrationality beyond my personal ken. It's something I classify colloquially as too stupid to live. My assumptions about the NSA are that they're smart, clever, and practical. Conjectures about their behavior that deviate from any of those axes ring false to the degree that they deviate from that. My conjectures start with assuming they're at least as smart as me, and I start with what would I do if I were them? I think they're smart enough not to attack the strong points of the system, but the weak points. I think they're smart enough to prefer operating in stealth. Yeah, yeah, sure, if with those resources I stumbled into a fundamental mathematical advantage, I'd use it. But I would use it to maximize my gain, not to be gratuitously sneaky. The math we know about block ciphers suggests (not proves, suggests) that a back door in a cipher is impractical, because it would imply the holy grail of public key systems -- fast, secure, public key crypto. It suggests secure trapdoor functions that can be made out of very simple components. If I found one, it would be great, but I'd devote my resources to places where I technology is on my side. Those include network security and software security, along with traffic analysis. If I wanted to devote research resources, I'd be looking closely at language-theoretic security. I'd be paying close attention to the fantastic things that have come out of there. The stuff that Bangert, Bratus, Shapiro, and Smith did on turning an MMU into a Turing machine is where I'd devote research, as well as their related work on weird machines. I apologize for repeating myself, but I'd fight the next war, not the last one. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKno7sTedWZOD3gYRAjMUAJ9qDQcQZVr/1580qZStlu/7fFgLIwCg2U5r WFth65Vi4GIDF1wu5oVukYs= =M/f+ -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
...and to add to all that, how about the fact that IPsec was dropped as a 'must implement' from IPv6 sometime after 2002? signature.asc Description: Message signed with OpenPGP using GPGMail ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 9/6/2013 1:05 PM, Perry E. Metzger wrote: I have re-read the NY Times article. It appears to only indicate that this was *a* standard that was sabotaged, not that it was the only one. In particular, the Times merely indicates that they can now confirm that this particular standard was sabotaged, but presumably it was far from the only target. WEP was so bad it's hard to think anyone could have done that intentionally. OTOH, stupidity usually wins out over malice. Besides, I don't believe that WEP fits the other attributes of the story. But seriously, sabotage can manifest itself in a lot of different ways. Perhaps their HUMINT promoted attitudes of jealously and backstabbing. Those means would likely be more efficient means to get something you want. Eventually everyone gets weary and will agree on practically anything even if it isn't near optimal, especially it it had been suggested early on and then discarded because the committee decided they could do better. There's also politics, bribes, and other gratuity they might offer. There's more than one one to dumb down standards besides just suggesting the wording of some crypto details which is what everyone seems to be assuming they did. Maybe all they did was encourage an dumb idea that someone else offered. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 6, 2013, at 8:22 PM, John Gilmore g...@toad.com 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: ...and to add to all that, how about the fact that IPsec was dropped as a 'must implement' from IPv6 sometime after 2002? signature.asc Description: Message signed with OpenPGP using GPGMail ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 6, 2013, at 8:58 PM, Jon Callas wrote: I've long suspected that NSA might want this kind of property for some of its own systems: In some cases, it completely controls key generation and distribution, so can make sure the system as fielded only uses good keys. If the algorithm leaks without the key generation tricks leaking, it's not just useless to whoever grabs onto it - it's positively hazardous. The gun that always blows up when the bad guy tries to shoot it We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. I'm sorry, but this is just nonsense. You're starting with informal, rough definitions and claiming a mathematical theorem. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. I said all this before. A back door doesn't have to be fast. It doesn't have to be implementable using amounts of memory that are practical for a fielded system. It may require all kinds of expensive pre-computation to be useful at all. It just has to allow practical attacks. A back door that reduced the effective key size of AES to 40 bits would amount to an effective break of AES, but would be a public key system only in some very technical and uninteresting sense. And none of this is relevant to whether one could have a system with many weak keys. Some kind of structure in the round computation structure would be an obvious place to look. In fact, now that I think of it, here's a rough example of such a system: Take any secure round-based block cipher and decide that you're not going to use a round computation at all - you'll let the user specify the full expanded per-round key. (People proposed doing this with DES as a way of getting beyond the 56-bit key size. It didn't work - DES is inherently good for no more than 56 bits, more or less. In general doing this with any decent block cipher won't make it any stronger. But that's not the point of the example.) There are now many weak keys - all kinds of repetitive structures allow for slide attacks, for example. Every bad way of designing a round computation corresponds to a set of weak full keys. On the other hand, for a certain subset of the keys - those that could have been produced by the original (good) round computation - it's *exactly* the original cipher, with *exactly* the original security guarantees. If I carefully use only keys from that se t, I've lost nothing (other than wasted space for a key longer than it needs to be). So now I have a block cipher that has two sets of keys. One set makes it as secure as the original cipher; one set makes it easy to break - my back door. Have I just invented a new public key system? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
OK how about this: If a person at Snowden's level in the NSA had any access to information that indicated the existence of any program which involved the successful cryptanalysis of any cipher regarded as 'strong' by this community then the Director of National Intelligence, the Director of the NSA and everyone involved in those decisions should be fired immediately and lose their pensions. What was important in Ultra was the fact that the Germans never discovered they were being intercepted and decrypted. They would have strengthened their cipher immediately if they had known it was broken. So either the NSA has committed an unpardonable act of carelessness (beyond the stupidity of giving 50,000 people like Snowden access to information that should not have been shared beyond 500) or the program involves lower strength ciphers that we would not recommend the use of but are still there in the cipher suites. I keep telling people that you do not make a system more secure by adding the choice of a stronger cipher into the application. You make the system more secure by REMOVING the choice of the weak ciphers. I would bet that there is more than enough DES traffic to be worth attack and probably quite a bit on IDEA as well. There is probably even some 40 and 64 bit crypto in use. Before we assume that the NSA is robbing banks by using an invisibility cloak lets consider the likelihood that they are beating up old ladies and taking their handbags. On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Informed speculation means intelligent, technical ideas about what has been done. It does not mean wild conspiracy theories and the like. I will be instructing the moderators (yes, I have help these days) to ruthlessly prune inappropriate material. At the same time, I will repeat that reasonably informed technical speculation is appropriate, as is any solid information available. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 5, 2013 at 4:57 PM, Perry E. Metzger pe...@piermont.com wrote: On Thu, 5 Sep 2013 16:53:15 -0400 Perry E. Metzger pe...@piermont.com wrote: Anyone recognize the standard? Please say it aloud. (I personally don't recognize the standard offhand, but my memory is poor that way.) There is now some speculation in places like twitter that this refers to Dual_EC_DRBG though I was not aware that was widely enough deployed to make a huge difference here, and am not sure which international group is being mentioned. I would be interested in confirmation. I believe it is Dual_EC_DRBG. The ProPublica storyhttp://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryptionsays: Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” This appears to describe the NIST SP 800-90 situation pretty precisely. I found Schneier's contemporaneous article to be good at refreshing my memory: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 - Tim ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 09/05/2013 01:57 PM, Perry E. Metzger wrote: and am not sure which international group is being mentioned. ISO. Not that narrows it down much. Eric ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 5 Sep 2013 at 16:11, Phillip Hallam-Baker wrote: I would bet that there is more than enough DES traffic to be worth attack and probably quite a bit on IDEA as well. There is probably even some 40 and 64 bit crypto in use. Indeed -- would you (or any of us) guess that NSA could break TDES these days? /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA -- Too many people, too few sheep -- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
The NYT article is pretty informative: (http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html) Because strong encryption can be so effective, classified N.S.A. documents make clear, the agency’s success depends on working with Internet companies — by getting their voluntary collaboration, forcing their cooperation with court orders or surreptitiously stealing their encryption keys or altering their software or hardware. N.S.A. documents show that the agency maintains an internal database of encryption keys for specific commercial products, called a Key Provisioning Service, which can automatically decode many messages. If the necessary key is not in the collection, a request goes to the separate Key Recovery Service, which tries to obtain it. How keys are acquired is shrouded in secrecy, but independent cryptographers say many are probably collected by hacking into companies’ computer servers, where they are stored Also interesting: Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology, the United States’ encryption standards body, and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” “Eventually, N.S.A. became the sole editor,” the memo says. Anyone recognize the standard? Eric ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
First, I don't think it has anything to do with Dual EC DRGB. Who uses it? My impression is that most of the encryption that fits what's in the article is TLS/SSL. That is what secures most encrypted content going online. The easy way to compromise that in a passive attack is to compromise servers' private keys, via cryptanalysis or compromise or bad key generation. For server side TLS using RSA, guessing just the client's random values ought to be enough to read the traffic. For active attacks, getting alternative certs issued for a given host and playing man in the middle would work. Where do the world's crypto random numbers come from? My guess is some version of the Windows crypto api and /dev/random or /dev/urandom account for most of them. What does most of the world's TLS? OpenSSL and a few other libraries, is my guess. But someone must have good data about this. My broader question is, how the hell did a sysadmin in Hawaii get hold of something that had to be super secret? He must have been stealing files from some very high ranking people. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What surprises me is that anyone is surprised. If you believed OpenBSD's Theo de Raadt and Gregory Perry back in late 2010, various government agencies (in this specific case the FBI- though one wonders if they were the originating agency) have been looking to introduce weaknesses wholesale into closed AND open source software and OS infrastructures for some time. Over a decade in his example. (See: http://marc.info/?l=openbsd-techm=129236621626462w=2) Those of us old enough might marvel at the fact that going back to the late 1980s a huge dust up was caused by the allegations that Swiss firm Crypto AG introduced backdoors into their products at the behest of Western (read: United States and the BND) intelligence agencies, products that, at the time, were in widespread use by foreign governments who, one presumes, could not afford to field their own national cryptology centers to protect their own infrastructure (or were just lazy and seduced by a Swiss flag on the corporate domicile of Crypto AG). For the unwashed on the list, Wikipedia (and Der Spiegel) relate the story of (probably) hapless Crypto AG salesman Hans Buehler's 1992 arrest by the Iranian authorities after those allegations came to light, and the fact that Crypto AG paid a $1m ransom for him (but then later billed him for the $1m--you stay classy, Crypto AG). (See: http://en.wikipedia.org/wiki/Crypto_AG) But fear not. Governments and NGOs around the world will be pleased to know that Crypto AG lives on and continues to provide superior crypto and security solutions to foreign institutions of all kinds, including: National security councils, national competence centres, e-government authorities, encryption authorities, national banks, ministries of defence, combined/joint commands, cyber commands, air forces, land forces, naval forces, special forces, military intelligence services, defence encryption authorities, ministries of foreign affairs and numerous international organisations, ministries of the interior, presidential guards, critical infrastructure authorities, homeland security authorities, intelligence services, police forces, and cyber forces. (See: http://www.crypto.ch/ - The inclusion of a shot of the Patrouille Suisse is an especially nice touch. I often drive by their offices in Steinhausen and was stunned to realize a few years ago that they are thriving- I can only imagine what the mortgage on that place costs). I expect that today many of us feel quite naive at being shocked by those penetration revelations (sorry, allegations) given that it seems highly probable now that anyone using any sort of Microsoft, Cisco, Google, Facebook, Yahoo, YouTube, Skype, AOL or Apple product has now been elevated to a collection priority that seemed confined to the Irans of the world in the 1990s and early 2000s. Perry wondered after the unpardonable carelessness of the NSA in giving 50,000 Snowden's access to a Powerpoint with all the Prism partners. I would argue that the NSA had good cause to think no one would notice or care given how many people who should know MUCH MUCH better still send Crypto AG scads of money. And going back to the days of toad.com hasn't this always been the story? Security is expensive. Most people (and some governments) are cheap. There's something about the present political climate in the United States that really interests me. Mere mention of the word fascism in any context other than sarcasm seems to brand one quite instantly as a tin-foil nutjob. Granted, I think the world fascism is as overused as the word communism, but it bears mentioning that the usurpation of corporate entities and industry by the state to its own purposes is one of the classic tenants of fascism. I'm sure the list's readers sense where I'm going with this by now. It is hard to escape noticing that the NSA and its sister and orbital agencies have long since broken the traditional firewall and morphed themselves into domestic surveillance agencies. But the United States is late to the party here. In the world of finance it was long understood that certain state-dominated Russian firms were front-running a number of U.S. economic indicators prior to release. The rumor at the time was that this activity stopped cold after a security audit at the offending U.S. agencies. It's possible that the story was apocryphal, but I sort of doubt it. The economic intelligence apparatus of foreign intelligence services was the place to be if you wanted to find yourself in the good graces of your nation-state. (It's not an accident that Nikolay Patolichev, once the Soviet Union's Foreign Trade Minister, led the pack having been awarded the Order of Lenin twelve times). Of course, drafting otherwise independent-appearing private enterprises to the purposes of the state was popular then (the CIA would routinely interview U.S. businessmen and businesswomen after trips to jurisdictions
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013 19:14:53 -0400 John Kelsey crypto@gmail.com wrote: First, I don't think it has anything to do with Dual EC DRGB. Who uses it? It did *seem* to match the particular part of the story about a subverted standard that was complained about by Microsoft researchers. I would not claim that it is the most important part of the story. My impression is that most of the encryption that fits what's in the article is TLS/SSL. Yes, and if they have a real hole there they're exploiting, that is quite disturbing. If they're merely using a hodge-podge of techniques to get keys, it is less worrying. Where do the world's crypto random numbers come from? My guess is some version of the Windows crypto api and /dev/random or /dev/urandom account for most of them. I'm starting to think that I'd probably rather type in the results of a few dozen die rolls every month in to my critical servers and let AES or something similar in counter mode do the rest. A d20 has a bit more than 4 bits of entropy. I can get 256 bits with 64 die rolls, or, if I have eight dice, 16 rolls of the group. If I mistype when entering the info, no harm is caused. The generator can be easily tested for correct behavior if it is simply a block cipher. What does most of the world's TLS? OpenSSL and a few other libraries, is my guess. But someone must have good data about this. My broader question is, how the hell did a sysadmin in Hawaii get hold of something that had to be super secret? He must have been stealing files from some very high ranking people. I believe there was already discussion in the press on that latter point, but I think it is less germane to our discussion here and would prefer that we avoid speculating on things that are only of human/gossip interest. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013 16:53:15 -0400 Perry E. Metzger pe...@piermont.com wrote: Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” “Eventually, N.S.A. became the sole editor,” the memo says. Anyone recognize the standard? Please say it aloud. (I personally don't recognize the standard offhand, but my memory is poor that way.) There is now some speculation in places like twitter that this refers to Dual_EC_DRBG though I was not aware that was widely enough deployed to make a huge difference here, and am not sure which international group is being mentioned. I would be interested in confirmation. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 05 Sep 2013 13:33:48 -0700 Eric Murray er...@lne.com wrote: The NYT article is pretty informative: (http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html) [...] Also interesting: Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology, the United States’ encryption standards body, and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” “Eventually, N.S.A. became the sole editor,” the memo says. Anyone recognize the standard? Please say it aloud. (I personally don't recognize the standard offhand, but my memory is poor that way.) BTW, I will now openly speculate if the deeply undeployable key management protocols for IPSec that originated at the NSA were an accident. I had enough involvement not to feel overly strongly that this is what happened, but it does lead one to wonder strongly. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013 15:58:04 -0400 Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Here are a few guesses from me: 1) I would not be surprised if it turned out that some people working for some vendors have made code and hardware changes at the NSA's behest without the knowledge of their managers or their firm. If I were running such a program, paying off a couple of key people here and there would seem only rational, doubly so if the disclosure of their involvement could be made into a crime by giving them a clearance or some such. 2) I would not be surprised if some of the slow speed at which improved/fixed hashes, algorithms, protocols, etc. have been adopted might be because of pressure or people who had been paid off. At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. Whether I am correct or not, such behavior clearly serves the interest of those who would do bad things. 3) I would not be surprised if random number generator problems in a variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not. 4) Choices not to use things like Diffie-Hellman in TLS connections on the basis that it damages user experience and the like should be viewed with enormous suspicion. 5) Choices not to make add-ons available in things like chat clients or mail programs that could be used for cryptography should be viewed with suspicion. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Informed speculation means intelligent, technical ideas about what has been done. It does not mean wild conspiracy theories and the like. I will be instructing the moderators (yes, I have help these days) to ruthlessly prune inappropriate material. At the same time, I will repeat that reasonably informed technical speculation is appropriate, as is any solid information available. http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security • The NSA spends $250m a year on a program which, among other goals, works with technology companies to covertly influence their product designs. I believe this confirms my theory that the NSA has plants in the IETF to discourage moves to strong crypto. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 5, 2013 at 4:41 PM, Perry E. Metzger pe...@piermont.com wrote: On Thu, 5 Sep 2013 15:58:04 -0400 Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Here are a few guesses from me: 1) I would not be surprised if it turned out that some people working for some vendors have made code and hardware changes at the NSA's behest without the knowledge of their managers or their firm. If I were running such a program, paying off a couple of key people here and there would seem only rational, doubly so if the disclosure of their involvement could be made into a crime by giving them a clearance or some such. Or they contacted the NSA alumni working in the industry. 2) I would not be surprised if some of the slow speed at which improved/fixed hashes, algorithms, protocols, etc. have been adopted might be because of pressure or people who had been paid off. At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. Whether I am correct or not, such behavior clearly serves the interest of those who would do bad things. I think it is subtler that that. Trying to block a strong cipher is too obvious. Much better to push for something that is overly complicated or too difficult for end users to make use of. * The bizare complexity of IPSEC. * Allowing deployment of DNSSEC to be blocked in 2002 by blocking a technical change that made it possible to deploy in .com. * Proposals to deploy security policy information (always send me data encrypted) have been consistently filibustered by people making nonsensical objections. 3) I would not be surprised if random number generator problems in a variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not. Agreed, the PRNG is the easiest thing to futz with. It would not surprise me if we discovered kleptography at work as well. 4) Choices not to use things like Diffie-Hellman in TLS connections on the basis that it damages user experience and the like should be viewed with enormous suspicion. 5) Choices not to make add-ons available in things like chat clients or mail programs that could be used for cryptography should be viewed with suspicion. I think the thing that discouraged all that was the decision to make end user certificates hard to obtain (still no automatic spec) and expire after a year. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 05 Sep 2013 16:43:59 -0400 Bernie Cosell ber...@fantasyfarm.com wrote: On 5 Sep 2013 at 16:11, Phillip Hallam-Baker wrote: I would bet that there is more than enough DES traffic to be worth attack and probably quite a bit on IDEA as well. There is probably even some 40 and 64 bit crypto in use. Indeed -- would you (or any of us) guess that NSA could break TDES these days? The articles make it sound much more like implementation flaws that have been intentionally placed in software and hardware, and a select few bad protocols and standards. I'm not going to say that it is impossible that they can break 3DES at this point, but it doesn't sound like that's what is being discussed here. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Bruce Schneier explains the Dual_EC_DRBG attack: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Hi all, If you read the articles carefully, you'll note that at no point does the NSA appear to have actually broken the *cryptography* in use. It's hard to get concrete details from such vague writing and no access to the the original documents, but it sounds like they've mostly gotten a lot of backdoors in *systems* (not algorithms, though they may have tried that with Dual_EC_DRBG in NIST SP 800-90 in 2006 ... which lasted barely a year before public cryptographers flagged it). Basically, the summary of this new information appears to be best given by Paul Kocher, who noted that the NSA had pushed for a backdoor key escrow system with the Clipper Chip, was denied, ... and they went and did it anyway, without telling anyone. In this case, it wasn't a mandated key escrow backdoor, but through a combination of targeted interception and strong-arming companies like Google and Microsoft, they got enough. It's the same old story of crypto in the real world: Don't attack the algorithm; Attack the system. Better story here: http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Informed speculation means intelligent, technical ideas about what has been done. It does not mean wild conspiracy theories and the like. I will be instructing the moderators (yes, I have help these days) to ruthlessly prune inappropriate material. At the same time, I will repeat that reasonably informed technical speculation is appropriate, as is any solid information available. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Lance James http://soundcloud.com/lancejames Office: 760-262-4141 l lan...@securescience.netan...@gmail.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
[This drifts from the thread topic; feel free to attach a different subject line to it] On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote: 3) I would not be surprised if random number generator problems in a variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not. Random number generators make for a very interesting target. Getting decent amounts of entropy on conventional machines is very difficult. Servers have almost no random variation in their environments; desktops somewhat more; modern laptops, yet more. Virtualization - now extremely common on the server side - makes things even harder. But even laptops don't have much. So we're left trying to distill enough randomness for security - a process that's error-prone and difficult to check. So ... along comes Intel with a nice offer: Built-in randomness on their latest chips. Directly accessible to virtual machines, solving the very difficult problems they pose. The techniques used to generate that randomness are published. But ... how could anyone outside a few chip designers at Intel possibly check that the algorithm wasn't, in some way, spiked? For that matter, how could anyone really even check that the outputs of the hardware Get Random Value instruction were really generated by the published algorithm? Randomness is particularly tricky because there's really no way to test for a spiked random number generator (unless it's badly spiked, of course). Hell, every encryption algorithm is judged by its ability to generate streams of bits that are indistinguishable from random bits (unless you know the key). Now, absolutely, this is speculation. I know of no reason to believe that the NSA, or anyone else, has influenced the way Intel generates randomness; or that there is anything at all wrong with Intel's implementation. But if you're looking for places an organization like the NSA would really love to insert itself - well, it's hard to pick a better one. Interestingly, though, there's good news here as well. While it's hard to get at sources of entropy in things like servers, we're all carrying computers with excellent sources of entropy in our pockets. Smartphones have access to a great deal of environmental data - accelerometers, one or two cameras, one or two microphones, GPS, WiFi, and cell signal information (metadata, data, signal strength) - more every day. This provides a wealth of entropy, and it's hard to see how anyone could successfully bias more than a small fraction of it. Mix these together properly and you should be able to get extremely high quality random numbers. Normally, we assume code on the server side is better and should take the major role in such tasks as providing randomness. Given what we know now about the ability of certain agencies to influence what runs on servers, *in general*, we need to move trust away from them. The case is particularly strong in the case of randomness. Of course, there's a whole other layer of issue introduced by the heavily managed nature of phone software. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 5, 2013, at 7:14 PM, John Kelsey wrote: My broader question is, how the hell did a sysadmin in Hawaii get hold of something that had to be super secret? He must have been stealing files from some very high ranking people. This has bothered me from the beginning. Even the first leaks involved material that you would expect to only be available to highly trusted people *well up in the organization* - they were slides selling capabilities to managers and unlikely to be shown to typical employees, cleared or not. My immediate impression was that we were looking at some disgruntled higher-up. The fact that these are coming from a sysadmin - who would never have reason to get legitimate access to pretty much *any* of the material leaked so far - is a confirmation of a complete breakdown of NSA's internal controls. They seem to know how to do cryptography and cryptanalysis and all that stuff - but basic security and separation of privileges and internal monitoring ... that seems to be something they are just missing. Manning got to see all kinds of material that wasn't directly related to his job because the operational stuff was *deliberately* opened up in an attempt to get better analysis. While he obviously wasn't supposed to leak the stuff, he was authorized to look at it. I doubt the same could be said of Snowden. Hell, when I had a data center manager working for me, we all understood that just because root access *let* you look at everyone's files, you were not *authorized* to do so without permission. One of the things that must be keeping the NSA guys up night after night is: If Snowden could get away with this much without detection, who's to say what the Chinese or the Russians or who knows who else have managed to get? Have they spiked the spikers, grabbing the best stuff the NSA manages to find? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, 06 Sep 2013 12:13:48 +1200 Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Perry E. Metzger pe...@piermont.com writes: I would like to open the floor to *informed speculation* about BULLRUN. Not informed since I don't work for them, but a connect-the-dots: 1. ECDSA/ECDH (and DLP algorithms in general) are incredibly brittle unless you get everything absolutely perfectly right. I'm aware of the randomness issues for ECDSA, but what's the issue with ECDH that you're thinking of? 2. The NSA has been pushing awfully hard to get everyone to switch to ECDSA/ECDH. Yes, and 24 hours ago I would have said that was because they themselves depended on the use of commercial products with such algorithms available (as in Suite B.) Now I'm less sure. Wasn't Suite B promulgated in the 2005-2006 period? Yes, though it doesn't sound like Suite B is what the article meant when discussing standards. Peter (who choses RSA over ECC any time, follow a few basic rules and you're safe with RSA while ECC is vulnerable to all manner of attacks, including many yet to be discovered). Many people out there seem to claim the opposite of course. The current situation doesn't give us a definitive way to resolve such an argument. RSA certainly appears to require vastly longer keys for the same level of assurance as ECC. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
BULLRUN seems to be just an overarching name for several wide programs to obtain plaintext of passively encrypted internet communications by many different methods. While there seem to be many non-cryptographic attacks included in the BULLRUN program, of particular interest is the cryptographic attack mentioned in the Snowden papers and also hinted at in earlier US congressional manouverings for NSA funding. The most obvious target of attack is some widespread implementation of SSL/TLS, and while it might just be an attack against a reduced keyspace, eg password-guessing or RNG compromise, I wonder whether NSA have actually made a big cryptographic break against some cipher, and if so, against what? Candidate ciphers are: 3DES RC4 AES and key establishment mechanisms: RSA DH ECDH I don't think a break in another cipher or KEM would be widespread enough to matter much. Assuming NSA (or possibly GCHQ) have made a big break: I don't think it's against 3DES or RC4, though the latter is used a lot more than people imagine. AES? Maybe, but a break in AES would be a very big deal. I don't know whether hiding that would be politically acceptable. RSA? Well, maybe indeed. Break even a few dozen RSA keys per month, and you get a goodly proportion of all internet encrypted traffic. It's just another advance on factorisation. If you can break RSA you can probably break DH as well. ECDH? Again quite possible, especially against the curves in use - but perhaps a more widespread break against ECDH is possible as well. The math says that it can be done starting with a given curve (though we don't know how to do it), and you only need to do the hard part once per curve. My money? RSA. But even so, double encrypting with two different ciphers (and using two different KEMs) seems a lot more respectable now. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Perry E. Metzger pe...@piermont.com writes: I would like to open the floor to *informed speculation* about BULLRUN. Not informed since I don't work for them, but a connect-the-dots: 1. ECDSA/ECDH (and DLP algorithms in general) are incredibly brittle unless you get everything absolutely perfectly right. 2. The NSA has been pushing awfully hard to get everyone to switch to ECDSA/ECDH. Wasn't Suite B promulgated in the 2005-2006 period? Peter (who choses RSA over ECC any time, follow a few basic rules and you're safe with RSA while ECC is vulnerable to all manner of attacks, including many yet to be discovered). ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thursday, September 5, 2013, Jerry Leichter wrote: [This drifts from the thread topic; feel free to attach a different subject line to it] On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote: 3) I would not be surprised if random number generator problems in a variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not. Random number generators make for a very interesting target. Getting decent amounts of entropy on conventional machines is very difficult. Servers have almost no random variation in their environments; desktops somewhat more; modern laptops, yet more. Virtualization - now extremely common on the server side - makes things even harder. But even laptops don't have much. So we're left trying to distill enough randomness for security - a process that's error-prone and difficult to check. Virtual private servers are a very big problem. Virtual machine deployment systems at very large hosting providers have been found to use the same /dev/urandom initialization for many thousands of machines. It comes from not re-seeding from /dev/random on provisioning, and running with the same seed as was in the VM template when it was 'cut'. I know because I fixed it at places I worked as a contractor. I know at least one competitor had the issue. No knowledge if it was ever fixed there. Don't trust seeds you didn't generate. Think about Amazon AWS instances all spinning up on demand with the exact same init code and prng seed (this example is not the ones i dealt with, butnis perhaps a larger problem). You always have a window after startup where you can predicte the state of the kernel level prng. Not a big one, but it is real and in the wild. -David Mercer -- David Mercer - http://dmercer.tumblr.com IM: AIM: MathHippy Yahoo/MSN: n0tmusic Facebook/Twitter/Google+/Linkedin: radix42 FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Perry E. Metzger pe...@piermont.com writes: At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. I think you're ascribing way too much of the usual standards committee crapification effect to enemy action. For example I've had an RFC draft for a trivial (half a dozen lines of code) fix for a decade of oracle attacks and whatnot on TLS sitting there for ages now and can't get the TLS WG chairs to move on it (it's already present in several implementations because it's so simple, but without a published RFC no-one wants to come out and commit to it). Does that make them NSA plants? There's drafts for one or two more fairly basic fixes to significant problems from other people that get stalled forever, while the draft for adding sound effects to the TLS key exchange gets fast-tracked. It's just what standards committees do. (If anyone knows of a way of breaking the logjam with TLS, let me know). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, 06 Sep 2013 13:50:54 +1200 Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Perry E. Metzger pe...@piermont.com writes: Does that make them NSA plants? There's drafts for one or two more fairly basic fixes to significant problems from other people that get stalled forever, while the draft for adding sound effects to the TLS key exchange gets fast-tracked. It's just what standards committees do. Maybe. Yesterday I would have consistently ascribed things to bureaucracy instead of malice. Today, I'm less sure. At the very least, the current revelations make such things less benevolent -- whether from malice or stupidity, we can no longer sit on security fixes on the basis that no one will exploit them and they're not important to the user. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2013, at 7:01 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Perry E. Metzger pe...@piermont.com writes: I'm aware of the randomness issues for ECDSA, but what's the issue with ECDH that you're thinking of? It's not just randomness, it's problems with DLP-based crypto in general. For example there's the scary tendency of DLP-based ops to leak the private key (or at least key bits) if you get even the tiniest thing wrong. For example if you follow DSA's: k = G(t,KKEY) mod q then you've leaked your x after a series of signatures, so you need to know that you generate a large-than-required value before reducing mod q. The whole DLP family is just incredibly brittle. I don't disagree by any means, but I've been through brittleness with both discrete log and RSA, and it seems like only a month ago that people were screeching to get off RSA over to ECC to avert the cryptocalypse. And that the ostensible reason was that there are new discrete log attacks -- which was just from Mars and I thought that that proved the people didn't know what they were talking about. Oh, wait, it *was* only a month ago! Silly me. Crypto experts issue a call to arms to avert the cryptopocalypse http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/ Discrete log has brittleness. RSA has brittleness. ECC is discrete log over a finite field that's hard to understand. It all sucks. RSA certainly appears to require vastly longer keys for the same level of assurance as ECC. That's assuming that the threat is cryptanalysis rather than bypass. Why bother breaking even 1024-bit RSA when you can bypass? And now we're back to the hymnal you and I have been singing from. It ain't the crypto, it's the software. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKTuhsTedWZOD3gYRAhiJAKDaNIw1ztD/Lj1WAW3U/pOtkpoybQCgoW6o nd08pq+l1QiViF7cPATuPig= =Z3wh -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
The actual documents - some of which the Times published with few redactions - are worthy of a close look, as they contain information beyond what the reporters decided to put into the main story. For example, at http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?ref=uspagewanted=all, the following goal appears for FY 2013 appears: Complete enabling for [redacted] encryption chips used in Virtual Public Network and Web encryption devices. The Times adds the following note: Large Internet companies use dedicated hardware to scramble traffic before it is sent. In 2013, the agency planned to be able to decode traffic that was encoded by one of these two encryption chips, either by working with the manufacturers of the chips to insert back doors or by exploiting a security flaw in the chips' design. It's never been clear whether these kinds of notes are just guesses by the reporters, come from their own sources, or com e from Snowden himself. The Washington Post got burned on one they wrote. But in this case, it's hard to come up with an alternative explanation. Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. Elsewhere, enabling access and exploiting systems of interest and inserting vulnerabilities. These are all side-channel attacks. I see no other reference to cryptanalysis, so I would take this statement at face value: NSA has techniques for doing cryptanalysis on certain algorithms/protocols out there, but not all, and they would like to steer public cryptography into whatever areas they have attacks against. This makes any NSA recommendation *extremely* suspect. As far as I can see, the bit push NSA is making these days is toward ECC with some particular curves. Makes you wonder. (I know for a fact that NSA has been interested in this area of mathematics for a *very* long time: A mathematician I knew working in the area of algebraic curves (of which elliptic curves are an example) was re cruited by - and went to - NSA in about 1975. I heard indirectly from him after he was at NSA, where he apparently joined an active community of people with related interests. This is a decade before the first public suggestion that elliptic curves might be useful in cryptography. (But maybe NSA was just doing a public service, advancing the mathematics of algebraic curves.) NSA has two separate roles: Protect American communications, and break into the communications of adversaries. Just this one example shows that either (a) the latter part of the mission has come to dominate the former; or (b) the current definition of an adversary has become so broad as to include pretty much everyone. Now, the NSA will say: Only *we* can make use of these back doors. But given the ease with which Snowden got access to so much information ... why should we believe they can keep such secrets? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2013, at 7:31 PM, Jerry Leichter leich...@lrw.com wrote: Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. Elsewhere, enabling access and exploiting systems of interest and inserting vulnerabilities. These are all side-channel attacks. I see no other reference to cryptanalysis, so I would take this statement at face value: NSA has techniques for doing cryptanalysis on certain algorithms/protocols out there, but not all, and they would like to steer public cryptography into whatever areas they have attacks against. This makes any NSA recommendation *extremely* suspect. As far as I can see, the bit push NSA is making these days is toward ECC with some particular curves. Makes you wonder. Yes, but. The reason we are using those curves is because they want them for products they buy. (I know for a fact that NSA has been interested in this area of mathematics for a *very* long time: A mathematician I knew working in the area of algebraic curves (of which elliptic curves are an example) was re cruited by - and went to - NSA in about 1975. I heard indirectly from him after he was at NSA, where he apparently joined an active community of people with related interests. This is a decade before the first public suggestion that elliptic curves might be useful in cryptography. (But maybe NSA was just doing a public service, advancing the mathematics of algebraic curves.) I think it might even go deeper than that. ECC was invented in the civilian world by Victor Miller and Neal Koblitz (independently) in 1985, so they've been planning for breaking it even a decade before its invention. NSA has two separate roles: Protect American communications, and break into the communications of adversaries. Just this one example shows that either (a) the latter part of the mission has come to dominate the former; or (b) the current definition of an adversary has become so broad as to include pretty much everyone. I definitely believe (b). However, I also think that they aren't a monolith, and we know that each part of the mission is the adversary of the other. I don't believe that the IA people would do a bad job to support SIGINT. Once you start down that path, it's easy to get to madness, or perhaps merely evidence that they have time travel. I'll add that they have a third mission -- run the government's classified computer network, and that *that* mission is the one that Snowden worked for. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKUQLsTedWZOD3gYRAlZvAKCtZP9iy1eyGBq4UbG9xO9jmNscigCZAYVv M13sxiFZ5ch7PhgoIh1LziA= =fEtw -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sep 5, 2013, at 10:19 PM, Jon Callas wrote: I don't disagree by any means, but I've been through brittleness with both discrete log and RSA, and it seems like only a month ago that people were screeching to get off RSA over to ECC to avert the cryptocalypse. And that the ostensible reason was that there are new discrete log attacks -- which was just from Mars and I thought that that proved the people didn't know what they were talking about. Oh, wait, it *was* only a month ago! Silly me. Crypto experts issue a call to arms to avert the cryptopocalypse http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/ Discrete log has brittleness. RSA has brittleness. ECC is discrete log over a finite field that's hard to understand. It all sucks. Perhaps it's time to move away from public-key entirely! We have a classic paper - Needham and Schroeder, maybe? - showing that private key can do anything public key can; it's just more complicated and less efficient. Not only are the techniques brittle and increasingly under suspicion, but in practice almost all of our public key crypto inherently relies on CA's - a structure that's just *full* of well-known problems and vulnerabilities. Public key *seems to* distribute the risk - you just get the other guy's public key and you can then communicate with him safely. But in practice it *centralizes* risks: In CA's, in single magic numbers that if revealed allow complete compromise for all connections to a host (and we now suspect they *are* being revealed.) We need to re-think everything about how we do cryptography. Many decisions were made based on hardware limitations of 20 and more years ago. More efficient claims from the 1980's often mean nothing today. Many decisions assumed trust models (like CA's) that we know are completely unrealistic. Mobile is very different from the server-to-server and dumb-client-to-server models that were all anyone thought about the time. (Just look at SSL: It has the inherent assumption that the server *must* be authenticated, but the client ... well, that's optional and rarely done.) None of the work then anticipated the kinds of attacks that are practical today. I pointed out in another message that today, mobile endpoints potentially have access to excellent sources of randomness, while servers have great difficulty getting good random numbers. This is the kind of fundamental change that needs to inform new designs. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. ... This makes any NSA recommendation *extremely* suspect. As far as I can see, the bit push NSA is making these days is toward ECC with some particular curves. Makes you wonder. Yes, but. The reason we are using those curves is because they want them for products they buy. They want to buy COTS because it's much cheap, and COTS is based on standards. So they have two contradictory constraints: They want the stuff they buy secure, but they want to be able to break in to exactly the same stuff when anyone else buys it. The time-honored way to do that is to embed some secret in the design of the system. NSA, knowing the secret, can break in; no one else can. There have been claims in this direction since NSA changed the S-boxes in DES. For DES, we now know that was to protect against differential cryptanalysis. No one's ever shown a really convincing case of such an embedded secret hack being done ... but now if you claim it can't happen, you have to explain how the goal in NSA's budget could be carried out in a way consistent with the two constraints. Damned if I know (I know for a fact that NSA has been interested in this area of mathematics for a *very* long time: A mathematician I knew working in the area of algebraic curves (of which elliptic curves are an example) was recruited by - and went to - NSA in about 1975 I think it might even go deeper than that. ECC was invented in the civilian world by Victor Miller and Neal Koblitz (independently) in 1985, so they've been planning for breaking it even a decade before its invention. I'm not sure exactly what you're trying to say. Yes, Miller and Koblitz are the inventors of publicly known ECC, and a number of people (Diffie, Hellman, Merkle, Rivest, Shamir, Adelman) are the inventors of publicly known public-key cryptography. But in fact we now know that Ellis, Cocks, and Williamson at GCHQ anticipated their public key cryptography work by several years - but in secret. I think the odds are extremely high that NSA was looking at cryptography based on algebraic curves well before Miller and Koblitz. Exactly what they had developed, there's no way to know. But of course if you want to do good cryptography, you also have to do cryptanalysis. So, yes, it's quite possible that NSA was breaking ECC a decade before its (public) invention. :-) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2013, at 8:02 PM, Jerry Leichter leich...@lrw.com wrote: Perhaps it's time to move away from public-key entirely! We have a classic paper - Needham and Schroeder, maybe? - showing that private key can do anything public key can; it's just more complicated and less efficient. Not really. The Needham-Schroeder you're thinking of is the essence of Kerberos, and while Kerberos is a very nice thing, it's hardly a replacement for public key. If you use a Needham-Schroeder/Kerberos style system with symmetric key systems, you end up with all of the trust problems, but on steroids. (And by the way, please say symmetric key as opposed to public key -- if you say private key then someone will inevitably get confused and think you mean the private half of a public key pair and there will be tears.) Not only are the techniques brittle and increasingly under suspicion, but in practice almost all of our public key crypto inherently relies on CA's - a structure that's just *full* of well-known problems and vulnerabilities. Public key *seems to* distribute the risk - you just get the other guy's public key and you can then communicate with him safely. But in practice it *centralizes* risks: In CA's, in single magic numbers that if revealed allow complete compromise for all connections to a host (and we now suspect they *are* being revealed.) I have to disagree. You don't need a CA. There's a very long rant I could make here, and I'll try to keep it a summary. Much of the system we have is built needing CAs, but it was only built that way. A long time ago, the certificate structure we're still vestigially using had as one of its goals a way to keep the riff-raff from using crypto. I remember when I got my first PEM certificate, I had to send my blinking passport off to MITRE for two weeks so they could let me encrypt the crapola that was sitting on my disk unencrypted. It was harder to get a cert than it was to get a visa to Saudi Arabia! So much of what we would have encrypted we just printed on paper and put in a file cabinet. Excuse me, I'm starting on that rant I said I wouldn't do. The major problem one has with public key is knowing that the public key of the endpoint you want to talk to us actually the right public key. Trusted Introducers of any sort are one way to solve the problem. CAs are merely an industrialized form of Trusted Introducer and not ipso facto bad. The way that Web PKI (as it's now being called) is using Trusted Introducers is suboptimal, but ironically, we are on the inflection point of a real honest-to-whomever fix to them in the form of Certificate Transparency. That suggests even another discussion, one that I promised Ben I'd get to eventually. The major problem with the certificate system is actually the browsers, in my opinion, because they actively discourage using certificates in any other way. If browsers, for example, allowed you to use a private cert with a user experience that was ultimately SSH-like (also called TOFU for Trust On First Use) as opposed to putting big blood-red danger warnings up, it would work out better for everyone including the CAs. But anyway, there are other solutions. They range from some variant of Direct Trust being TOFU or even using a Kerberos-like system to hand you a key, or what we do in ZRTP, or lots of other things. The bottom line is that if you want to send someone a message securely and you have never talked to them before, you have no other way to deal with it than public key systems. (Or you can re-define the problem. Suppose I want to send Glenn Greenwald a message and his Kerberos controller gives me an AES key, I merely have to trust the controller. If we say that trusting him is the same as trusting the controller, then yeah, sure, it works. That's a suitable redefinition in which the KDC is isomorphic to a CA. But if we allow public key, then I could get Mr. Greenwald's public key from an intermediary who is not necessarily an authority, or even self-publish keys. It's done with PGP all the time.) We need to re-think everything about how we do cryptography. Many decisions were made based on hardware limitations of 20 and more years ago. More efficient claims from the 1980's often mean nothing today. Many decisions assumed trust models (like CA's) that we know are completely unrealistic. Mobile is very different from the server-to-server and dumb-client-to-server models that were all anyone thought about the time. (Just look at SSL: It has the inherent assumption that the server *must* be authenticated, but the client ... well, that's optional and rarely done.) None of the work then anticipated the kinds of attacks that are practical today. I concur that the way that browsers and web servers us SSL is suboptimal. This doesn't mean that a solution is impossible, it only means we have
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2013, at 8:24 PM, Jerry Leichter leich...@lrw.com wrote: Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS. ... This makes any NSA recommendation *extremely* suspect. As far as I can see, the bit push NSA is making these days is toward ECC with some particular curves. Makes you wonder. Yes, but. The reason we are using those curves is because they want them for products they buy. They want to buy COTS because it's much cheap, and COTS is based on standards. So they have two contradictory constraints: They want the stuff they buy secure, but they want to be able to break in to exactly the same stuff when anyone else buys it. The time-honored way to do that is to embed some secret in the design of the system. NSA, knowing the secret, can break in; no one else can. There have been claims in this direction since NSA changed the S-boxes in DES. For DES, we now know that was to protect against differential cryptanalysis. No one's ever shown a really convincing case of such an embedded secret hack being done ... but now if you claim it can't happen, you have to explain how the goal in NSA's budget could be carried out in a way consistent with the two constraints. Damned if I know (I know for a fact that NSA has been interested in this area of mathematics for a *very* long time: A mathematician I knew working in the area of algebraic curves (of which elliptic curves are an example) was recruited by - and went to - NSA in about 1975 I think it might even go deeper than that. ECC was invented in the civilian world by Victor Miller and Neal Koblitz (independently) in 1985, so they've been planning for breaking it even a decade before its invention. I'm not sure exactly what you're trying to say. Yes, Miller and Koblitz are the inventors of publicly known ECC, and a number of people (Diffie, Hellman, Merkle, Rivest, Shamir, Adelman) are the inventors of publicly known public-key cryptography. But in fact we now know that Ellis, Cocks, and Williamson at GCHQ anticipated their public key cryptography work by several years - but in secret. I think the odds are extremely high that NSA was looking at cryptography based on algebraic curves well before Miller and Koblitz. Exactly what they had developed, there's no way to know. But of course if you want to do good cryptography, you also have to do cryptanalysis. So, yes, it's quite possible that NSA was breaking ECC a decade before its (public) invention. :-) What am I trying to say? I'm being a bit of a smartass. I'm sorry, it's a character flaw, but it's one that amuses me. I'll be blunt, instead. There is a lot of discussion here -- not really so much from you but in general -- that in my opinion is fighting the last war. Sometimes that last war is the crypto wars of the 1990s, but sometimes it's WWII. Yeah, yeah, if you don't remember history you'll repeat it, but we need to look through the windshield, not the rear view mirror. My smartassedness was saying that by looking at the past, gawrsh, maybe we're seeing a time machine! The present war is not the previous one. This one is not about crypto. It involves crypto, but it's not *about* it. The bright young things of 1975 who went to work for the NSA wrote theorems and got lifetime employment. The bright young things of 2010 write shellcode and are BAH contractors. There are two major trends that are happening. One is that they're hitting the network, not the crypto. Look at Dave Aitel's career, not your mathematician friend. Aitel is one of the ones that got away, and what he talks about is what we're seeing that they are doing. If you have to listen to one of the old school mathematicians, listen to Shamir -- they go around crypto. (And actually, we need to look not at Aitel as he left in 2002, but the bright young thing who left last year, but I think I'm making my point.) The other major trend is that outsourcing, contracting and other things ruined the social contract between them and the people who work there. (This reflects the other other problem which is that the social contract between them and us seems to be void.) Nonetheless, Aitel and others left and are leaving because no longer do they tap you on the shoulder in college and then there's the mutual backscratching of a lifelong career. Now a contractor knows that when the contract is over, they're out of a job. And when the contractor sees malfeasance that goes all the way up to the Commander-in-Chief, they look at what their employment agreement said, as well as the laws that apply to them. If you're in that environment and you see malfeasance, you go to your superior and it's a felony not to. If your superior is part of the malfeasance, you go