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] FIPS, NIST and ITAR questions
Sent from my iPad On Sep 3, 2013, at 6:06 PM, Jerry Leichter leich...@lrw.com wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. hash-PRNG: append blocks that are digest (seed ++ counter ++ seed) Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. If you think this is obviously wrong, consider instead: H1(X) = SHA-512(X) || SHA-512(SHA-512(X)) Could you determine, just from black-box access to H1, that it's equally bad as a PRNG? (You could certainly do it with about 2^256 calls to H1 with distinct inputs - by then you have a .5 chance of a duplicated top half of the output, almost certainly with a distinct bottom half. But that's a pretty serious bit of testing) I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
... Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. You won't get a prf or stream cipher or prng or block cipher just out of collision resistance--you need some kind of pseudorandomness assumption. We expect general purpose hash functions like Keccak to provide that, but it doesn't follow from the collision resistance assumption, for exactly the reason you gave there--it's possible to design collision-resistant functions that leak input or are predictable in some bits. I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) The HMAC construction wouldn't give a PRF for your example of h(x) = sha512(x) || sha512(x) A single output would be trivial to distinguish from a 1024 bit random number. -- Jerry --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Can you backdoor a symmetric cipher
On Thu, 5 Sep 2013 21:42:29 -0700 Jon Callas j...@callas.org wrote: On Sep 5, 2013, at 9:33 PM, Perry E. Metzger pe...@piermont.com wrote: It is probably very difficult, possibly impossible in practice, to backdoor a symmetric cipher. For evidence, I direct you to this old paper by Blaze, Feigenbaum and Leighton: http://www.crypto.com/papers/mkcs.pdf There is also a theorem somewhere (I am forgetting where) See the URL quoted above. That is the implication of their paper. that says that if you have a block cipher with a back door, then it is also a public key cipher. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Aside on random numbers (was Re: Opening Discussion: Speculation on BULLRUN)
On Fri, 6 Sep 2013 01:04:31 -0400 John Kelsey crypto@gmail.com wrote: 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. No, clearly not, but it works fine for a key generation ceremony for a valuable key or the like. It might also be fine in other limited contexts. That said, I came up with a fine way to automate this in the shower, which I'm documenting here in case it inspires someone. Naively, one could take a picture of the dice and OCR it. However, one doesn't actually need to OCR the dice -- simply hashing the pixels from the image will have at least as much entropy if the position of the dice is recognizable from the image. (You have to assume your hash function is reasonable but the rest of your infrastructure needs to assume that anyway in all likelihood.) So, simply take pictures of each of N rolls of multiple dice and hash them all together. One could write an app to do this, but of course the phone is not exactly a secure platform to begin with... Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Sabotaged hardware (was Re: Opening Discussion: Speculation on BULLRUN)
On Thu, 5 Sep 2013 22:31:50 -0400 Jerry Leichter leich...@lrw.com wrote: 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. This is troubling. It implies that there are widely used crypto accelerators in use at large organizations that intentionally harm the security of users. Random number generator flaws would seem like an obvious possibility here. This is especially disturbing because other actors can now start doing teardowns on a wide variety of such devices looking to find the flaws so they can themselves attack the traffic in question. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Is ECC suspicious?
Op 6 sep. 2013, om 01:09 heeft Perry E. Metzger pe...@piermont.com het volgende geschreven: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance …. The Suite B curves were picked some time ago. Maybe they have problems. …. Now, this certainly was a problem for the random number generator standard, but is it an actual worry in other contexts? I tend not to believe that but I'm curious about opinions. Given the use, including that of the wider security/intelligence community, I'd expect any issues to be more with very specific curves (either tweaked to be that way; or through soft means promoted/pushed/suggested those who by happenstance have an issue) that with the ECC as an algorithm/technology class. As anything deeper than a curve would assume very aligned/top-down control and little political entropy. Not something which 'just the' signal intelligence community could easily enforce on the other cats. Dw ___ 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] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/13 8:36 AM, Perry E. Metzger wrote: One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. +1 In practice, how do we make that happen? On the XMPP network we're pushing to make sure that all client-to-server and server-to-server hops are encrypted (yes, I know, per-hop encryption is not enough, we need end-to-end encryption too). Is there a handy list of PFS-friendly ciphersuites that I can communicate to XMPP developers and admins so they can start upgrading their software and deployments? Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKgDaAAoJEOoGpJErxa2pMssQAKVjwZZqy0q2ogIk13rGZkym 8PnXm6H9qsw08q4w3NEXPOU41rEh/GpS4agcgVxA+huYo5hU+qeA8YuhrVXt2xS7 Jt/fUgpJup297W4ErUpzMDQegVfP8ckNizI2AXBfr631PKUs7U3ije6wdxK30Hyx 262V/SLP0uVnJpbmepWUMCfzTGMY0SAvq2blVAPJjqjulC6lshj/aiKP6RBi9hCF CW8yWO4L7Uot1mAa7j87Ywlyg9V8j6nKNEsKu81rjhSLpGvmed0GncK7U3GxLmsM z2VzZKRJ+NxwJ3MKicmEy2bNnPjSJUd8itUWKru2vYMZftGImljWv1cUsLjXkxI7 DvQQ0lrjl3W8tisN7aqmGPi2734j8AN6ilHAUCbWniJfaarfC6rU/fDuk6fGnFss N/zq9+NhYdvegmJiLvwVm42d1XdCxgoKzb27g/d8CsUWqWWXtQhxTeLL+OcKXiqh kXLDDTv9uqBgdqWDZ/uhhlFGd/PFfeakeW7QWDjAvRMyF3XWaHA+OBJpg+nE/Dsl kSfLmiCzOj4FN8aPQoM39T9IHbASpp+KYgnCl0nDweYXXBH/v5B/bCwsqz5Sy0ut SET7zglbKm6oVf9hWoXsv01Kqsrxw6xj2bdnMU6YSUQoDvDHdXlilRZ6dTP5G63v 8XfdEe3k0aa+7uPpWQ5t =SiIp -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 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] Suite B after today's news
Hi, Same here. AES is, as far as we know, pretty secure, so any problems are going to arise in how AES is used. AES-CBC wrapped in HMAC is about as solid as you can get. AES-GCM is a design or coding accident waiting to happen. But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS 1.0. RC4 was good enough for a while, but with djb's new work - it's just waiting to be improved and made practical by someone. FWIW, we still use RC4 on our servers, but I'd be happy to see something else that is practical. Of course, the above attacks are probably not one of your worries when you're up against the NSA - your own system is probably much more endangered. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Aside on random numbers (was Re: Opening Discussion: Speculation on BULLRUN)
On Sep 6, 2013, at 10:03 AM, Perry E. Metzger pe...@piermont.com wrote: Naively, one could take a picture of the dice and OCR it. However, one doesn't actually need to OCR the dice -- simply hashing the pixels from the image will have at least as much entropy if the position of the dice is recognizable from the image. [...] One could write an app to do this, but of course the phone is not exactly a secure platform to begin with... http://gamesbyemail.com/News/DiceOMatic -wps ___ 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] People should turn on PFS in TLS
On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie b...@links.org wrote: On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com wrote: Google is also now (I believe) using PFS on their connections, and they handle more traffic than anyone. A connection I just made to https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, ECDHE_RSA. It would be good to see them abandon RC4 of course, and soon. In favour of what, exactly? We're out of good ciphersuites. I thought AES was okay for TLS 1.2? Isn't the issue simply that Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 connection. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Can you backdoor a symmetric cipher (was Re: Opening Discussion: Speculation on BULLRUN)
It is probably very difficult, possibly impossible in practice, to backdoor a symmetric cipher. For evidence, I direct you to this old paper by Blaze, Feigenbaum and Leighton: http://www.crypto.com/papers/mkcs.pdf There is also a theorem somewhere (I am forgetting where) that says that if you have a block cipher with a back door, then it is also a public key cipher The real question there is whether someone who had such a thing would want to be remembered by history as the inventor of the most significant PK system the world has ever seen, or a backdoored cipher. Well, if that someone were the NSA, they might well be very happy to be remembered as the guy who made it possible break in to much of the world's communication! However, I find this argument unconvincing. It has the feel of a standard reduction, but isn't, because the reduction is to a known problem that's widely thought to be difficult - it's to a vaguely defined, broad class of problems, designing a much faster public key system. Just because the construction gives you something like a public key system, doesn't mean if gives you anything practical for use that way. For example, suppose the master key works - but only for 1/2^k possible cleartext blocks, or even 1/2^k possible keys. This makes it useless as a public-key system even for very small k, but quite useful to an attacker even for larger k. Or suppose the master key works on all messages and keys, but is inefficient, requiring large amounts of time or memory, or the pre-computation of large lookup tables. Here's a thought experiment: Suppose differential cryptanalysis were known only to you, and you were in a position to influence the choice of S-boxes for a cryptosystem. Your master key would be the knowledge that DC would work very effectively against the system - but it would still require a lot of time and memory to do so. You'd even have a leg up on everyone else because you'd know the differentials to use up front - though that's a trivial advantage, since once you know to look for them, finding them is easy enough. In fact, as far as I know, no one has had any reason to pose questions like: Could you choose S-boxes that allow some kind of pre-computation step to make application of DC to messages much faster? DC requires gathering up a large number of plaintext/cyphertext pairs; eventually, you f ind examples of you can use. But could there be some way of producing pairs so that success is more likely to come earlier? Could it be that there's some pre-secret that allows computation both of those tables and and of the S-boxes, such that given only the S-boxes, finding the pre-secret and the tables isn't practical? Once DC was known and it was found the NSA had actually strengthened DES's S-boxes to protect against it, no one really looked into such issues - basically, who cared? If you really want to think in tin-hat terms, consider linear cryptanalysis. While DES was strong against DC, it was quite weak against LC. People interpreted this as meaning that NSA didn't know about LC. But ... maybe out in Area 51, or wherever Langley does work with alien technologies, they knew about LC *all along*, and *deliberately* made DES weak against it! (Why LC and not DC? Because as we subsequently learned from Don Coppersmith, DC was already known in the non-NSA community, and the NSA knew that it was known.) Please keep in mind that I'm not proposing that NSA actually did anything like this for any widely-used cryptosystem. I don't even see how they could have with respect to, say, AES, since they had no hand in the design of the algorithm or the choice of constants. The only thing I'm arguing here is that the theorems that say such a thing could never happen prove nothing of the sort. -- Jerry ___ 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] IA side subverted by SIGINT side
I have a small amount of raised eyebrow because the greatest bulwark we have against the SIGINT capabilities of any intelligence agency are that agency's IA cousins. I don't think that the Suite B curves would have been intentionally weak. That would be a shock. Then be shocked, shocked that the muscular exploitation side of an intelligence agency would overrule the weak Information Assurance side. It happens over and over. It even happens in companies that have no SIGINT side, like Crypto AG, when somebody near the top is corrupted or blackmailed into submission. As late as 1996, the National Academy of Sciences CRISIS panel was tasked by the US Congress with coming up with a US crypto policy that would be good for the whole nation, updating the previous policy that was driven by spy agency and law enforcement excesses to sacrifice the privacy and security of both people and companies. After taking a large variety of classified and unclassified input, the panel's unanimous consensus suggested that everybody standardize on 56-bit DES, which they KNEW was breakable. Diffie, Hellman and Baran persuasively argued in the 1970s when DES was up for standardization that a brute force DES cracker was practical; they recommended longer keys than 56 bits. See for example this contemporaneous 1976 cassette recording / transcript: https://www.toad.com/des-stanford-meeting.html Subsequent papers in 1993 (Weiner, Efficient DES Key Search) and in 1996 (Goldberg Wagner, Architectural Considerations for Cryptanalytic Hardware) provided solid designs for brute-force DES key crackers. Numerous cryptographers and cypherpunks provided input to the CRISIS panel as well. They even cited these papers and input on page 288 of their report. I have never seen a subsequent accounting by the CRISIS panel members for this obviously flawed recommendation. It was rapidly obsoleted by subsequent developments when in June 1997 Rocke Verser coordinated a team to publicly crack DES by brute force in months; when in 1998 EFF revealed its DES Cracker hardware that cost $250K and could crack DES in a week; and when in 2000 the export regs were effectively removed on any strength encryption in mass market and free software, a change forced upon them by EFF's success in Dan Bernstein's First Amendment case. The panel members included substantial information-assurance folks like Marty Hellman and Peter Neumann, Lotus Notes creator Ray Ozzie, and Willis Ware (an engineer on WW2 radars and the Johnniac, who later spread computers throughout aviation design and the Air Force, ended up at RAND, and served on the 1974 Privacy Act's Privacy Protection Study Commission). But several of those people (and others on the panel such as Ann Caracristi, long-term NSA employee and 2-year deputy director of NSA) also have a long history involved with classified military work, which makes their publicly-uttered statements unlikely to reflect their actual beliefs. John PS: The CRISIS panel also recommended that encryption of any strength be exportable if the proposed product user is willing to provide access to decrypted information upon a legally authorized request. They assumed the ongoing existence of a democratic civilian government and a functioning independent court system in the United States -- an assumption that is currently questionable. I don't think the panel foresaw that a single legally authorized request would come with a gag order from a secret court, would purport to target a single unnamed individual, but would nevertheless require that information about every person making a phone call in the United States be turned over to a classified government agency for permanent storage and exploitation. Nor did they see that the government they were part of would be committing serious international war crimes including political assassination, torture, indefinite detention without trial, and wars of aggression, on an ongoing basis. Either that, or maybe NSA blackmailed the committee members into these recommendations, just as J. Edgar Hoover blackmailed his way through 40 years of unchecked power. Trouble is, Hoover eventually had to die; NSA, not being human, does not have that natural limit. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
Hi, It would be good to see them abandon RC4 of course, and soon. In favour of what, exactly? We're out of good ciphersuites. I thought AES was okay for TLS 1.2? Isn't the issue simply that Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 connection. Firefox has added TLS 1.2 two or three weeks ago, and TLS 1.2 does indeed protect against BEAST, CRIME, Lucky 13 (but not against BREACH, I recall). However, my guess would be that too many Apaches out there are linked to older openssl versions that do not yet support TLS 1.1 or TLS 1.2. I have found this a good write-up: https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Aside on random numbers (was Re: Opening Discussion: Speculation on BULLRUN)
On Sep 6, 2013, at 10:03 AM, Perry E. Metzger wrote: Naively, one could take a picture of the dice and OCR it. However, one doesn't actually need to OCR the dice -- simply hashing the pixels from the image will have at least as much entropy if the position of the dice is recognizable from the image One could write an app to do this, but of course the phone is not exactly a secure platform to begin with... Ah, but that highlights an essential difference between OCR'ing the image and just hashing it: I can easily check, with my own eyes, that the OCR app is really doing what it claims to be doing. I have no hope of checking the hash-based app. A whole class of attacks is closed off by the OCR technique. It's not that there aren't other attacks. The phone could, for example, leak the generated values, sending them off to Big Brother. That kind of attack would, if done correctly, be virtually impossible to detect. On the other hand, it's not nearly as valuable as a biased generation attack - Big Brother would receive streams of random die tosses with little context about what the resulting values would be used for or how they would be used. Appropriately targeted attacks might work - I know Metzger regenerates his keys on the 3rd of every month at about 8:00 AM, so let's use the values he scans at around that time as guesses for his base random values - but we're talking quite a bit of difficulty here - and the more people use the app, and the more often they make it a habit to toss and scan dice and just discard the results, the more difficult it becomes. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 06.09.2013 18:20, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/13 8:36 AM, Perry E. Metzger wrote: One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. +1 In practice, how do we make that happen? On the XMPP network we're pushing to make sure that all client-to-server and server-to-server hops are encrypted (yes, I know, per-hop encryption is not enough, we need end-to-end encryption too). Is there a handy list of PFS-friendly ciphersuites that I can communicate to XMPP developers and admins so they can start upgrading their software and deployments? Thanks! Peter yet, one can find this sort of thing in 3rd position when searching nginx crypto : http://www.hybridforge.com/blog/nginx-ssl-ciphers-and-pci-compliance quote : The developers of Nginx have recently changed the default SSL ciphers to include the very strong Diffie-Hellman Ephemeral (DHE) cipher. DHE is used to provide perfect forward secrecy in TLS. Further reading on Ephermal Diffie-Hellman, PFS and TLS at Wikipedia.org While I applaud this move on the part of the Nginx dev team there is a tradeoff and that is slower performance. DHE provides stronger encryption which in turn requires more computation but here’s where it gets interesting. To meet today’s PCI DSS crypto standards DHE is not required. Like many things in life there’s a balance to be struck between the risk of compromised encryption and the additional expense or rather the relative loss of connections per second. I’m not a lawyer nor should this be considered legal advice but I prefer things that go fast while meeting the necessary PCI compliance criteria. In order to disable DHE in the server context of the Nginx configuration add the following line: ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH; ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 9/6/2013 9:52 AM, Raphaël Jacquot wrote: To meet today’s PCI DSS crypto standards DHE is not required. PCI is about credit card fraud. Mastercard/Visa aren't worried that criminals are storing all your internet purchase transactions with the hope they can crack it later; if the FBI/NSA want your CC number they can get it by asking. -Dan Veditz smime.p7s Description: S/MIME Cryptographic Signature ___ 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] Sabotaged hardware (was Re: Opening Discussion: Speculation on BULLRUN)
On Sep 6, 2013, at 11:37 AM, John Ioannidis wrote: I'm a lot more worried about FDE (full disk encryption) features on modern disk drives, for all the obvious reasons. If you're talking about the FDE features built into disk drives - I don't know anyone who seriously trusts it. Every secure disk that's been analyzed has been found to be secured with amateur-level crypto. I seem to recall one that advertised itself as using AES (you know, military-grade encryption) which did something like: Encrypt the key with AES, then XOR with the result to encrypt all the data. Yes, it does indeed use AES There's very little to be gained, and a huge amount to be lost, be leaving the crypto to the drive, and whatever proprietary, hacked-up code the bit-twiddlers who do driver firmware decide to toss in to meet the marketing requirement of being able to say they are secure. Maybe when they rely on a published standard, *and* provide a test mode so I can check to see that what they wrote to the surface is what the standard says should be there, I might change my mind. At least them, I'd be worrying about deliberate attacks (which, if you can get into the supply chain are trivial - there's tons of space to hide away a copy of the key), rather than the nonsense we have today. And if I wanted to be truly paranoid, I'd worry about HSMs to Now, wouldn't compromising HSM's be sweet. Not that many vendors make HSM's, and they are exactly the guys who already have a close relationship with the CI (crypto-industrial) complex -- Jerry /ji ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6 September 2013 18:24, Perry E. Metzger pe...@piermont.com wrote: On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie b...@links.org wrote: On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com wrote: Google is also now (I believe) using PFS on their connections, and they handle more traffic than anyone. A connection I just made to https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, ECDHE_RSA. It would be good to see them abandon RC4 of course, and soon. In favour of what, exactly? We're out of good ciphersuites. I thought AES was okay for TLS 1.2? Isn't the issue simply that Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 connection. Apart from its fragility, AES-GCM is still OK, yes. The problem is that there's nothing good left for TLS 1.2. ___ 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
[Cryptography] 1024 bit DH still common in Tor network
Summary: blog posting claims most of the Tor network is still running older software that uses 1024 bit Diffie-Hellman. http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html I'm not sure how cheap it actually would be to routinely crack DH key exchanges, but it does seem like it would be valuable for most Tor nodes to be running newer software anyway. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
I think that any of OCB, CCM, or EAX are preferable from a security standpoint, but none of them parallelize as well. If you want to do a lot of encrypted and authenticated high-speed link encryption, well, there is likely no other answer. It's GCM or nothing. OCB parallelizes very well in software and I see no reason it would not also do so in hardware; each block of both the plaintext and associated data can be processed independently of the others, and all of OCB's operations (xor, GF(2^128) doubling, Grey codes) seem like they would be well suited to a fast hardware implementation. And actually McGrew and Viega's original 2003 paper on GCM specifically mentions that OCB scales to high speeds in hardware, though they do not provide references to specific results. Jack ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 06/09/13 15:36, Perry E. Metzger wrote: One solution, preventing passive attacks, is for major browsers and websites to switch to using PFS ciphersuites (i.e. those based on ephemeral Diffie-Hellmann key exchange). It occurred to me yesterday that this seems like something all major service providers should be doing. I'm sure that some voices will say additional delay harms user experience. Such voices should be ruthlessly ignored. Any additional delay will be short - after all, if forward secrecy by ephemeral key setup (I hate the term PFS, there is nothing perfect about it) is not used then you have to use something else - usually RSA - instead. For a desktop, laptop, or even a decent mobile the difference is not noticeable in practice if the server is fast enough. However, while the case for forward secrecy is easy to make, implementing it may be a little dangerous - if NSA have broken ECDH then using it only gives them plaintext they maybe didn't have before. Personally, operating on the assumption that NSA have not made a crypto break is something I'm not prepared to do. I just don't know what that break is is. I think it's most likely RSA/DH or ECC, but could easily be wrong. I don't really care if the break is non-existent, irrelevant or disinformation - beefing up today's crypto is only hard in terms of getting people to choose a new updated crypto, and then getting people to implement it. This happens every so often anyway. One point which has been mentioned, but perhaps not emphasised enough - if NSA have a secret backdoor into the main NIST ECC curves, then even if the fact of the backdoor was exposed - the method is pretty well known - without the secret constants no-one _else_ could break ECC. So NSA could advocate the widespread use of ECC while still fulfilling their mission of protecting US gubbmint communications from enemies foreign and domestic. Just not from themselves. Looking at timing, the FIPS 186-3 curves were introduced in July 2009 - the first hints that NSA had made a cryptanalytic break came in early to mid 2010. I'm still leaning towards RSA, but ... -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why prefer symmetric crypto over public key crypto?
In this oped in the Guardian http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Bruce Schneier writes: Prefer symmetric cryptography over public-key cryptography. The only reason I can think of is that for public key crypto you typically use an American (and thus subverted) CA to get the recipients public key. What other reasons could there be for this advice? Best, Jaap-Henk (I apologise for typos and being terse; this mail was written on an iPad) -- Jaap-Henk Hoepman TNO, Groningen Dept. of Computer Science Radboud University Nijmegen (m) j...@cs.ru.nl (w) www.cs.ru.nl/~jhh (m) jaap-henk.hoep...@tno.nl (t) +31 6 20619554 (t) @xotoxot___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Bruce Schneier has gotten seriously spooked
On Fri, Sep 06, 2013 at 04:25:12PM -0400, Jerry Leichter wrote: A response he wrote as part of a discussion at http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html: Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? A: (Schneier) Yes, I believe so. This is why I've been verifying Tor downloads using out of band fingerprints of signing key. Just because active attacks are more expensive than passive attacks and are fundamentally detectable, don't assume they're not being used in highly targeted cases. If you have ever been under telco surveillance, that's enough effort already spent to warrant slipping you some custom malware with no added bill of materials. ___ 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] People should turn on PFS in TLS
On Fri, 6 Sep 2013 18:56:51 +0100 Ben Laurie b...@links.org wrote: The problem is that there's nothing good [in the way of ciphers] left for TLS 1.2. So, lets say in public that the browser vendors have no excuse left for not going to 1.2. I hate to be a conspiracy nutter, but it is that kind of week. Anyone at a browser vendor resisting the move to 1.2 should be viewed with deep suspicion. (Heck, if they're not on the government's payroll, then shame on them for retarding progress for free. They should at least be charging. And yes, I'm aware many of the people resisting are probably doing so without realizing they're harming internet security, but we can no longer presume that is the motive.) Chrome handles 1.2, there is no longer any real excuse for the others not to do the same. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Bruce Schneier has gotten seriously spooked
A response he wrote as part of a discussion at http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html: Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? A: (Schneier) Yes, I believe so. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Bruce Schneier calls for independent prosecutor to investigate NSA
Quoting: All of this denying and lying results in us not trusting anything the NSA says, anything the president says about the NSA, or anything companies say about their involvement with the NSA. We know secrecy corrupts, and we see that corruption. There's simply no credibility, and -- the real problem -- no way for us to verify anything these people might say. https://www.schneier.com/blog/archives/2013/09/conspiracy_theo_1.html -- 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] Suite B after today's news
Ralph Holz ralph-cryptometz...@ralphholz.de writes: But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS 1.0. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of these, I just can't get any traction on it from the TLS WG chairs. Maybe they're following http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Washington Post: Google racing to encrypt links between data centers
Quoting: Google is racing to encrypt the torrents of information that flow among its data centers around the world, in a bid to thwart snooping by the NSA as well as the intelligence agencies of foreign governments, company officials said on Friday. The move by Google is among the most concrete signs yet that recent revelations about the National Security Agency’s sweeping surveillance efforts have provoked significant backlash within an American technology industry that U.S. government officials long courted as a potential partner in spying programs. http://www.washingtonpost.com/business/technology/google-encrypts-data-amid-backlash-against-nsa-spying/2013/09/06/9acc3c20-1722-11e3-a2ec-b47e45e6f8ef_story.html -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com wrote: Google is also now (I believe) using PFS on their connections, and they handle more traffic than anyone. A connection I just made to https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, ECDHE_RSA. It would be good to see them abandon RC4 of course, and soon. In favour of what, exactly? We're out of good ciphersuites. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 6/09/13 20:15 PM, Daniel Veditz wrote: On 9/6/2013 9:52 AM, Raphaël Jacquot wrote: To meet today’s PCI DSS crypto standards DHE is not required. PCI is about credit card fraud. So was SSL ;-) Sorry, couldn't resist... Mastercard/Visa aren't worried that criminals are storing all your internet purchase transactions with the hope they can crack it later; if the FBI/NSA want your CC number they can get it by asking. That's what the crims do to, they ask for all the numbers, they don't bother much with SSL. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] tamper-evident crypto?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 06:48 PM, Richard Clayton wrote: so you'd probably fail to observe any background activity that tested whether this information was plausible or not and then some chance event would occur that caused someone from Law Enforcement (or even a furnace maintenance technician) to have to look in the basement. Well, I'm sure /somebody/ on this list is clever enough to arrange countersurveillance and counterintrusion measures... a) especially given that detecting surveillance and/or intrusion is the whole point of the exercise; b) especially given that we have all the time in the world to arrange boatloads of nanny-cams and silent alarms etc., arranging everything in advance, before provoking the opponent; c) especially given that we know it's a trap, and the opponent probably isn't expecting a trap; d) especially given that the opponent has a track record of being sometimes lazy ... for instance by swearing that the fruits of illegal wiretaps came from a confidential informant who has been reliable in the past and using that as the basis for a search warrant, at which point you've got them for perjury as well as illegal wiretapping, *and* you know your information security is broken; e) especially given that we get to run this operation more than once. (assuming that the NSA considered this [kiddie porn] important enough to pursue) *) If they don't like that flavor of bait, we can give them something else. For example, it is known that there is a large-diameter pipeline from the NSA to the DEA. http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/05/the-nsa-is-giving-your-phone-records-to-the-dea-and-the-dea-is-covering-it-up/ *) Again: We get to run this operation more than once. I repeat the question from the very beginning of this thread: Shouldn't this be part of the /ongoing/ validation of any data security scheme? There's a rule that says that you shouldn't claim a crypto system is secure unless it has been subjected to serious cryptanalysis. I'm just taking the next step in this direction. If you want to know whether or not the system is broken, /measure/ whether or not it is broken. One of the rules in science, business, military planning, et cetera is to consider /all/ the plausible hypotheses. Once you consider the possibility that your data security is broken, the obvious next step is to design an experiment to /measure/ how much breakage there is. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSKi2j2FOSJqrRXAoRAtJAAJ9zUubRz66YdcdRM3G3Wpx70TcDtgCgm9tE xiI/Ikqt4PbbTDZeC0sK9vI= =UYAV -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On 6 September 2013 17:20, Peter Saint-Andre stpe...@stpeter.im wrote: Is there a handy list of PFS-friendly ciphersuites that I can communicate to XMPP developers and admins so they can start upgrading their software and deployments? Anything with EDH, DHE or ECDHE in the name... ___ 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] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
we were brought in as consultants to a small client/server startup that wanted to do payment transactions on their server, they had this technology they called SSL they wanted to use, the result is now frequently called electronic commerce. The two people at the startup responsible for the commerce server we had worked with in prior life on parallel Oracle cluster scaleup. As part of mapping SSL technology to payment transactions we had to audit operations selling SSL digital certificates and also came up with recommendations on how browsers and servers would deploy and use the technology. Almost immediately several of the recommendations were violated, resulting in some number of the exploits that continue to this day. We were then tangentially involved in the Cal. data breach notification legislation, having been brought in to help wordsmith the Cal. electronic signature legislation. Many of the parties were heavily involved in privacy issues and had done numerous, indepth, public surveys. The number one issue was identity theft of the form involving fraudulent financial transactions ... frequently as result of data breach. The issue was nothing was being done about the problems and so it was hoped that the publicity from the notifications might motivate corrective action. Part of the issue is normally institutions take security measures in self-interests ... however, the institutions having breaches weren't at risk, it was the account holders. PCI DSS shows up some time after Cal. data breach notification and frequently the joke is that if you have a breach ... you loose your PCI DSS certification. It turns out that there was a number of Federal data breach notification bills introduced, preempting state legislation and effectively eliminating notification requirements ... citing PCI DSS industry effort as justification for no longer needing notification. Another problem we've frequently pointed out is current paradigm with dual use paradigm and even if the planet was covered in miles of information hiding encryption, it wouldn't stop data leakage. Account information is used for authenticating new transactions and so has a requirement that it be kept totally confidential and never divulged to anybody ... but at the same time, account information is needed in dozens of business processes at millions of locations around the planet. disclaimer: we were co-authors of the x9.59 financial transaction standard that slightly tweaked the current payment paradigm and eliminated the dual-use characteristic which then also eliminated the need to hide account information and as a result it also eliminated the need for SSL to hide account information in electronic commerce transactions eliminating the major requirement for SSL in the world today. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Matthew Green on BULLRUN
Some interesting nuggets here, including the fact that he explicitly calls out the existence of NSA's new HUMINT division that infiltrates corporations for a living. http://blog.cryptographyengineering.com/2013/09/on-nsa.html -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On 6/09/13 04:44 AM, Peter Gutmann wrote: John Kelsey crypto@gmail.com writes: If I had to bet, I'd bet on bad rngs as the most likely source of a breakthrough in decrypting lots of encrypted traffic from different sources. If I had to bet, I'd bet on anything but the crypto. Why attack when you can bypass [1]. Peter. [1] From Shamir's Law [2], crypto is bypassed, not penetrated. [2] Well I'm going to call it a law, because it deserves to be. [3] This is a recursive footnote [3]. It looks like it is all of the above. These are the specific interventions I have seen mention of so far: * weakened algorithms/protocols for big players (e.g., GSM, Cisco) * weakening of RNGs * inside access by 'covert agents' to hand over secrets (e.g., big 4) * corruption of the standards process (NIST 2006?) * corruption of certification process (CSC) * crunching of poor passwords * black ops to steal keys * black ops to pervert systems Which makes sense. Why would the biggest player just do one thing ? No, they are going to do everything within their power. They'll try all the tricks. Why not, they've got the money... What is perhaps more interesting is how these tricks interplay with each other. That's something that we'll have trouble seeing and imagining. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Bruce Schneier has gotten seriously spooked
On 6 September 2013 16:25, Jerry Leichter leich...@lrw.com wrote: Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? http://c2.com/cgi/wiki?TheKenThompsonHack (and many other references) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers
Right. Maybe some AES32? 2013/9/7 Perry E. Metzger pe...@piermont.com Quoting: Google is racing to encrypt the torrents of information that flow among its data centers around the world, in a bid to thwart snooping by the NSA as well as the intelligence agencies of foreign governments, company officials said on Friday. The move by Google is among the most concrete signs yet that recent revelations about the National Security Agency’s sweeping surveillance efforts have provoked significant backlash within an American technology industry that U.S. government officials long courted as a potential partner in spying programs. http://www.washingtonpost.com/business/technology/google-encrypts-data-amid-backlash-against-nsa-spying/2013/09/06/9acc3c20-1722-11e3-a2ec-b47e45e6f8ef_story.html -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 6, 2013, at 11:41 AM, Jack Lloyd ll...@randombit.net wrote: I think that any of OCB, CCM, or EAX are preferable from a security standpoint, but none of them parallelize as well. If you want to do a lot of encrypted and authenticated high-speed link encryption, well, there is likely no other answer. It's GCM or nothing. OCB parallelizes very well in software and I see no reason it would not also do so in hardware; each block of both the plaintext and associated data can be processed independently of the others, and all of OCB's operations (xor, GF(2^128) doubling, Grey codes) seem like they would be well suited to a fast hardware implementation. And actually McGrew and Viega's original 2003 paper on GCM specifically mentions that OCB scales to high speeds in hardware, though they do not provide references to specific results. I confess that I might not explain very well a controversy that I lie on a different side of -- I'm using CCM, myself. My above explanation is what GCM proponents have told me -- that if you are doing multiple high-speed streams and have hardware you can throw at it, then it's what you want. There is/was an additional OCB issue specifically that there is/was IP around it. Univ. of California has recently relaxed them, but it's still needlessly complex. I confess I tend to think of OCB as a footnote -- the cool thing we can't use -- only. My decision tree is that I think in a perfect world, one would use OCB, but the IP nixes it. CCM was created specifically because it's not OCB, and EAX as an alternative to the alternative CCM. GCM is too easy to screw up and is slow in software (yes, there's galois multiply on Intel processors, but most of what I do is ARM). There's nothing wrong with EAX, but CCM is there and standardized in a number of places. Other people might end up with a different place for their own reasons. I don't think that any of them are bad, including the decision of using GCM and just making sure you do it right. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKm8XsTedWZOD3gYRAjUuAKC2sqp6C0wCrg+KydfhroBjYahqjwCgo+4d tLx/6e9TaWxRuknLWHEvF5w= =M7s8 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
PEM == Perry E Metzger pe...@piermont.com writes: PEM Anyone at a browser vendor resisting the move to 1.2 should be PEM viewed with deep suspicion. Is anyone? NSS has 1.2 now; it is, AIUI, in progress for ff and sm. Chromium supports it (as of version 29, it seems). Opera supports 1.2 (at least as of version 12, maybe earlier?). Arora 0.11.0 doesn't seem to provide a way to check Links and elinks only did tls 1.1. I don't see a way to get lynx or w3m (text browsers), midori, luakit or xombrero (webkit-gtk) or qupzilla (webkit-qt) to report the tls version details. So I cannot confirm what webkit can do. A bug report from 2011 for polarssl mentions that ie9 can do 1.2. I don't think there is anything else I can test. With it in openssl, gnutls, nss, polarssl, et alia support seems pretty complete. It will take some time for the current ff alpha to filter down to a release, but otherwise things look good on the 1.2 front. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 01:13 PM, Perry E. Metzger wrote: Google is also now (I believe) using PFS on their connections, and they handle more traffic than anyone. A connection I just made to https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, ECDHE_RSA. There may be limits to how far they've deployed PFS on their user-facing services around the world at this time. I just accessed encrypted.google.com and Gmail from home, and here's what the Calomel SSL Validation add-on for Firefox (with HTTPS Finder and HTTPS-Everywhere, verified manually) and is telling me: Symmetric cipher RC4 (weak 10/49) Symmetric key length 128 bits (weak 8/19) Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6) Manually keying https://www.google.com/ into my browser returned the same thing. Gmail shows me this: Symmetric cipher RC4 (weak 10/39) Symmetric key length 128 bits (weak 8/19) Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6) https://www.google.com/analytics is returning the same as Gmail. Let's contrast this with ChaosPad: Symmetric cipher Camellia (STRONG 39/39) Symmetric key length 256 bits (STRONG 19/19) Cert issued by CAcert, Inc. SHA-1 with RSA @ 4096 bit (MODERATE 2/6) I'd be very interested in what other people see where they are. Alternatively, my browser's SSL/TLS configuration could be hosed, in which case I'm completely off base and probably need to torch my browser profile and start over. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Be the strange that you want to see in the world. --Gareth Branwyn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqdHwACgkQO9j/K4B7F8Ez8QCg0BvBhYA5EFVrTRwEqUCJFh0Y Pd8AoJGg5Zg+sKL4NdK76JxcwT1Yvcmb =T/D2 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 01:13 PM, Perry E. Metzger wrote: Google is also now (I believe) using PFS on their connections, and they handle more traffic than anyone. A connection I just made to https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, ECDHE_RSA. Addendum: Calomel SSL Validation has an interesting set of configuration options, which may be of interest and discussion. Two noteworthy ones: - - FIPS 140-2 restricted 256 bit ciphers - - ...AND limit to Perfect Forward Secrecy ciphers Interestingly, turning this on breaks access to https://addons.mozilla.org/. Bluh. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Be the strange that you want to see in the world. --Gareth Branwyn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqdcYACgkQO9j/K4B7F8EKrQCguaWu9UGXABSkUwKJ7A+9n7NX KUoAn3D1AF+NW8KIu9BoIDoxllKkE2+K =GSYs -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 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
[Cryptography] ADMIN: Reminder, yet again...
Sadly it seems I need to repeat this: We've got a very large number of participants on this list, and volume has gone way up at the moment thanks to current events. To make the experience pleasant for everyone please: 1) Cut down the original you're quoting to only the relevant portions to minimize the amount of reading the 1600 people who will be seeing your post will have to do. 2) Do not top post. I've explained why repeatedly. 3) Try to make sure what you are saying is interesting enough and on topic. Minor asides etc. are not. The list is moderated for a reason, and if you top post a one liner followed by a 75 line intact original, be prepared to see a rejection message. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] NYTimes: Legislation Seeks to Bar N.S.A. Tactic in Encryption
Quoting: After disclosures about the National Security Agency’s stealth campaign to counter Internet privacy protections, a congressman has proposed legislation that would prohibit the agency from installing “back doors” into encryption, the electronic scrambling that protects e-mail, online transactions and other communications. Representative Rush D. Holt Jr., a New Jersey Democrat who is also a physicist, said on Friday he believed that the N.S.A. was overreaching and could hurt American interests, including the reputations of American companies whose products the agency may have altered or influenced. “We pay them to spy,” Mr. Holt said. “But if in the process they degrade the security of the encryption we all use, it’s a net national disservice.” http://www.nytimes.com/2013/09/07/us/politics/legislation-seeks-to-bar-nsa-tactic-in-encryption.html -- 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
...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] Bruce Schneier has gotten seriously spooked
Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? Why would they perform the attack only for encryption software? They could compromise people's laptops by spiking any popular app. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, Sep 6, 2013 at 5:34 PM, The Doctor dr...@virtadpt.net wrote: Symmetric cipher RC4 (weak 10/49) Symmetric key length 128 bits (weak 8/19) Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6) First time I've heard of 128-bit symmetric called weak... Sure, RC4 isn't awesome but they seem to be saying that 128-bit keys per se are weak. Let's contrast this with ChaosPad: Symmetric cipher Camellia (STRONG 39/39) Symmetric key length 256 bits (STRONG 19/19) Cert issued by CAcert, Inc. SHA-1 with RSA @ 4096 bit (MODERATE 2/6) Without good server authentication, the other stuff doesn't matter. With Chrome, you get key pinning when talking to some sites (including Google sites, Tor, and Twtitter); I'd much rather have that and only 128-bit symmetric. Also, I don't know why you weren't getting forward secrecy; check your Firefox configuration. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help
It seems to me that while PFS is an excellent back-stop against NSA having/deriving a website RSA key, it does *nothing* to prevent the kind of cooperative endpoint scenario that I've seen discussed in other forums, prompted by the latest revelations about what NSA has been up to. But if your fave website (gmail, your bank, etc) is disclosing the session-key(s) to the NSA, or has deliberately-weakened session-key negotiation in some way, then PFS doesn't help you. I agree that if the scenario is NSA has a database of RSA keys of 'popular sites' then PFS helps tremendously. But if the scenario goes deeper into the cooperative endpoint territory, then waving the PFS flag is perhaps like playing the violin on the deck of the Titantic. Do we now strongly suspect that NSA have a flotilla of TWIRL (or similar) machines, so that active cooperation of websites isn't strictly necessary to derive their (weaker) RSA secret keys? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA hates sunshine
As of Jan-2014 CAs are forbidden from issuing/signing anything less than 2048 certs. For some value of forbidden. :-) Yeah, just like employees at big companies are forbidden to reveal how they are collaborating with NSA. Years ago I heard what happened when George Davida filed a patent on something related to encryption, all the way back in 1978, and eventually received a communication from the government telling him that his patent was subject to patent secrecy, that it would never issue, and that he could not even tell anyone that it had been suppressed, nor could he ever tell anyone how his invention worked. In theory, the law was all on the NSA's and the patent office's side. But in fact, they were in a very weak position. Instead of acquiescing, Davida shouted it to the housetops, engaged the press and his university about censorship of academic freedom, involved his Congressperson, etc. Within months, the secrecy order was rescinded. NSA hates sunshine. NSA secrecy relies on the cowardice of most people. Courage is all it takes to beat them. If NSA tries to shut you up, just shine a lot of attention on their attempt to shut you up. Spread the information that they are trying to suppress, far and wide. Send copies to a dozen random post-office boxes in different cities, asking the recipient to physically bring it in to their local newspaper. Leave your cellphone at home, then stash copies in places that you don't frequent, so that government agents can't come raid your house and office and steal all copies of what they're trying to suppress. In my case I posted something like this (a suppressed paper by Ralph Merkle) to Usenet, and it was suddenly on thousands of servers overnight. NSA habitually decides that the publicity that their activities get from any continued effort to suppress the information is FAR worse than the damage caused by the initial release of the info. Any efforts they make to shut you up, prosecute you, jail you, etc give you a perfect soapbox, and the attention of the news media and the public. Keep repeating the info, from your jail cell if necessary, and you're likely to win. Because if NSA relents, your revelations become last week's news and get a lot less public attention. When NSA found out I had copies of an early encryption tutorial that they considered classified (I was suing them under FOIA to get a copy, but then found copies in a public library), they first tried to persuade my lawyer to bring in all the copies so we can secure them in a safe place. That's NSA-ese for throw them down a deep hole where you'll never see them again. When we refused, and instead contacted the New York Times, which printed a story about the attempted suppression, NSA and DoJ buckled within one day. (Indeed, the way I found out they had suddenly declassified the document is that they called the NYT reporter to tell him. They never did tell me; I got the news from the reporter.) As part of suing the government, the Al Haramain foundation accidentally received a government report making it clear that the government had illegally wiretapped their phone calls. They noticed this but it took the government 60 days to notice. Unfortunately, instead of making hundreds of copies of the document, and spreading them all over the world and to the press, they did what the government asked, and destroyed all their copies of the document. Once all copies of the document were gone, NSA went to the court and claimed first that the whole thing was a state secret and couldn't proceed, and then second that the group didn't have any standing to challenge the wiretaps in court because Al Haramain (now) had zero evidence that the taps had even occurred. The foundation and their lawyers have literally spent years of work recovering from that one mistake, and only the kind indulgence of a smarter than average judge enabled their lawsuit to survive at all. See this story by one of their lawyers: http://www.salon.com/2008/07/09/alharamain_lawsuit/ Don't make the same mistake when NSA, or their minions at the FBI or FISA or DoJ come to threaten YOU to suppress information that came to you through no fault of your own. John Gilmore ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
On Sep 6, 2013, at 6:13 AM, Jaap-Henk Hoepman j...@cs.ru.nl wrote: In this oped in the Guardian http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Bruce Schneier writes: Prefer symmetric cryptography over public-key cryptography. The only reason I can think of is that for public key crypto you typically use an American (and thus subverted) CA to get the recipients public key. What other reasons could there be for this advice? Public-key cryptography is less well-understood than symmetric-key cryptography. It is also tetchier than symmetric-key crypto, and if you pay attention to us talking about issues with nonces, counters, IVs, chaining modes, and all that, you see that saying that it's tetchier than that is a warning indeed. The magic of public key crypto is that it gets rid of the key management problem -- if I'm going to communicate with you with symmetric crypto, how do I get the keys to you? The pain of it is that it replaces it with a new set of problems. Those problems include that the amazing power of public-key crypto tempts one to do things that may not be wise. Jon PGP.sig Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On 26 August 2013 22:43, Perry E. Metzger pe...@piermont.com wrote: (I would prefer to see hybrid capability systems in such applications, like Capsicum, though I don't think any such have been ported to Linux and that's a popular platform for such work.) FWIW, we're working on a Linux port of Capsicum. Help is always welcome :-) ___ 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] Bruce Schneier has gotten seriously spooked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 08:48 PM, Chris Palmer wrote: Why would they perform the attack only for encryption software? They could compromise people's laptops by spiking any popular app. What is more important to them: A single system, or all of the comms going into and coming out of it? - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Too bizarre for real life, too normal to wind up on Art Bell. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqngUACgkQO9j/K4B7F8EtYgCgtMPqxWguJq/ey3jj/jsPFA3V iD0AoOSHbT8ZLZ7YxNLqdy5uOiS/6o4p =DGj7 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2013 09:02 PM, Chris Palmer wrote: First time I've heard of 128-bit symmetric called weak... Sure, RC4 isn't awesome but they seem to be saying that 128-bit keys per se are weak. calomel.org may be erring on the side of weak due to known vulnerabilities in RC4. Without good server authentication, the other stuff doesn't matter. I am inclined to agree with you. With Chrome, you get key pinning when talking to some sites (including Google sites, Tor, and Twtitter); I'd much rather have that and only 128-bit symmetric. Also, I don't know why you weren't getting forward secrecy; check your Firefox configuration. I did some poking around inside its configuration and it does not seem to be negotiating upward in strength, but for whatever it can get (see other post this evening). I am uncertain as to why; some investigation is in order, but slash/burn/upgrade may be safest. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Too bizarre for real life, too normal to wind up on Art Bell. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIqok4ACgkQO9j/K4B7F8HX2ACZAStTl0wR/JJqI7n182jLX6mD 5i0AnAopo0YASsPGYVVntF9KKUwwrpRN =9Acb -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 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] Why prefer symmetric crypto over public key crypto?
The magic of public key crypto is that it gets rid of the key management problem -- if I'm going to communicate with you with symmetric crypto, how do I get the keys to you? The pain of it is that it replaces it with a new set of problems. Those problems include that the amazing power of public-key crypto tempts one to do things that may not be wise. I find public-key cryptography to be full of dirty little secrets. Some of the notions inherent in public-key *infrastructure* are, on the face of them, preposterous. Consider the notion of a certificate authority. I am to trust some third party (the CA) that I've never met, and have not the slightest reason to trust, is able to make a believable assertion about the identity (and corresponding public-key binding), of some *other* party I've never met, and have no real reason to trust. It always struck me as another instance of there's no problem in CS that can't be solved by adding another layer of abstraction. I think this is an instance of a general problem with digitally-signed documents of all kinds: confusion about exactly what they are--a signature on a document (like a certificate) says nothing about the *essential truth* of the statements contained within the document. When SlushySign issues a certificate for www.crowbars-r-us.com, there's a subtle distinction between we believe this to be the appropriate binding between this public-key, and an entitity known as www.crowbars-r-us.com and this really is the binding between this pubic-key, and the entity you all know as www.crowbars-r-us.com. I started thinking about the essential truth problem back when the whole TPM thing was popular, and proponents were talking as if the digital signature of a computer stating that it was sane was somehow the same is said computer actually being sane. Absent independent verification, there's no way to distinguish a strongly-signed lie from a strongly-signed truth. That isn't necessarily a problem that's confined to PK systems. Any digital-signature scheme has that problem. The other thing that I find to be a dirty little secret in PK systems is revocation. OCSP makes things, in some ways, better than CRLs, but I still find them to be a kind of swept under the rug problem when people are waxing enthusiastic about PK systems. However, PK is the only pony we've managed to bring to this circus, so, we we make do with making the dirty little secrets as inoffensive as we can. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] I have to whistle to blow...
... but I must scream. http://kebesays.blogspot.com/2013/09/i-have-no-whistle-to-blow-but-i-must.html FYI, and thanks, Dan McD. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On 09/07/2013 12:04 AM, Ben Laurie wrote: On 26 August 2013 22:43, Perry E. Metzger pe...@piermont.com mailto:pe...@piermont.com wrote: (I would prefer to see hybrid capability systems in such applications, like Capsicum, though I don't think any such have been ported to Linux and that's a popular platform for such work.) FWIW, we're working on a Linux port of Capsicum. Help is always welcome :-) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography I implemented a lightweight, tightly-focused (well, it started out that way), capabilities-like system for Android kernels last year. It was a monumental PITA largely due to interior kernel-side APIs changing so frequently across kernel versions. We had mechanisms for binding capabilities to ELF binaries in a way that the kernel could verify. The project failed, largely because it kept being dragged around by marketing so often, that we never got it really nicely robust in any given direction. This week, it's a floor polish. Next week, it's a turbine maintenance system. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
