[Cryptography] Ars Technica on the Taiwanese National ID smart card break
Weeks after the informal announcement, the Taiwanese National ID smartcard break is finally getting press. It is a great example of a piece of certified crypto hardware that works poorly because of bad random number generation. Good explanation for your technical but not security oriented friends in Ars Technica: http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/ -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point
On Tue, 17 Sep 2013 12:15:48 -0400 Jerry Leichter leich...@lrw.com wrote: Actually, I think there is a potentially interesting issue here: RC4 is faster and requires significantly fewer resources than modern block ciphers. As a result, people would really like to use it - and actually they *will* continue to use it even in the face of the known attacks (which, *so far*, are hardly fatal except in specialized settings). If you are dealing with huge numbers of connections, you probably have hardware and AES is plenty fast -- modern Intel hardware accelerates it, too. (If you really want a fast stream cipher, why not use ChaCha20 or something else that is probably much better than RC4? I mean, if you're going to propose changing it, as you do, it won't interoperate anyway, so you can substitute something better.) In any case, I would continue to suggest that the weakest point (except for RC4) is (probably) not going to be your symmetric cipher. It will be protocol flaws and implementation flaws. No point in making the barn out of titanium if you're not going to put a door on it. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On Tue, 17 Sep 2013 11:35:34 -0400 Perry E. Metzger pe...@piermont.com wrote: Added c...@panix.com -- if you want to re-submit this (and maybe not top post it) I will approve it... Gah! Accidentally forwarded that to the whole list, apologies. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point
On the Paranoid Cryptoplumbing discussion: I'd like to note quite strongly that (with certain exceptions like RC4) the odds of wholesale failures in ciphers seem rather small compared to the odds of systems problems like bad random number generators, sabotaged accelerator hardware, stolen keys, etc., and a smart attacker goes for the points of weakness. I'm not going to put my admin hat on and stop the discussion so long as it remains relatively sane and technical, but for most purposes it is probably just reinforcing a steel door in a paper wall. (Of course, if the endpoints are trusted hardware running a formally verified capability operating system and you still have time on your hands, hey, why not? Of course, when I posted a long message about modern formal verification techniques and how they're now practical, no one bit on the hook.) All that said, even I feel the temptation for low performance applications to do something like Bill Frantz suggests. It is in the nature of people in our community to like playing with such things. Just don't take them *too* seriously please. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
Added c...@panix.com -- if you want to re-submit this (and maybe not top post it) I will approve it... Perry On Tue, 17 Sep 2013 11:08:43 -0400 Carl Ellison c...@panix.com wrote: If you can examine your setup and determine all possible memory in the device, count that memory in bit-equivalents, and discover that the number of bits is small (e.g., 8), then you can apply Maurer's test: ftp://ftp.inf.ethz.ch/pub/crypto/publications/Maurer92a.pdf Of course, if you're concerned that someone has slipped you a CPU chip with a PRNG replacing the RNG, you can't detect that without ripping the chip apart. On 9/12/13 11:00 AM, Perry E. Metzger pe...@piermont.com wrote: On Wed, 11 Sep 2013 17:06:00 -0700 Tony Arcieri basc...@gmail.com wrote: It seems like Intel's approach of using thermal noise is fairly sound. Is there any reason why it isn't more widely adopted? Actually, I think things like this mostly have been missing because manufacturers didn't understand they were important. Even the Raspberry Pi now has an SoC with a hardware RNG. In addition to getting CPU makers to always include such things, however, a second vital problem is how to gain trust that such RNGs are good -- both that a particular unit isn't subject to a hardware defect and that the design wasn't sabotaged. That's harder to do. Perry -- Perry E. Metzger pe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Ivan Ristić blog post on TLS best practices
Recommends phasing out RC4 among other things: http://blog.ivanristic.com/2013/09/updated-best-practices-deprecate-rc4.html -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Mon, 16 Sep 2013 17:47:11 -0700 Bill Frantz fra...@pwpconsult.com wrote: Authentication is achieved by signing the entire exchange with DSA. -- Change the protocol to sign the exchange with both RSA and DSA and send and check both signatures. Remember to generate the nonce for DSA using a deterministic method. The current data exchange encryption uses SHA1 in HMAC mode and 3DES in CBC mode with MAC then encrypt. The only saving grace is that the first block of each message is the HMAC, which will make the known plain text attacks on the protocol harder. -- I would replace this protocol with one that encrypts twice and MACs twice. Using one of the modes which encrypt and MAC in one operation as the inner layer is very tempting with a different cypher in counter mode and a HMAC as the outer layer. I confess I'm not sure what the current state of research is on MAC then Encrypt vs. Encrypt then MAC -- you may want to check on that. Also, you may want to generate your IVs deterministically from a block cipher in counter mode, and not actually send them on the wire -- see earlier discussions for why that is good, but in addition to assuring the IVs are unpredictable and do not repeat, it prevents a bad actor from using the IV as a covert channel. (Some would argue against using CBC mode entirely -- see Rogaway's paper on block cipher modes.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point
On Tue, 17 Sep 2013 10:07:38 -0700 Tony Arcieri basc...@gmail.com wrote: The NSA of course participated in active attacks too, but it seems their main MO was passive traffic collection. That's not what I've gotten out of the most recent revelations. It would seem that they've been evading rather than breaking the crypto: putting back doors in protocols, stealing keys, encouraging weak RNGs, adding flaws to hardware, etc. -- as well as doing active attacks using stolen or broken CA keys. I don't doubt that they archive everything they can forever, of course. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Johns Hopkins round table on NSA and Crypto
Matthew Green tweeted earlier today that Johns Hopkins will be hosting a roundtable at 10am EDT tomorrow (Wednesday, September 18th) to discuss the NSA crypto revelations. Livestream will be at: https://connect.johnshopkins.edu/jhuisicrypto/ Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On Tue, 17 Sep 2013 16:52:26 -0400 John Kemp j...@jkemp.net wrote: On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker hal...@gmail.com wrote: The objective of PRISM-hardening is not to prevent an attack absolutely, it is to increase the work factor for the attacker attempting ubiquitous surveillance. Examples include: Forward Secrecy: Increases work factor from one public key per host to one public key per TLS session. How does that work if one of PRISMs objectives is to compromise data _before_ it is transmitted by subverting its storage in one way or another? Forward secrecy does nothing to impact the work factor in that case. So, PFS stops attackers from breaking all communications by simply stealing endpoint RSA keys. You need some sort of side channel or reduction of the RNG output space in order break an individual communication then. (Note that this assumes no cryptographic breakthroughs like doing discrete logs over prime fields easily or (completely theoretical since we don't really know how to do it) sabotage of the elliptic curve system in use.) Given that many real organizations have hundreds of front end machines sharing RSA private keys, theft of RSA keys may very well be much easier in many cases than broader forms of sabotage. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] A lot to learn from Business Records FISA NSA Review
On Sat, 14 Sep 2013 20:37:07 -0700 John Gilmore g...@toad.com wrote: [A very interesting message, and I'm going to reply to just one tiny detail in it...] We in the outside world *invented* all of NSA's infrastructure. They buy it from us, and are just users like most computer users. (Yes, they have programmers and they write code, but their code seems mostly applications, not lower level OS improvements or protocols. I'm not talking about the parts of NSA that find security holes in other peoples' infrastructure, nor the malware writers.) Well, we do know they created things like the (not very usable) seLinux MAC (Multilevel Access Control) system, so clearly they do some hacking on security infrastructure. (I will not argue with the larger point though.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Apple and Certificate Pinning
I've not been able to figure out if Apple is using certificate pinning for its applications (including its update systems) that seem to use PKI. Does anyone know? -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: entropy of randomness discussion is falling...
One wants maximum entropy not only from one's RNG but also from one's discussions about randomness. Sadly, entropy is measured based on the level of surprise at the content, and the level of surprise is going down in the current discussion. As surprise goes to zero, so does interest on the part of the couple thousand people reading along. I'd like to ask participants to please: 1) Write compactly but clearly. 2) Avoid repeating themselves. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Key management, key storage. (was Re: prism proof email, namespaces, and anonymity)
On Sat, 14 Sep 2013 17:23:40 +0100 Max Kington mking...@webhanger.com wrote: The keys. This to me is the critical point for widespread adoption, key management. How do you do this in a way that doesn't put people off immediately. You don't seem to be entirely talking about key management, given that you talk about mailpile and parley. Parley seems to be simply talking about *key storage* for example, which is a different kettle of fish. However, on the topic of key management itself, my own proposal was described here: http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html In summary, I proposed a way you can map IDs to keys through pure long term observation/widely witnessed events. The idea is not original given that to some extent things like Certificate Transparency already do this in other domains. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On Sat, 14 Sep 2013 09:31:22 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: Also see RFC 3766 from almost a decade ago; it has stood up fairly well. For those not aware, the document, by Paul and Hilarie Orman, discusses equivalent key strengths and practical brute force methods, giving extensive detail on how all calculations were done. A URL for the lazy: http://tools.ietf.org/html/rfc3766 It is very well done. I'd like to see an update done but it does feel like the methodology was well laid out and is difficult to argue with in general. The detailed numbers are slightly different from others out there, but not so much as to change the general recommendations that have been floating around. Their table, from April 2004, looked like this: +-+---+--+--+ | System | | | | | requirement | Symmetric | RSA or DH| DSA subgroup | | for attack | key size | modulus size | size | | resistance | (bits)| (bits) | (bits) | | (bits) | | | | +-+---+--+--+ | 70 | 70| 947 | 129 | | 80 | 80| 1228 | 148 | | 90 | 90| 1553 | 167 | |100 |100| 1926 | 186 | |150 |150| 4575 | 284 | |200 |200| 8719 | 383 | |250 |250|14596 | 482 | +-+---+--+--+ They had some caveats, such as the statement that if TWIRL like machines appear, we could presume an 11 bit reduction in strength -- see the RFC itself for details. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Quantum Computers for Shor's Algorithm (was Re: Perfection versus Forward Secrecy)
On Sat, 14 Sep 2013 11:49:50 -0700 Tony Arcieri basc...@gmail.com wrote: We still haven't seen quantum computers built yet which can truly rival their conventional electronic brethren, especially if you look at it from a cost perspective. DWave computers are interesting from a novelty perspective, but not really ready to replace existing computers, even for highly specialized tasks like running Shor's algorithm. Nevertheless, if you've been following the trends in quantum computers over the last few years, they are getting larger, and DWave is an example of them moving out of the labs and turning into something you can buy. I wouldn't be surprised to see a large quantum computer built in the next two decades. DWave has never unambiguously shown their machine actually is a quantum computer, and even if it is, given its design it very specifically cannot run Shor's algorithm or anything like it. I'm unaware of a quantum computer of more than five qbits that has been demonstrated that can run Shor's algorithm, and that specific method, using a molecule with five distinct NMR peaks, cannot really be extended further. If you can find a reference to quantum computer with more qbits that can run Shor's algorithm that has been demonstrated in public, I would be very interested. (And yes, I'm aware of the two photon device that factored the number 21, though I believe the team used tricks to make that work -- opinions on whether that work could scale would be welcome of course.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Quantum Computers for Shor's Algorithm (was Re: Perfection versus Forward Secrecy)
On Sat, 14 Sep 2013 12:42:22 -0700 Tony Arcieri basc...@gmail.com wrote: Sure, I never said it could ;) I also said that conventional computers can still outpace it. I'm certainly NOT saying, that in their present capacity, that DWave computers are any sort of threat to modern cryptography. But still, it goes to show that quantum computers are happening. Given that the DWave design is totally unsuitable for Shor's algorithm, it seems to have no real bearing on the situation in either direction. To break 1024 bit keys (a minimum capability for a useful Shor machine, I'd say), you need several thousand qbits. I've not heard of a demonstration of more than a half dozen, and I've seen no progress on the topic in a while. It isn't like last year we could do six and the year before five and this year someone announced fifteen -- there have been no incremental improvements. It is of course possible that there's been secret research on this at NSA which has gotten far further, but I would expect that the manufacturing technology needed to do that would require a huge number of people to pull off, too many to keep quiet indefinitely. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Stealthy Dopant-Level Hardware Trojans
On Fri, 13 Sep 2013 11:49:24 +0200 Eugen Leitl eu...@leitl.org wrote: http://people.umass.edu/gbecker/BeckerChes13.pdf Stealthy Dopant-Level Hardware Trojans[...] This is pretty clearly a big deal. The fact that you can skew HRNGs just by fiddling with dopant levels is something I would have suspected, but now that we know, I think need for chip companies to provide access to the raw HRNG output has become even more obvious. It is not a question of not trusting the engineers who work on the hardware. It is a question of not wanting to trust every single individual in a long supply chain. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Security is a total system problem (was Re: Perfection versus Forward Secrecy)
On Fri, 13 Sep 2013 08:08:38 +0200 Eugen Leitl eu...@leitl.org wrote: Why e.g. SWIFT is not running on one time pads is beyond me. I strongly suspect that delivering them securely to the vast number of endpoints involved and then securing the endpoints as well would radically limit the usefulness. Note that it appears that even the NSA generally prefers to compromise endpoints rather than attack crypto. The problem these days is not that something like AES is not good enough for our purposes. The problem is that we too often build a reinforced steel door in a paper wall. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Summary of the discussion so far
On Fri, 13 Sep 2013 15:46:58 -0500 Nico Williams n...@cryptonector.com wrote: On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote: On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams n...@cryptonector.com wrote: Traffic analysis can't really be defeated, not in detail. What's wrong with mix networks? First: you can probably be observed using them. Sure, but the plan I described a few weeks ago would presumably end with hundreds of thousands or millions of users if it worked at all. Second: I suspect that to be most effective the mix network also has to be most inconvenient (high latency, for example). Sure, that's true for voice and such. However, for messaging apps, that's not an issue. See my claims here: http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html (That was part of a three message sequence that began with these two: http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html and http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html but only the second of those two is really relevant to this particular discussion.) Third: the mix network had better cross multiple jurisdictions that are not accustomed to cooperating with each other. This seems very difficult to arrange. That's important for onion networks, not mix networks. I understand that the distinction isn't well understood by most, but it can be summarized thus: an onion network depends on no one observing the whole network to provide security, while a mix network uses sufficient cover traffic and delay induction to prevent people from being able to learn much even if they can observe the whole network and control a minority of nodes. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism proof email, namespaces, and anonymity
On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey crypto@gmail.com wrote: Everyone, The more I think about it, the more important it seems that any anonymous email like communications system *not* include people who don't want to be part of it, and have lots of defenses to prevent its anonymous communications from becoming a nightmare for its participants. If the goal is to make PRISM stop working and make the email part of the internet go dark for spies (which definitely includes a lot more than just US spies!), then this system has to be something that lots of people will want to use. There should be multiple defenses against spam and phishing and other nasty things being sent in this system, with enough designed-in flexibility to deal with changes in attacker behavior over tome. Indeed. As I said in the message I just pointed Nico at: http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html Quoting myself: Spam might be a terrible, terrible problem in such a network since it could not easily be traced to a sender and thus not easily blocked, but there's an obvious solution to that. I've been using Jabber, Facebook and other services where all or essentially all communications require a bi-directional decision to enable messages for years now, and there is virtually no spam in such systems because of it. So, require such bi-directional friending within our postulated new messaging network -- authentication is handled by the public keys of course. Some thoughts off the top of my head. Note that while I think all these can be done with crypto somehow, I am not thinking of how to do them yet, except in very general terms. a. You can't freely send messages to me unless you're on my whitelist. That's my solution. As I note, it seems to work for Jabber, Facebook and other such systems, so it may be sufficient. b. This means an additional step of sending me a request to be added to your whitelist. This needs to be costly in something the sender cares about--money, processing power, reputation, solving a captcha, rate-limits to these requests, whatever. I'm not sure about that. Jabber doesn't really rate limit the number of friend requests I get per second but I don't seem to get terribly many, perhaps because fakes at most could hide some attempted phish in a user@domain name, which isn't very useful to scammers. g. The format of messages needs to be restricted to block malware, both the kind that wants to take over your machine and the kind that wants to help the attacker track you down. Plain text email only? Some richer format to allow foreign language support? My claim that I make in my three messages from August 25 is that it is probably best if we stick to existing formats so that we can re-use existing clients. My idea was that you still talk IMAP and SMTP and Jabber to a server you control (a $40 box you get at Best Buy or the like) using existing mail and chat clients, but that past your server everything runs the new protocols. In addition to the message I linked to above, see also: http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html for my wider proposals. I agree this makes email delivered malware continue to be a bit of a problem, though you could only get it from your friends. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On Wed, 11 Sep 2013 17:06:00 -0700 Tony Arcieri basc...@gmail.com wrote: It seems like Intel's approach of using thermal noise is fairly sound. Is there any reason why it isn't more widely adopted? Actually, I think things like this mostly have been missing because manufacturers didn't understand they were important. Even the Raspberry Pi now has an SoC with a hardware RNG. In addition to getting CPU makers to always include such things, however, a second vital problem is how to gain trust that such RNGs are good -- both that a particular unit isn't subject to a hardware defect and that the design wasn't sabotaged. That's harder to do. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On Wed, 11 Sep 2013 21:06:35 -0400 Marcus D. Leech mle...@ripnet.com wrote: And this is the reason that I'd be in favour of diversity -- using sound cards, lava-lamps, etc, etc. Sources that don't explicitly identify themselves as the random number generator. As a practical matter, though, people aren't going to put lava lamps and cameras in their colos along with every 1U box and blade server. They also won't attach them to the $40 boxes they buy at Best Buy. Good solutions probably involve hardware that is well tested, on motherboard, dirt cheap and easy for software to field validate. Yes, this is hard. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: Please pick appropriate Subject lines...
A quick note: many recent postings with very useful content have gone out with entirely inappropriate Subject: lines because of threads shifting topics. Always look at your Subject: line and ask yourself if it should be updated. (And thank all of you for not top posting. It is appreciated.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
On Wed, 11 Sep 2013 06:49:45 +0200 Raphael Jacquot sxp...@sxpert.org wrote: according to http://en.wikipedia.org/wiki/Padding_(cryptography) , most protocols only talk about padding at the end of the cleartext before encryption. now, how about adding some random at the beginning of the cleartext, say, 2.5 times the block size, that is 40 bytes for the example above, of random stuff before the interesting text appears ? The padding at the end is to make sure that you have a full block of data for a block cipher, since your actual message will usually be shorter than a full block. In symmetric systems, it is not per se a security feature. (Asymmetric Adding padding at the front to prevent cryptanalysts from using cribs (that is, known plaintext) seems useless to me. Even if the padding was of random length, it is of necessity going to be short. If you have a technique that depends on known plaintext, crib dragging (that is, trying all of the small number of possibilities) is easy. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Killing two IV related birds with one stone
It occurs to me that specifying IVs for CBC mode in protocols like IPsec, TLS, etc. be generated by using a block cipher in counter mode and that the IVs be implicit rather than transmitted kills two birds with one stone. The first bird is the obvious one: we now know IVs are unpredictable and will not repeat. The second bird is less obvious: we've just gotten rid of a covert channel for malicious hardware to leak information. Note that if you still transmit the IVs, a misimplemented client could still interoperate with a malicious counterparty that did not use the enforced method for IV calculation. If you don't transmit the IVs at all but calculate them, the system will not interoperate if the implicit IVs aren't calculated the same way by both sides, thus ensuring that the covert channel is closed. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On Thu, 12 Sep 2013 08:47:16 +1000 (EST) Dave Horsfall d...@horsfall.org wrote: Another whacky idea... Given that there is One True Source of randomness to wit radioactive emission, has anyone considered playing with old smoke detectors? People have experimented with all sorts of stuff, and you can make any of hundreds of methods from cameras+lava lamp+hash function to sound cards to radioactive sources work if you have budget and time. The issue is not finding ways to generate entropy. The issue is that you need something that's cheap and ubiquitous. User endpoints like cell phones have users to help them generate entropy, but the world's routers, servers, etc. do not have good sources, especially at first boot time, and for customer NAT boxes and the like the price points are vicious. The attraction of methods that use nothing but a handful of transistors is that they can be fabricated on chip and thus have nearly zero marginal cost. The huge disadvantage is that if your opponent can convince chip manufacturers to introduce small changes into their design, you're in trouble. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Killing two IV related birds with one stone
On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter leich...@lrw.com wrote: ...Note that if you still transmit the IVs, a misimplemented client could still interoperate with a malicious counterparty that did not use the enforced method for IV calculation. If you don't transmit the IVs at all but calculate them, the system will not interoperate if the implicit IVs aren't calculated the same way by both sides, thus ensuring that the covert channel is closed. Ah, but where did the session and IV-generating keys come from? The same random generator you now don't trust to directly give you an IV? Certainly, but if you remove most or all covert channels, you've narrowed the problem down to auditing the RNG instead of having to audit much more of the system. It is all a question of small steps towards better assurance. No one measure will fix everything. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Fw: how could ECC params be subverted other evidence
Forwarding because Adam apparently has distinct envelope and From: addresses and didn't notice the bounce. Note that anyone replying and attributing this message to *me* will be laughed at mercilessly as their message is rejected. Perry Begin forwarded message: Date: Tue, 10 Sep 2013 13:42:57 +0200 From: Adam Back a...@cypherspace.org To: Perry E. Metzger pe...@piermont.com Cc: Alexander Klimov alser...@inbox.ru, Cryptography List cryptography@metzdowd.com, Adam Back a...@cypherspace.org Subject: Re: [Cryptography] how could ECC params be subverted other evidence Perry wrote: The Times reported that a standard [...] had been subverted, and there had been much internal congratulation in a memorandum. [...]This was only an example, the context in the Guardian and the Times made it clear others are probably lurking. The important potential backdoor is NIST 186-3 curves in Peter Fairbrother's reply, and I think that would be a good place to focus analysis. (DRBG is largely irrelevant due suspected compromised state since 2007, and very limited use. It is also a different type of issue - not backdoored curves, arguably backdoored parameters). I would like to hear also from other readers, who may have a deeper understanding of EC math and parameter selection. I do think people should be careful to distinguish between three things: 1 political confirmed backdoor claims from whistleblower documents as interpreted by journalists (technical articles by eg Schneier exempted); 2 possible backdoor (showing that a parameter or key generation lacks sufficient fairness in its generation) 3 actual verifiable sabotage (the actual backdoor keys, previously unpublished implausible design failure, software backdoor etc.) We need accuracy because once the dust has settled people will be making crypto protocol design implementation decisions based on what is concluded. Speculate away, but be clear. Adam ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Reports: NSA, GCHQ used forged certs to impersonate Google
The story has been floating around for some days now. Apparently, Man in the Middle attacks have been used quite extensively, including against the Brazilian state oil company, and a major international wire transfer network. http://www.slate.com/blogs/future_tense/2013/09/09/shifting_shadow_stormbrew_flying_pig_new_snowden_documents_show_nsa_deemed.html I think this indicates that Certificate Transparency and similar techniques need to be deployed quickly. CAs have been dead as a form of real assurance for some time now, but at this point the dance party on the grave has gone on a bit too long. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sun, 8 Sep 2013 15:22:32 -0400 Perry E. Metzger pe...@piermont.com wrote: Ah, now *this* is potentially interesting. Imagine if you have a crypto accelerator that generates its IVs by encrypting information about keys in use using a key an observer might have or could guess from a small search space. Oh, and of course, if you're doing a DSA style algorithm, you can leak information in your choice of random nonce. This is yet more reason to force protocols to use nonces that are deterministic based on context, and to enforce that. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Tue, 10 Sep 2013 17:04:51 -0400 Joe Abley jab...@hopcount.ca wrote: On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote: then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. How would this work, in practice? Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Note that the apparent attacks against Petrobras, SWIFT and others disclosed a few days ago appear to have used precisely this attack. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Fw: how could ECC params be subverted other evidence
On Tue, 10 Sep 2013 16:45:23 -0400 John Kelsey crypto@gmail.com wrote: [DBRG] seemed like a really weird place to put a backdoor, because it was insanely slow, and it seemed unlikely to get any significant use. As an aside, this is just the instance we know about, partially because they screwed up, partially because the New York Times saw fit to let us have confirmation of what was suspected in public. I presume they've been more careful in other places, and that this is not their only work. I presume that they knew this would not be used much and it was only a target of opportunity -- and that they've gotten much more interesting fixes in elsewhere, perhaps even in other parts of the NIST RNG standards (though it would *seem* much harder to gimmick those). And I, at least, had internalized the idea that we weren't going to get intentional bad advice or sabotage from another part of the federal government. You're not the only person feeling betrayed. For many years, the NSA people appeared on our doorsteps offering help in many, many contexts -- IETF for example. The awful part is, many of them may have been completely sincere. The IA side of the house *does*, in fact, depend on COTS hardware to secure most of the Federal Government. They *do* have an interest in keeping US commercial targets safe from attack. However, even if many of the NSA people who participated in standards work were sincere, their good will has been ruined by other NSA people who used the sincere ones as cover for their machinations. We now have to be suspicious of all of them, probably permanently, and that's bad for everyone. I imagine that there are some people inside the NSA now yelling at others about how they've made it ever so much harder to fix the security of most of the Federal Government, which ineed depends on COTS hardware. Now even if they come to us with really good advice, we have no idea if we should take it because we can't know they're not lying to us. None the less, it is done, and those of us on the outside can't depend on NSA participants in standards work any longer. A set of short sighted, foolish decisions have created tragedy for all. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
On Tue, 10 Sep 2013 17:04:04 -0400 Jerry Leichter leich...@lrw.com wrote: Phil Rogoway has a paper somewhere discussing the right way to implement cryptographic modes and API's. It would be useful to get a URL for it. In particular, he recommends changing the definition of CBC from: E_0 = IV # Not transmitted E_{i+1} = E(E_i XOR P_{i+1}) to E_0 = E(IV) # Not transmitted E_{i+1} = E(E_i XOR P_{i+1}) You make no mention there of whether the key used to encrypt the IV is the same as that used for the plaintext. I presume if you need a lot of IVs (see protocols like IPsec), and have enough key material, a second key might be of value for that -- but I don't know what all the ins and outs are, and would prefer to read the literature... Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES state of the art...
On Mon, 9 Sep 2013 14:18:41 +0300 Alexander Klimov alser...@inbox.ru wrote: On Sun, 8 Sep 2013, Perry E. Metzger wrote: What's the current state of the art of attacks against AES? Is the advice that AES-128 is (slightly) more secure than AES-256, at least in theory, still current? I am not sure what is the exact attack you are talking about, but I guess you misunderstood the result that says: the attack works against AES-256, but not against AES-128 as meaning that AES-128 is more secure. It can be the case that to break AES-128 the attack needs 2^240 time, while to break AES-256 it needs 2^250 time. Here AES-128 is not technically broken, since 2^240 2^128, but AES-256 is broken, since 2^250 2^256, OTOH, AES-256 is still more secure against the attack. There is a related key attack against AES-256 that breaks it in order 2^99.5, far worse than 2^250! However, several people seem to have assured me (in private email) that they think such related key attacks are not important in practice. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: traffic levels
List traffic levels are very high right now. Although the current situation is worrisome to many of us, the list becomes less useful to all when it becomes so clogged with posts that it becomes impossible for any reasonable person to read it. I and the co-moderators are probably going to start being much more strict about content until things settle down. Do not be surprised or offended when you get a rejection -- it is nothing personal. Some rules of thumb: SHORT BEATS LONG: Don't ramble, get to the point, avoid unnecessary asides, trim back what you're quoting to the minimum. This is especially important in replies on long threads. IMPORTANT BEATS TRIVIAL: The more real, interesting, and new content, the more likely we are to forward it. DON'T BE REDUNDANT: If you already said something a couple of times in a thread, don't repeat it endlessly. Fixing a clear misunderstanding is okay, of course. TECHNICAL BEATS POLITICAL: The list explicitly permits political postings, but especially when the load is this high, they should be informative and insightful. I'll almost always forward technical cryptography and protocol discussion. BARE LINKS ARE IRRITANTS: If you post a link to something, it should explain clearly why someone might want to click. Even a sentence will do. TOP POSTING IS AN ABOMINATION BEFORE THE MODERATOR: ...and I am an angry, old-testament sort of moderator, too. Lastly: I've had to ban two people in the last week for getting incredibly insulting after I would not forward their postings. It should go without saying that calling me a fascist, an NSA plant, etc. is unlikely to alter my opinion of your posting in a positive way. There are other, unmoderated forums (with even more volume) -- you know how to find them if you like. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Random number generation influenced, HW RNG
First, David, thank you for participating in this discussion. To orient people, we're talking about whether Intel's on-chip hardware RNGs should allow programmers access to the raw HRNG output, both for validation purposes to make sure the whole system is working correctly, and if they would prefer to do their own whitening and stretching of the output. On Sun, 08 Sep 2013 21:40:34 -0700 David Johnston d...@deadhat.com wrote: Well, since you personally did this, would you care to explain the very strange design decision to whiten the numbers on chip, and not provide direct access to the raw unwhitened output. #1 So that that state remains secret from things trying to discern that state for purposes of predicting past or future outputs of the DRBG. That seems like a misguided rationale. In particular, given that virtually all crypto software and existing kernels already have to cope with hardware that does not provide this capability, it is probably better that a hardware RNG not be a cryptographic PRNG. It should be a source of actual hard-random bits that feed in to the commonly used software mechanisms. If you can't generate enough of them to satisfy all possible demand, then I think it is architecturally far safer to allow software to make the decision about how to stretch the scarcity, and in any case, the software needs to exist anyway because other hardware does not have the capability. As it stands, the major consumers of your RNG, like the Linux kernel, already end up mixing it in to a software RNG rather than implicitly trusting it. It would be better to go further than this, I think. A far greater concern than non-Intel engineers being bad at building a random number generator in softare is that a fabrication flaw, a post-manufacturing failure, or an intentional fabrication failure induced by a paid agent would reduce the security of the system. It is difficult to test such things as the system is constructed. #2 So that one thread cannot undermine a second thread by putting the DRNG into a broken mode. There is only one DRNG, not one per core or one per thread. Having one DRNG per thread would be one of the many preconditions necessary before this could be contemplated. I think the same counterarguments hold. In any case, making it impossible even for a privileged process like the kernel to test the thing before returning it to its normal state seems like an unfortunate choice. #3 Any method of access is going have to be documented and supported and maintained as a constant interface across many generations of chip. We don't throw that sort of thing into the PC architecture without a good reason. There is, however, excellent reason here. #4 Obviously there are debug modes to access raw entropy source output. The privilege required to access those modes is the same debug access necessary to undermine the security of the system. This only happens in very controlled circumstances. Could you be more explicit about that? Please note we are not asking this sort of thing out of malice. There is now a document in wide circulation claiming multiple chip vendors have had their crypto hardware compromised by intent. Regardless of your own personal integrity, there are others inside your organization that may very well be beneficiaries of the $250M a year the NSA is now spending on undermining security. Indeed, were I running that program, I would regard your group as a key target and attempt to place someone inside it. Do you not agree that you're a major vendor and that your hardware would be a very tempting target for such a program, which we now know to exist? Access to the raw output would have been a massive can of worms. And yet, you will note that many, many security types would prefer raw output to a finished cryptographic random number source. Intel could always provide a standard C routine to do the conversion from the raw output into a suitable whitened and stretched output. The statistical properties of the entropy source are easy to model and easy to test online in hardware. They are described in the CRI paper if you want to read them. But, forgive me for saying this, in an environment where the NSA is spending $250M a year to undermine efforts like your own it is impossible for third parties to trust black boxes any longer. I think you may not have absorbed that what a week or two ago was a paranoid fantasy turns out to be true. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] how could ECC params be subverted other evidence
On Tue, 10 Sep 2013 00:23:51 +0200 Adam Back a...@cypherspace.org wrote: On Mon, Sep 09, 2013 at 06:03:14PM -0400, Perry E. Metzger wrote: On Mon, 9 Sep 2013 14:07:58 +0300 Alexander Klimov wrote: No. They are widely used curves and thus a good way to reduce conspiracy theories that they were chosen in some malicious way to subvert DRBG. Er, don't we currently have documents from the New York Times and the Guardian that say that in fact they *did* subvert them? From what I could see it was more like people are taking more seriously the criticism that they could have subverted the curves because the published parameter generation seeds are big hex strings (rather than the typical literaly quote or digits of pi), and therefore there is no way to verify the parameters were chosen fairly. The Times reported that a standard from about the right time period that had been criticized in a 2007 paper by some researchers at Microsoft (who reported a backdoor) had been subverted, and there had been much internal congratulation in a memorandum. The only such standard was apparently the one in question. This is no longer speculation, we now know that they seem to have done this. This was only an example, the context in the Guardian and the Times made it clear others are probably lurking. As I've said before, a week ago I would have called the entire idea paranoia. Now, the evidence has changed. When the facts change, I change my mind. Relatedly it seems to me that backdooring is a tricky business, especially if you care about plausible deniability, and about actual security in the face of blackhats or other state actors who may rediscover the sabotaged parameters, design, code, master keys in the binary etc and exploit it rather than publish it and have it fixed by the vendor. I think you're hardly the only person to note that this is a very dangerous game they've played, in some cases literally endangering people's lives. Presumably the reverse engineering deities are warming up their softICE to pore over the windows and other OS crypto code. And, I would imagine, people are probably ripping apart popular hardware crypto implementations, decapping the chips, and photographing them as we speak. The memoranda spoke of hardware crypto systems being subverted. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On Mon, 9 Sep 2013 14:07:58 +0300 Alexander Klimov alser...@inbox.ru wrote: On Mon, 9 Sep 2013, Daniel wrote: Is there anyone on the lists qualified in ECC mathematics that can confirm that? NIST SP 800-90A, Rev 1 says: The Dual_EC_DRBG requires the specifications of an elliptic curve and two points on the elliptic curve. One of the following NIST approved curves with associated points shall be used in applications requiring certification under [FIPS 140]. More details about these curves may be found in [FIPS 186], the Digital Signature Standard. And what ramifications it has, if any.. No. They are widely used curves and thus a good way to reduce conspiracy theories that they were chosen in some malicious way to subvert DRBG. Er, don't we currently have documents from the New York Times and the Guardian that say that in fact they *did* subvert them? Yes, a week ago this was paranoia, but now we have confirmation, so it is no longer paranoia. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On Tue, 10 Sep 2013 00:25:20 +0100 Peter Fairbrother zenadsl6...@zen.co.uk wrote: On 09/09/13 23:03, Perry E. Metzger wrote: On Mon, 9 Sep 2013, Daniel wrote: [...] They are widely used curves and thus a good way to reduce conspiracy theories that they were chosen in some malicious way to subvert DRBG. Er, don't we currently have documents from the New York Times and the Guardian that say that in fact they *did* subvert them? Yes, a week ago this was paranoia, but now we have confirmation, so it is no longer paranoia. I did not see that, and as far as I can tell there is no actual confirmation. Quoting: Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all This has generally been accepted to only match the NIST ECC RNG standard, i.e. Dual_EC_DRBG, with the critique in question being On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng which may be found here: http://rump2007.cr.yp.to/15-shumow.pdf Do you have an alternative theory? Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why are some protocols hard to deploy? (was Re: Opening Discussion: Speculation on BULLRUN)
On Sat, 07 Sep 2013 18:50:06 -0700 John Gilmore g...@toad.com wrote: It was never clear to me why DNSSEC took so long to deploy, [...] PS: My long-standing domain registrar (enom.com) STILL doesn't support DNSSEC records -- which is why toad.com doesn't have DNSSEC protection. Can anybody recommend a good, cheap, reliable domain registrar who DOES update their software to support standards from ten years ago? I believe you have answered your own question there, John. Even if we assume subversion, deployment requires cooperation from too many people to be fast. One reason I think it would be good to have future key management protocols based on very lightweight mechanisms that do not require assistance from site administrators to deploy is that it makes it ever so much easier for things to get off the ground. SSH deployed fast because one didn't need anyone's cooperation to use it -- if you had root on a server and wanted to log in to it securely, you could be up and running in minutes. We need to make more of our systems like that. The problem with DNSSEC is it is so obviously architecturally correct but so difficult to do deploy without many parties cooperating that it has acted as an enormous tar baby. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Impossible trapdoor systems (was Re: Opening Discussion: Speculation on BULLRUN)
On Sat, 07 Sep 2013 20:14:10 -0700 Ray Dillinger b...@sonic.net wrote: On 09/06/2013 05:58 PM, Jon Callas wrote: We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. I've seen this assertion several times in this thread, but I cannot help thinking that it depends on what *kind* of backdoor you're talking about, because there are some cases in which as a crypto amateur I simply cannot see how the construction of an asymmetric cipher could be accomplished. As an example of a backdoor that doesn't obviously permit an asymmetric-cipher construction, consider a broken cipher that has 128-bit symmetric keys; but one of these keys (which one depends on an IV in some non-obvious way that's known to the attacker) can be used to decrypt any message regardless of the key used to encrypt it. That key would then be known as the private key. The public key is the set of magic values used in the symmetric cipher (say in the one way functions of the Feistel network if it were a Feistel cipher) such that such a magic decryption key exists. However, it is not a valid encryption key; no matter what you encrypt with it you get the same ciphertext. So? If you have an algorithm that creates such ciphers in such a way that the magic key is hard to find, then you produce all that you want and you have a very powerful primitive for constructing public key systems. You don't have an obvious signature algorithm yet, but I'm sure we can think of one with a touch of cleverness. That said, your hypothetical seems much like imagine that you can float by the power of your mind alone. The construction of such a cipher with a single master key that operates just like any other key seems nearly impossible, and that should be obvious. A symmetric cipher encryption function is necessarily one-to-one and onto from the set of N bit blocks to itself. After all, if two blocks encrypt to the same block, you can't decrypt them, and one block can't encrypt to two blocks. If every key produces the same function from 2^N to 2^N, it will be rapidly obvious, so keys have to produce quite different mappings. Your magic key must then take any block of N bits and magically produce the corresponding plaintext when any given ciphertext might correspond to many, many different plaintexts depending on the key. That's clearly not something you can do. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sun, 8 Sep 2013 15:55:52 -0400 Thor Lancelot Simon t...@rek.tjls.com wrote: On Sun, Sep 08, 2013 at 03:22:32PM -0400, Perry E. Metzger wrote: Ah, now *this* is potentially interesting. Imagine if you have a crypto accelerator that generates its IVs by encrypting information about keys in use using a key an observer might have or could guess from a small search space. Hadn't even occurred to me since it seems way more blatant than the other sort of leaks I was thinking of, but of course the mere fact that it is blatant doesn't mean that it would never be tried... Well, I guess it depends what your definition of blatant is. Treating the crypto hardware as a black box, it would be freaking hard to detect, no? Ah, but it only needs to be found once to destroy the reputation of a company. Inserting bugs into chips (say, random number generators that won't work well in the face of fabrication processes that alter analog characteristics of circuits slightly) results in a could be an accident sort of mistake. Altering a chip to insert an encrypted form of a key into the initialization vectors in use cannot be explained away that way. You may say but how would you find that?. However, I've worked in recent years with people who decap chips, photograph the surface and reconstruct the circuits on a pretty routine basis -- tearing apart secure hardware for fun and profit is their specialty. Even when this process destructively eliminates in-RAM programming, usually weaknesses such as power glitching attacks are discovered by the examination of the dead system on the autopsy table and can then be used with live hardware. Now that it has been revealed that the NSA has either found or arranged for bugs in several chips, I would presume that some of these people are gearing up for major teardowns. Not all such teardowns will happen in the open community, of course -- I'd expect that even now there are folks in government labs around the world readying their samples, their probe stations and their etchant baths. Hopefully the guys in the open community will let us know what's bad before the other folks start exploiting our hardware silently, as I suspect the NSA is not going to send out a warning. I also wonder -- again, not entirely my own idea, my whiteboard partner can speak up for himself if he wants to -- about whether we're going to make ourselves better or worse off by rushing to the safety of PFS ciphersuites, which, with their reliance on DH, in the absence of good RNGs may make it *easier* for the adversary to recover our eventual symmetric-cipher keys, rather than harder! I'll repeat the same observation I've made a lot: Dorothy Denning's description of the Clipper chip key insertion ceremony described the keys as being generated deterministically using an iterated block cipher. I can't find the reference, but I'm pretty sure that when she was asked why, the rationale was that an iterated block cipher can be audited, and a hardware randomness source cannot. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] AES state of the art...
What's the current state of the art of attacks against AES? Is the advice that AES-128 is (slightly) more secure than AES-256, at least in theory, still current? (I'm also curious as to whether anyone has ever proposed fixes to the weaknesses in the key schedule...) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Paper on Tor deanonymization: Users Get Routed
A new paper on the Tor network, entitled Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries. https://security.cs.georgetown.edu/~msherr/papers/users-get-routed.pdf Quote to whet your appetite: We present the first analysis of the popular Tor anonymity network that indicates the security of typical users against reasonably realistic adversaries in the Tor network or in the underlying Internet. Our results show that Tor users are far more susceptible to compromise than indicated by prior work. [...] Our analysis shows that 80% of all types of users may be de- anonymized by a relatively moderate Tor-relay adversary within six months. Our results also show that against a single AS adversary roughly 100% of users in some common locations are deanonymized within three months (95% in three months for a single IXP). Fur- ther, we find that an adversary controlling two ASes instead of one reduces the median time to the first client de-anonymization by an order of magnitude: from over three months to only 1 day for a typical web user; and from over three months to roughly one month for a BitTorrent user. This clearly shows the dramatic effect an adversary that controls multiple ASes can have on security. Disclaimer: one of the authors (Micah Sherr) is a doctoral brother. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sun, 08 Sep 2013 20:34:55 -0400 Kent Borg kentb...@borg.org wrote: On 09/08/2013 06:16 PM, John Kelsey wrote: I don't think you can do anything useful in crypto without some good source of random bits. I don't see the big worry about how hard it is to generate random numbers unless: Lenstra, Heninger and others have both shown mass breaks of keys based on random number generator flaws in the field. Random number generators have been the source of a huge number of breaks over time. Perhaps you don't see the big worry, but real world experience says it is something everyone else should worry about anyway. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Does NSA break in to endpoints (was Re: Bruce Schneier has gotten seriously spooked)
On Sat, 07 Sep 2013 09:33:28 +0100 Brian Gladman b...@gladman.plus.com wrote: On 07/09/2013 01:48, Chris Palmer wrote: 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. Because NSA and GCHQ are much more interested in attacking communictions in transit rather than attacking endpoints. Except, one implication of recent revelations is that stealing keys from endpoints has been a major activity of NSA in the last decade. I'm not going to claim that altering patches and software during download has been a major attack vector they've used for that -- I have no evidence for the contention whatsoever and besides, endpoints seem to be fairly vulnerable without such games -- but clearly attacking selected endpoints is now an NSA passtime. Perry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: Volume, top posting, trimming, SUBJECT LINES
1) Volume has gotten understandably high the last few days given the current news. I'd like people to please consider if their posting conveys interesting information before sending. 2) Please adjust the Subject lines of your messages if your posting deviates from the original Subject. This makes it much easier for people to determine what they want to skip. 3) Again, please don't top post. Again, please trim the message you are replying to. Perry ___ 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 Sat, 07 Sep 2013 13:01:53 -0700 Ray Dillinger b...@sonic.net wrote: I think we can no longer rule out the possibility that some attacker somewhere (it's easy to point a finger at the NSA but it could be just as likely pointed at GCHQ or the IDF or Interpol) may have secretly developed a functional quantum computer with a qbus wide enough to handle key sizes in actual use. In the same sense that we can no longer rule out the possibility that, given modern synthetic biology techniques, someone has already come up with a way to create pigs with wings. I see the possibility of the quantum computer as slightly smaller, however. And IIRC, pretty much every asymmetric ciphersuite (including all public- key crypto) is vulnerable to some transformation of Shor's algorithm that is in fact practical to implement on such a machine. To my knowledge, there is no ECC analog of Shor's algorithm. Perry ___ 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 Sat, 7 Sep 2013 13:06:14 -0700 Tony Arcieri basc...@gmail.com wrote: In order to beat quantum computers, we need to use public key systems with no (known) quantum attacks, such as lattice-based (NTRU) or code-based (McEliece/McBits) algorithms. ECC and RSA will no longer be useful. I'm unaware of an ECC equivalent of the Shor algorithm. Could you enlighten me on that? Perry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Replacing CAs (was Re: Why prefer symmetric crypto over public key crypto?)
On Sat, 7 Sep 2013 17:46:39 -0400 Derrell Piper d...@electric-loft.org wrote: On Sep 6, 2013, at 11:51 PM, Marcus D. Leech mle...@ripnet.com wrote: 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. Well, there are other saddles, as it were. SPKI/SDSI both offer a path forward without needing a trusted CA... I think that in general one doesn't need CAs much. I will point out, again, a message I sent to the list recently in which I propose that simple demonstration of long term use and association may be sufficient for ordinary purposes: http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html ___ 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 Sat, 7 Sep 2013 20:43:39 -0400 I wrote: To my knowledge, there is no ECC analog of Shor's algorithm. ...and it appears I was completely wrong on that. See, for example: http://arxiv.org/abs/quantph/0301141 Senility gets the best of us. Perry ___ 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] 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
[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] 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 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
[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
[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
[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
[Cryptography] ADMIN: Please, please, please don't top post.
I hate to ask this yet again, but: Please, please, please don't top post. Please, please, please edit down your replies. If your mobile device, say, doesn't let you do otherwise, it can probably wait half an hour until you get to a machine with a keyboard. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013 19:14:53 -0400 John Kelsey crypto@gmail.com wrote: First, I don't think it has anything to do with Dual EC DRGB. Who uses it? It did *seem* to match the particular part of the story about a subverted standard that was complained about by Microsoft researchers. I would not claim that it is the most important part of the story. My impression is that most of the encryption that fits what's in the article is TLS/SSL. Yes, and if they have a real hole there they're exploiting, that is quite disturbing. If they're merely using a hodge-podge of techniques to get keys, it is less worrying. Where do the world's crypto random numbers come from? My guess is some version of the Windows crypto api and /dev/random or /dev/urandom account for most of them. I'm starting to think that I'd probably rather type in the results of a few dozen die rolls every month in to my critical servers and let AES or something similar in counter mode do the rest. A d20 has a bit more than 4 bits of entropy. I can get 256 bits with 64 die rolls, or, if I have eight dice, 16 rolls of the group. If I mistype when entering the info, no harm is caused. The generator can be easily tested for correct behavior if it is simply a block cipher. What does most of the world's TLS? OpenSSL and a few other libraries, is my guess. But someone must have good data about this. My broader question is, how the hell did a sysadmin in Hawaii get hold of something that had to be super secret? He must have been stealing files from some very high ranking people. I believe there was already discussion in the press on that latter point, but I think it is less germane to our discussion here and would prefer that we avoid speculating on things that are only of human/gossip interest. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Opening Discussion: Speculation on BULLRUN
I would like to open the floor to *informed speculation* about BULLRUN. Informed speculation means intelligent, technical ideas about what has been done. It does not mean wild conspiracy theories and the like. I will be instructing the moderators (yes, I have help these days) to ruthlessly prune inappropriate material. At the same time, I will repeat that reasonably informed technical speculation is appropriate, as is any solid information available. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013 16:53:15 -0400 Perry E. Metzger pe...@piermont.com wrote: Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” “Eventually, N.S.A. became the sole editor,” the memo says. Anyone recognize the standard? Please say it aloud. (I personally don't recognize the standard offhand, but my memory is poor that way.) There is now some speculation in places like twitter that this refers to Dual_EC_DRBG though I was not aware that was widely enough deployed to make a huge difference here, and am not sure which international group is being mentioned. I would be interested in confirmation. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] The Guardian: US and UK spy agencies defeat privacy and security on the internet
Quoting: US and British intelligence agencies have successfully cracked much of the online encryption relied upon by hundreds of millions of people to protect the privacy of their personal data, online transactions and emails, according to top-secret documents revealed by former contractor Edward Snowden. The files show that the National Security Agency and its UK counterpart GCHQ have broadly compromised the guarantees that internet companies have given consumers to reassure them that their communications, online banking and medical records would be indecipherable to criminals or governments http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 05 Sep 2013 13:33:48 -0700 Eric Murray er...@lne.com wrote: The NYT article is pretty informative: (http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html) [...] Also interesting: Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology, the United States’ encryption standards body, and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” “Eventually, N.S.A. became the sole editor,” the memo says. Anyone recognize the standard? Please say it aloud. (I personally don't recognize the standard offhand, but my memory is poor that way.) BTW, I will now openly speculate if the deeply undeployable key management protocols for IPSec that originated at the NSA were an accident. I had enough involvement not to feel overly strongly that this is what happened, but it does lead one to wonder strongly. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 5 Sep 2013 15:58:04 -0400 Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Here are a few guesses from me: 1) I would not be surprised if it turned out that some people working for some vendors have made code and hardware changes at the NSA's behest without the knowledge of their managers or their firm. If I were running such a program, paying off a couple of key people here and there would seem only rational, doubly so if the disclosure of their involvement could be made into a crime by giving them a clearance or some such. 2) I would not be surprised if some of the slow speed at which improved/fixed hashes, algorithms, protocols, etc. have been adopted might be because of pressure or people who had been paid off. At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. Whether I am correct or not, such behavior clearly serves the interest of those who would do bad things. 3) I would not be surprised if random number generator problems in a variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not. 4) Choices not to use things like Diffie-Hellman in TLS connections on the basis that it damages user experience and the like should be viewed with enormous suspicion. 5) Choices not to make add-ons available in things like chat clients or mail programs that could be used for cryptography should be viewed with suspicion. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Bruce Schneier in The Guardian on BULLRUN etc.
Quite worth reading. There is some speculation in there about various weaknesses that may have been added as well. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] NY Times: NSA Foils Much Internet Encryption
Quoting: The National Security Agency is winning its long-running secret war on encryption, using supercomputers, technical trickery, court orders and behind-the-scenes persuasion to undermine the major tools protecting the privacy of everyday communications in the Internet age, according to newly disclosed documents. The agency has circumvented or cracked much of the encryption, or digital scrambling, that guards global commerce and banking systems, protects sensitive data like trade secrets and medical records, and automatically secures the e-mails, Web searches, Internet chats and phone calls of Americans and others around the world, the documents show. http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, 05 Sep 2013 16:43:59 -0400 Bernie Cosell ber...@fantasyfarm.com wrote: On 5 Sep 2013 at 16:11, Phillip Hallam-Baker wrote: I would bet that there is more than enough DES traffic to be worth attack and probably quite a bit on IDEA as well. There is probably even some 40 and 64 bit crypto in use. Indeed -- would you (or any of us) guess that NSA could break TDES these days? The articles make it sound much more like implementation flaws that have been intentionally placed in software and hardware, and a select few bad protocols and standards. I'm not going to say that it is impossible that they can break 3DES at this point, but it doesn't sound like that's what is being discussed here. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Is ECC suspicious?
In this posting: http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Bruce Schneier casts some doubt on the use of ECC 5) Try to use public-domain encryption that has to be compatible with other implementations. For example, it's harder for the NSA to backdoor TLS than BitLocker, because any vendor's TLS has to be compatible with every other vendor's TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it's far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. 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. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] tamper-evident crypto? (was: BULLRUN)
On Thu, 05 Sep 2013 16:56:38 -0700 John Denker j...@av8n.com wrote: The generator can be easily tested for correct behavior if it is simply a block cipher. I wouldn't have said that. As Dykstra was fond of saying: Testing can show the presence of bugs; testing can never show the absence of bugs. The point is that a deterministic generator operating off of a seed can be validated -- you can assure yourself reasonably easily that the thing is indeed AES in counter mode. A hardware generator can have horrible flaws that are hard to detect without a lot of data from many devices. (The recent break of the Taiwanese national ID card system should be a lesson on that too.) I will remind everyone that the key generation ceremony for the Clipper devices used a deterministic generator for precisely this reason even given that the keys were being escrowed. See Dorothy Denning's old report on that for a reminder. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: less Snowden, more Crypto
On Thu, 5 Sep 2013 20:30:40 -0400 Jerry Leichter leich...@lrw.com wrote: On Sep 5, 2013, at 7:14 PM, John Kelsey wrote: My broader question is, how the hell did a sysadmin in Hawaii get hold of something that had to be super secret? He must have been stealing files from some very high ranking people. This has bothered me from the beginning. Even the first leaks Admin hat on: As interesting as the overall speculation might be in a human interest sort of way, I'd prefer if we avoided it, unless it points to interesting lessons for making the world more secure going forward or to something similarly worthwhile. Yes, this is irresistible gossip for many of us, but I don't know that it is interesting beyond that, and our traffic levels are quite high right now already. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, 06 Sep 2013 12:13:48 +1200 Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Perry E. Metzger pe...@piermont.com writes: I would like to open the floor to *informed speculation* about BULLRUN. Not informed since I don't work for them, but a connect-the-dots: 1. ECDSA/ECDH (and DLP algorithms in general) are incredibly brittle unless you get everything absolutely perfectly right. I'm aware of the randomness issues for ECDSA, but what's the issue with ECDH that you're thinking of? 2. The NSA has been pushing awfully hard to get everyone to switch to ECDSA/ECDH. Yes, and 24 hours ago I would have said that was because they themselves depended on the use of commercial products with such algorithms available (as in Suite B.) Now I'm less sure. Wasn't Suite B promulgated in the 2005-2006 period? Yes, though it doesn't sound like Suite B is what the article meant when discussing standards. Peter (who choses RSA over ECC any time, follow a few basic rules and you're safe with RSA while ECC is vulnerable to all manner of attacks, including many yet to be discovered). Many people out there seem to claim the opposite of course. The current situation doesn't give us a definitive way to resolve such an argument. RSA certainly appears to require vastly longer keys for the same level of assurance as ECC. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Fri, 06 Sep 2013 13:50:54 +1200 Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Perry E. Metzger pe...@piermont.com writes: Does that make them NSA plants? There's drafts for one or two more fairly basic fixes to significant problems from other people that get stalled forever, while the draft for adding sound effects to the TLS key exchange gets fast-tracked. It's just what standards committees do. Maybe. Yesterday I would have consistently ascribed things to bureaucracy instead of malice. Today, I'm less sure. At the very least, the current revelations make such things less benevolent -- whether from malice or stupidity, we can no longer sit on security fixes on the basis that no one will exploit them and they're not important to the user. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Can you backdoor a symmetric cipher (was Re: Opening Discussion: Speculation on BULLRUN)
On Thu, 5 Sep 2013 23:24:54 -0400 Jerry Leichter leich...@lrw.com wrote: They want to buy COTS because it's much cheap, and COTS is based on standards. So they have two contradictory constraints: They want the stuff they buy secure, but they want to be able to break in to exactly the same stuff when anyone else buys it. The time-honored way to do that is to embed some secret in the design of the system. NSA, knowing the secret, can break in; no one else can. There have been claims in this direction since NSA changed the S-boxes in DES. For DES, we now know that was to protect against differential cryptanalysis. No one's ever shown a really convincing case of such an embedded secret hack being done ... but now if you claim it can't happen, 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 Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Hashes into Ciphers (was Re: FIPS, NIST and ITAR questions)
As a pure aside... On Tue, 3 Sep 2013 15:16:14 -0400 Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Wed, 4 Sep 2013 09:14:36 +0200 Lucky Green shamr...@cypherpunks.to wrote: I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. I think this conversation has, at this point, gone well beyond the scope of the list. There are a bunch of google people on the mailing list, perhaps one or more of them might want to contact Lucky in private and see if they can help him with his question. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
On Wed, 4 Sep 2013 10:37:12 -0400 Perry E. Metzger pe...@piermont.com wrote: Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. Answering my own question https://groups.google.com/forum/#!original/sci.crypt/tTWR2qIII0s/iDvT3ptY5CEJ Note that Karn's construction need not use any particular hash function -- he's more or less simply describing how to use a hash function of any sort as the heart of a Feistel cipher. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote: At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. I don't understand why. The security requirement is that third parties must *not* be able to predict the token, because then they could sign the token without controlling the email address. The only organization that can know the cookie is actually the organization sending the cookie out. You appear to have inverted the security requirement... Then, each user can just broadcast his signature of the previously unpredictable consensual data, and various timestamping organizations can sign messages that say yes, I saw that at this time, maybe charging some tiny usage fee in the process. But then *anyone* could broadcast the token because anyone could have predicted it. It is difficult to make the interchange of the token and the reply itself widely witnessed -- the way around that is to have many organizations doing the interchanges so that one would have to suborn all of them. After a deadline, the organization publishes the definitive merkle tree digest of who was seen on time, together with the common salt. That is part of the envisioned model. Currently I'm looking at how to take advantage of the work already done on Certificate Transparency. Perry -- 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 Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com wrote: - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. That is a misunderstanding. If you look at the way that the NSA specs these things, they try to keep all portions of a system of equal security so none is the weak point. A 2048 bit RSA key is factored vastly more easily than a 256 bit AES key is brute forced (that's just public knowledge -- try doing the back of the envelope yourself) so that size key would be insufficient. However, a sufficiently large RSA key to be correctly sized for 256 bit AES is totally impractical for performance reasons, see: http://www.nsa.gov/business/programs/elliptic_curve.shtml So clearly the purpose of pushing ECC for this application is that they want the public key algorithm and its key size to have comparable security while both performing reasonably well. (Same for DH and DSA.) It looks as if they are betting that factoring and discrete logs over the integers aren't as hard as people had thought. Not at all, and the rationale is public and seen above. I believe you're incorrectly claiming that we know much less than we actually do here. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Mon, 2 Sep 2013 19:53:03 +0200 Faré fah...@gmail.com wrote: On Mon, Sep 2, 2013 at 7:19 PM, Perry E. Metzger pe...@piermont.com wrote: On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote: At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. I don't understand why. The security requirement is that third parties must *not* be able to predict the token, because then they could sign the token without controlling the email address. The only organization that can know the cookie is actually the organization sending the cookie out. You appear to have inverted the security requirement... In my scheme, no one can predict it, everyone can postdict it, *after* the trusted organization published its salt, at which point it's too late to send it signed confirmations. Therefore, neither side can cheat. I don't see what threat this averts. If the sending organization is cheating, this does not stop them from pretending that they received a signed cookie in a round trip. It just seems to add complexity. The only interesting form of cheating I can think of is pretending a round trip existed when it did not. In particular, the trusted organization has precious little power to extract information by handing users carefully crafted cookies. I don't see how that is an issue either, unless you are referring to chosen plaintext attacks, but the encryption format had better already defend against those. For even less power, the organization can publish digests of its salts years in advance. Again, I don't understand the threat being defended against. Can you articulate exactly what was possible before that is not possible in the scheme you propose? Perry -- 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 Mon, 2 Sep 2013 15:09:31 -0400 Jerry Leichter leich...@lrw.com wrote: On Sep 2, 2013, at 1:25 PM, Perry E. Metzger wrote: On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com wrote: - To let's look at what they want for TOP SECRET. First off, RSA - accepted for a transition period for SECRET, and then only with 2048 bit moduli, which until the last year or so were almost unknown in commercial settings - is completely out for TOP SECRET. So clearly they're faith in RSA is gone. That is a misunderstanding. If you look at the way that the NSA specs these things, they try to keep all portions of a system of equal security so none is the weak point. A 2048 bit RSA key is factored vastly more easily than a 256 bit AES key is brute forced (that's just public knowledge -- try doing the back of the envelope yourself) so that size key would be insufficient. However, a sufficiently large RSA key to be correctly sized for 256 bit AES is totally impractical for performance reasons, see: http://www.nsa.gov/business/programs/elliptic_curve.shtml a) The very reference you give says that to be equivalent to 128 bits symmetric, you'd need a 3072 bit RSA key - but they require a 2048 bit key. Only as a legacy you can do this for a while but please switch. And the same reference says that to be equivalent to 256 bits symmetric, you need a 521 bit ECC key - and yet they recommend 384 bits. So, no, even by that page, they are not recommending equivalent key sizes - and in fact the page says just that. I'd say they're judging a balance between security and performance while attempting not to leave particularly bad holes. b) Those comparisons long ago became essentially meaningless. On the symmetric size, it's using brute force attack strengths. But no one is going to brute force a 128-bit key with any known or suggested technology, and brute force attacks against 256-bit keys are way beyond what physics says is even remotely possible. I believe that is indeed a factor here, and is probably part of why the asymmetric key lengths aren't a bit longer. It is also possible they've been selected based on knowledge that AES keys are slightly weaker than we expect, but not radically so. As an aside, I'm reminded of the fact that there were certificational weaknesses in Skipjack that meant it was only more or less as potentially secure as the number of bits available in they key length. When this was pointed out to someone in the know, the mumble back I remember was in other words, they did the engineering correctly. Anyway, as I've said, I'm paranoid, but I operate under the assumption the counterparty is a reasonably rational actor that understands the very limited duration of secrets. Perry -- 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 Mon, 2 Sep 2013 14:45:00 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. But of course, sufficiently paranoid people might contend that perhaps the Microsoft people who complained might not have been briefed by the ones who cooperated. The problem with all such exercises is that they involve too many layers of recursive paranoia, but do not pay off with useful information that tells me how to act going forward. In the current case, the fact that they *could* potentially suborn process inside a vendor is an interesting thing to consider when doing design, and whether they *have* is less interesting to me. Clearly, as things like bad vendor drivers updates have been sent out using stolen keys in the past, and clearly vendors might simply make mistakes in the future. From there, I can consider whether the someone at vendor signs bad updates security model component is productive to defend against or not, and how one might defend against it. (In the current case, I'd say only typed assembly language offers an interesting defense against bad binaries that get executed in kernel mode, regardless of why they are bad. Using typed assembly language effectively of course requires that the code be written in a high level language with strong typing to be preserved in the delivered machine code in the first place.) I leave speculation to pundits, and prefer to write code and design protocols. Perry -- 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 Mon, 2 Sep 2013 13:14:00 -0700 Christian Huitema huit...@huitema.net wrote: Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. But of course, sufficiently paranoid people might contend that perhaps the Microsoft people who complained might not have been briefed by the ones who cooperated. I would be very surprised if they had gotten any assistance from Microsoft. As would I. Not my wider point. My wider point is that the speculation is not helpful, and one probably wants to think about how to make things trustworthy even in the presence of bugs, adversaries who look like bugs for most viewpoints, etc. Paranoid speculation is useless, concrete discussion of threat models and how to address them is useful. (Thus why I mentioned things like typed assembly language as being a more productive topic than infinitely recursive paranoia. One can speculate endlessly on who is collaborating with whom without ever terminating, but robust threat models with technical solutions are something you can actually do something about.) Perry -- 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 Mon, 2 Sep 2013 17:44:57 -0400 Jerry Leichter leich...@lrw.com wrote: ...Clearly, as things like bad vendor drivers updates have been sent out using stolen keys in the past, and clearly vendors might simply make mistakes in the future Except that that's not what happened in this case. Someone took an old, valid Microsoft license - which should never Yes, certainly, but the end effect was that an untrustworthy piece of code was then executing on the victim's machine. That can be happen by many means, however, both intentional and accidental -- trojan horses, vendor mistakes, bugs, rogue employees at a vendor, a vendor's credentials being stolen, cryptographic breaks like this, etc. Now, I do indeed find it interesting and exotic that someone involved knows how to create MD5 collisions by a different method than we know of in the open literature, and that tickles my fancy as a person who loves cryptography, and probably tells us something about who wrote that particular exploit. What it does not do, however, is tell me much about how to make systems robust against the wide variety of reasons why untrustworthy software might appear on a machine. As a security person, it is this latter problem that is vital to me, since doubtless that will show up again in the future. Even ignoring malice, bugs often happen in device drivers and other code running in security critical environments like kernels. I will again mumble things like: typed assembly language, proof carrying code, microkernels, hardware assists, formal verification... in the hopes that the mumbling might set some minds thinking. Perry -- 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 Sat, 31 Aug 2013 17:00:01 -0400 John Kelsey crypto@gmail.com wrote: 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. This seems by far the most probable conclusion. Note, for example, Heninger et al's recent work on the Taiwanese national smartcards. A discovery that some commonly used randomness sources are dramatically less random than supposed could dramatically lower the work factor on an otherwise brute force attack. That said, we simply can't know, and I think excessive speculation on the basis of no actual concrete information isn't that productive. Perry -- 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 Sun, 1 Sep 2013 07:11:06 -0400 Jerry Leichter leich...@lrw.com wrote: Meanwhile, just what evidence do we really have that AES is secure? The fact that the USG likes using it, too. That's also evidence for eliptic curve techniques btw. Perry -- 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 Sun, 1 Sep 2013 16:33:56 -0400 Jerry Leichter leich...@lrw.com wrote: On Sep 1, 2013, at 2:11 PM, Perry E. Metzger wrote: On Sun, 1 Sep 2013 07:11:06 -0400 Jerry Leichter leich...@lrw.com wrote: Meanwhile, just what evidence do we really have that AES is secure? The fact that the USG likes using it, too. We know they *say in public* that it's acceptable. But do we know what they *actually use*? We know what they spec for use by the rest of the US government in Suite B. http://www.nsa.gov/ia/programs/suiteb_cryptography/ AES with 128-bit keys provides adequate protection for classified information up to the SECRET level. Similarly, ECDH and ECDSA using the 256-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-256 provide adequate protection for classified information up to the SECRET level. Until the conclusion of the transition period defined in CNSSP-15, DH, DSA and RSA can be used with a 2048-bit modulus to protect classified information up to the SECRET level. AES with 256-bit keys, Elliptic Curve Public Key Cryptography using the 384-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-384 are required to protect classified information at the TOP SECRET level. Since some products approved to protect classified information up to the TOP SECRET level will only contain algorithms with these parameters, algorithm interoperability between various products can only be guaranteed by having these parameters as options. We clearly cannot be absolutely sure of what they actually use, but we know what they procure commercially. If you feel this is all a big disinformation campaign, please feel free to give evidence for that. I certainly won't exclude the possibility, but I find it unlikely. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Keeping backups (was Re: Separating concerns
On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote: One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. Inevitably this means that said backups are going to either be protected by a fairly weak password or that the user is going to have to print the key out and put it in their desk drawer and risk having it lost or stolen or destroyed in a fire. I think I can live with either problem. Right now, most people have very little protection at all. I think making the perfect the enemy of the good is a mistake. If doing bad things to me requires breaking in to my individual home, that's fine. If it is merely much less likely that I lose my data rather than certain that I have no backup at all, that's fine. BTW, automation *does* do a good job of making such things invisible. I haven't lost any real data since I started using Time Machine from Apple, and I have non-technical friends who use it and are totally happy with the results. I wish there was an automated thing in Time Machine to let me trade backups with an offsite friend as well. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
On Thu, 29 Aug 2013 01:18:59 +1000 (EST) Dave Horsfall d...@horsfall.org wrote: On Wed, 28 Aug 2013, Perry E. Metzger wrote: Anyway, I've already started implementing my proposed solution to that part of the problem. There is still a need for a distributed database to handle the lookup load, though, and one that is not the DNS. (Delurking) This suggests the use of LDAP. I can think of no circumstances where I would voluntarily use LDAP as the solution to any problem of any sort. In any case, you will note that LDAP does not actually solve the problem statement as I gave it: that is to say, users must be able to join the system without the permission or assistance of systems administrators. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Wed, 28 Aug 2013 10:43:24 -0400 Jerry Leichter leich...@lrw.com wrote: On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote: On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com wrote: It's not as if this isn't a design we have that we know works: DNS. Read what I said: There's a *design* that works. I never suggested *using DNS* - either its current physical instantiation, or even necessarily the raw code. In fact, I pointed out some of the very problems you mention. What defines the DNS model - and is in contrast to the DHT model - is: - Two basic classes of participants, those that track potentially large amounts of data and respond to queries and those that simply cache for local use; - Caching of responses for authoritative-holder-limited amounts of time to avoid re-querying; - A hierarchical namespace and a corresponding hierarchy of caches. DNS and DNSSEC as implemented assume a single hierarchy, and they map the hierarchy to authority. These features are undesirable and should be avoided. I'm unsure how to use a DNS-like model when there is no real linkage between hierarchy in the names used and the storage location of particular mappings. In particular, if I have names like f...@example.com, and I want just anyone to be able to enroll at any time without administrator input, and I don't want state authorities to be able to shut down or alter the contents of the system, I don't see how to accomplish all my goals with something DNS-like. That said, if you have a concrete proposal, I would of course find it interesting to hear about. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] The Case for Formal Verification
to proving the right thousand lines of code here and there without much fuss, and that might make an incredible difference in systems security if people actually take it seriously. So, if you're interested, how do you get started doing such things? At the moment, the best system for doing this sort of work is Coq: http://coq.inria.fr/ Coq is sort of a programming language (although it is not quite Turing equivalent -- all programs must be guaranteed to terminate for technical reasons), sort of a form of constructivist logic (i.e. all existence proofs construct examples, no law of the excluded middle). It uses a neat trick called the Curry-Howard isomorphism that may take some getting used to for people not exposed to modern type theory. In it, types and logical propositions are the same thing, and programs and proofs are the same thing. You can write a function that adds two numbers, or a function that proves that there are an infinite number of primes. The type of the former is clearly an integer, but the type of the latter is the theorem itself. A proof that proposition A implies proposition B is function of type A - B -- any function that takes a proof of A and yields a proof of B is after all a proof that if A is true then B is true. (This is why all functions in Coq itself must terminate -- otherwise all types would be inhabited so all theorems would be true. That in no way restricts one's ability to build verified non-terminating programs using the system, you just have to build them by reasoning about programs that Coq itself can't execute.) Proofs in Coq are generally not written by hand, though. Instead one uses a sublanguage called the tactic language in which one invokes help from Coq to interactively assemble a proof, which makes doing the proof far easier. For many theorems, you can almost completely automate the proof, while for others, you need to help Coq along more. (Some of the tactics are quite amazing, Omega for example will prove any assertion about numbers that does not involve multiplication by a variable, aka Presburger arithmetic.) Often, one builds software using Coq by constructing a sort of formally verified assertion about what the program would do, and then using a built in Coq facility to mechanically extract that into a working verified program written in OCaml, Haskell or Scheme. Nothing in theory prevents you from doing things many in other ways, though -- the system is quite general. Coq is, sadly, needlessly hard for the beginner. It has poor documentation, bad error messages and bad error behavior. These are not inherent problems, they're problems just with this instance of things -- people could build better if there was enough interest, and I hope that as these technologies become more popular people will build far better versions of the tools. However, bad documentation or no, at the moment, this is the right place to go I think. It is the system Quark and CompCert were built in, and not by accident. It is not for the faint of heart -- the learning curve is very steep. Still, it is quite doable. The right places to start with Coq are probably Benjamin Pierce's online Software Foundations textbook: http://www.cis.upenn.edu/~bcpierce/sf/ and, when one is done with that, possibly Adam Chlipala's online book Certified Programming with Dependent Types http://adam.chlipala.net/cpdt/ (There's also a manual for the system itself, as well as this book on Coq: https://www.springer.com/computer/swe/book/978-3-540-20854-9 ) I'm happy to give help to anyone trying to learn how to do this sort of thing -- we need more people in the world experimenting with verification if we're going to get truly trustworthy software going forward. Let me assert that we *do* need truly trustworthy software, too. We've been very, very good for years now at finding hole after hole in running code and making the systems we depend on every day into a minefield that we dare not take an unconsidered step in. Wouldn't it be nice to make some progress in the other direction? Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com wrote: It's not as if this isn't a design we have that we know works: DNS. As I said elsewhere: as a practical matter, almost no one using email is a DNS administrator. This therefore cannot possibly deploy in finite time for the average user. If your mailbox is in a domain name controlled by someone else, you may wait effectively forever for permission. Indeed, DNSSEC itself has waited forever as a result of that. Furthermore, this is unacceptable because the trust model is unacceptable. If you are a user of gmail, for example, it implies that Google is in the trust loop for telling the world security critical information, like, for example, your key. Sovereign threats can order Google to insert different keys at will. As I've said elsewhere: the DNS is a very architecturally tempting idea for all of this. I fully understand why people would want to do it that way. It is not, however, practical if one wants to deploy in months and not decades, and it makes trust entirely hierarchical. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] human readable IDs, revokable keys (Re: Email and IM are ideal candidates for mix networks)
First of all, I think systems that make people associate arbitrary long strings with someone's email address aren't really acceptable. I'll repeat that my model is give someone your email address on a napkin in a bar. I do things like this often enough right now. On Wed, 28 Aug 2013 06:41:27 -0400 Jerry Leichter leich...@lrw.com wrote: On the underlying matter of changing my public key: *Why* would I have to change it? Because people make mistakes and reveal security critical information to the world at intervals. Because computers are sometimes compromised. A system that does not permit you to recover from rare events is not going to deploy very well. I think that to begin with, though, a system that requires people to somehow associate arbitrary strings with their friends won't work either. Anyway, I proposed a system to handle id to key mappings with reasonable trust in the first of my three messages on my proposed new model -- it also happens to handle revocation reasonably well (though imperfectly). Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography