Re: [Cryptography] Points of compromise
Phillip Hallam-Baker wrote: > 5) Protocol vulnerability that IETF might have fixed but was discouraged > from fixing. By the way, it was a very interesting exercise to actually write out on graph paper the bytes that would be sent in a TLS exchange. I did this with Paul Wouters while working on how to embed raw keys in TLS (that would be authenticated from outside TLS, such as via DNSSEC). Or, print out a captured TLS packet exchange, and try to sketch around it what each bit/byte is for. The TLS RFCs, unlike most Jon Postel style RFCs, never show you the bytes -- they use a "high level description" with separate rules for encoding those descriptions on the wire. There is a LOT of known plaintext in every exchange! Known plaintext isn't the end of the world. But it makes a great crib for cryptanalysts who have some other angle to attack the system with. Systems with more known plaintext are easier to exploit than those with less. Is that why TLS has more known plaintext than average? Only the NSA knows for sure. John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Points of compromise
On Sep 8, 2013, at 1:53 PM, Phillip Hallam-Baker wrote: > I was asked to provide a list of potential points of compromise by a > concerned party. I list the following so far as possible/likely: It's not clear to me what kinds of compromises you're considering. You've produced a list of a number of possibilities, but not even mentioned whole classes of them - e.g., back doors in ECC. I've expanded, however, on one element of your list. > 2) Covert channel in Cryptographic accelerator hardware. > > It is possible that cryptographic accelerators have covert channels leaking > the private key through TLS (packet alignment, field ordering, timing, etc.) > or in key generation (kleptography of the RSA modulus a la Motti Young). There are two sides to a compromise in accelerator hardware: Grabbing the information, and exfiltrating it. The examples you give - and much discussion, because its fun to consider such stuff - look at clever ways to exfiltrate stolen information along with the data it refers to. However, to a patient attacker with large resources, a different approach is easier: Have the planted hardware gather up keys and exfiltrate them when it can. The attacker builds up a large database of possible keys - many millions, even billions, of keys - but still even an exhaustive search against that database is many orders of magnitude easier than an exhaustive search on an entire keyspace, and quite plausible - consider Venona. In addition, the database can be searched intelligently based on spatial/temporal/organizational "closeness" to the message being attacked. An attack of this sort means you need local memory in the device - pretty cheap these days, though of course it depends on the device - and some way of exfiltrating that data later. There are many ways one might do that, from the high tech (when asked to encrypt a message with a particular key, or bound to a particular target, instead encrypt - with some other key - and send - to some other target - the data to be exfiltrated) to low (pay someone with physical access to plug a USB stick into the device periodically). -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Points of compromise
I was asked to provide a list of potential points of compromise by a concerned party. I list the following so far as possible/likely: 1) Certificate Authorities Traditionally the major concern (perhaps to the point of distraction from other more serious ones). Main caveat, CA compromises leave permanent visible traces as recent experience shows and there are many eyes looking. Even if Google was compromised I can't believe Ben Laurie and Adam Langley are proposing CT in bad faith. 2) Covert channel in Cryptographic accelerator hardware. It is possible that cryptographic accelerators have covert channels leaking the private key through TLS (packet alignment, field ordering, timing, etc.) or in key generation (kleptography of the RSA modulus a la Motti Young). 3) Cryptanalytic attack on one or more symmetric algorithms. I can well believe that RC4 is bust and that there is enough RC4 activity going on to make cryptanalysis worth while. The idea that AES is compromised seems very less likely to me. 4) Protocol vulnerability introduced intentionally through IETF I find this rather unlikely to be a direct action since there are few places where the spec could be changed to advantage an attacker and only the editors would have the control necessary to introduce text and there are many eyes. 5) Protocol vulnerability that IETF might have fixed but was discouraged from fixing. Oh more times than I can count. And I would not discount the possibility that there would be strategies based exploiting on the natural suspicion surrounding security matters. It would have been easy for a faction to derail DNSSEC by feeding the WG chair's existing hostility to CAs telling him to stand firm. One concern here is that this will fuel the attempt to bring IETF under control of the ITU and Russia, China, etc. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
