Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
It bugs me that so many of the input words are mostly zero. Using the TLS Sequence Number for the nonce is certainly going to be mostly zero bits. And the block counter is almost all zero bits, as you note, (In the case of the TLS, limits on the plaintext size mean that the first counter word will never overflow in practice.) Heck, since the average IP packet length is 43, the average TLS record is likely shorter than that! At least half the connection directions, it's going to be rare that the counter itself exceeds 1! In my PPP ChaCha variant of this that I started several months ago, the nonce input words were replaced with my usual CBCS formulation. That is, invert the lower 32-bits of the sequence number, xor with the upper 32-bits, add (mod 2**64) both with a 64-bit secret IV, count the bits, and variably rotate. This gives more diffusion, at least 2 bits change for every packet, ensure a bit changes in the first 32-bits (highly predictable and vulnerable), and varies the bits affected among 64 positions. Note that I use a secret IV, a cipher key, and an ICV key for CBCS. However, to adapt your current formulation for making your ICV key, ChaCha20 is run with the given key and nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The remainder of the output is discarded. I suggest: ChaCha20 is run with the given key and sequence number nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The next 8 bytes of the output are saved to become the per-record input nonce for this ChaCha20 TLS record. Or you could use 16 bytes, and cover all the input fields There's no reason the counter part has to start at 1. Of course, this depends on not having a related-key attack, as mentioned in my previous message. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Evaluating draft-agl-tls-chacha20poly1305
On 9/10/13 2:42 PM, Ben Laurie wrote: On 10 September 2013 18:00, zooko mailto:zo...@zooko.com>> wrote: Please ask your friendly neighborhood TLS implementor to move fast on http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt . We prefer https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/. Hooray! Let's get behind this! It does things a bit differently than I'd choose, but fits the discussion we had a few months ago (on the companion list) about the next algorithm to choose, and seems to fit the TLS paradigm. I applaud moving the ICV outside the encryption. Phil Karn and I were advocates of this (for denial-of-service protection) going back long before there were known theoretical attacks on inner protection. ChaCha20 is run with the given key and nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The remainder of the output is discarded. Why generate the ICV key this way, instead of using a longer key blob from TLS and dividing it? Is there a related-key attack? Authenticated decryption is largely the reverse of the encryption process: the Poly1305 key is generated and the authentication tag calculated. The calculated tag is compared against the final 16 bytes of the authenticated ciphertext in constant time. If they match, the remaining ciphertext is decrypted to produce the plaintext. If AEAD, aren't the ICV and cipher text generated in parallel? So how do you check the ICV first, then decipher? Needs a bit more implementation details. I assume there's an implementation in the works. (Always helps define things with something concrete.) ___ 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 11/09/13 01:36 AM, Jerry Leichter wrote: (Generating a different one for this purpose is pointless - it would have to be random, in which case you might as well generate the IV randomly.) In a protocol I wrote with Zooko's help, we generate a random IV0 which is shared in the key exchange. http://www.webfunds.org/guide/sdp/sdp1.html Then, we also move the padding from the end to the beginning, fill it with a non-repeating length-determined value, and expand it to a size of 16-31 bytes. This creates what is in effect an IV1 or second transmitted IV. http://www.webfunds.org/guide/sdp/pad.html iang ___ 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 Sep 10, 2013, at 7:27 PM, Nemo wrote: >> E_0 = IV # Not transmitted >> E_{i+1} = E(E_i XOR P_{i+1}) > > Not sure what "not transmitted" means here. In typical CBC > implementations, the IV is certainly transmitted... Sure. The intent was just that the ciphertext starts with E1. IV has to be known to both sides, but it's part of the setup, not the ciphertext. >> to >> >> E_0 = E(IV) # Not transmitted >> E_{i+1} = E(E_i XOR P_{i+1}) > > As written, this does nothing to deny plaintext/ciphertext pairs further > along in the stream. Typical encrypted streams have lots of > mostly-predictable data (think headers), not just the first 16 bytes. That's certainly true. On the other hand, there's no mode I know of that denies the attacker access to (guessed or known or even chosen, if the attacker has a way to influence the data sent) plaintext/ciphertext pairs = which is exactly why no one would even begin to consider a cipher these days unless it was convincingly secure against chosen ciphertext attack. (Before roughly the 1950's, it was the working rule that plaintext transmitted via a cryptosystem was never released. Embassies receiving announcements via an enciphered channel would paraphrase them before making them public.) > I agree with Perry; a reference to a paper would be nice. I responded to Perry. >> the known attack (whose name escapes me - it was based on an attacker >> being able to insert a prefix to the next segment because he knows the >> IV it will use before it gets sent) > > I think you mean BEAST. No, something much simpler. Consider a situation in which there's an ongoing exchange of messages: Alice sends to Bob, Bob responds to Alice. Alice uses CBC and just continues the CBC sequence from one message to the next. In effect, this presents Eve with the initiation of a new CBC session, with a known IV. Between the end of one of Alice's messages to Bob and the next, Eve knows the next IV. Suppose Eve also knows a previously-transmitted plaintext block P2. Let P1 be the (unknown) plaintext block immediately preceding P2. P2 was transmitted as C2 = E(E(P1) XOR P2) If Eve re-inserts C2 as the first message of the response to Bob, Bob will decrypt it as IV XOR D(C2) == IV XOR E(P1) XOR P2. Thus Eve gets Bob to accept P2 modified by XOR'ing with a known quantity - which is not supposed to be possible in a secure mode. BTW, this reveals an interesting and little-mentioned assumption about CBC: That Eve can't insert a ciphertext block between two of Alice's in the time between two blocks. Probably not a good assumption on a packet network, actually. The older literature requires that the IV be "unpredictable" (an ill-defined term), but in fact if you want any kind of security proofs for CBC, it must actually be random. > Back to CBC mode and secret IVs. I do not think we will too find much > guidance from the academic side on this, because they tend to "assume a > can opener"... Er, I mean a "secure block cipher"... And given that > assumption, all of the usual modes are provably secure with cleartext > IVs. Incorrect on multiple levels. See the paper I mentioned in my response to Perry. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote: > On 6 September 2013 18:13, Perry E. Metzger wrote: > > > It would be good to see them abandon RC4 of course, and soon. > > > > In favour of what, exactly? We're out of good ciphersuites. Please ask your friendly neighborhood TLS implementor to move fast on http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt . Regards, Zooko ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [TLS] New Version Notification for draft-sheffer-tls-bcp-00.txt
On Sep 9, 2013, at 7:30 PM, Michael Ströder wrote: > > > Peter Gutmann wrote: > >> > Do you have numbers about the relative and absolute performance impact? >> > Personally I don't see performance problems but I can't prove my position >> > with >> > numbers. > > MBA-2:tmp synp$ openssl speed dsa1024 dsa2048 […] > signverifysign/s verify/s > dsa 1024 bits 0.000445s 0.000515s 2247.6 1941.8 > dsa 2048 bits 0.001416s 0.001733s706.4577.2 We are arguing about a key exchange that goes from ~1ms to ~3ms (where the cracking goes from "yes" to "no"). Yes, this is more but this is absolutely not a problem for PCs or even phones or tablets especially in the light of session keep alive and other techniques that allow a key exchange to last a while. Is the complaint that the server load is too high? Lastly, going a partial step seems strange also. Why do we what to put ourselves through this again so soon? The French government suggests 2048 now (for both RSA and DHE), and will only last 6 years. From http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf > La taille minimale du module est de 2048 bits, pour une utilisation ne devant > pas depasser lannee 2020. The minimum size of the modulus is 2048 bits for use not to exceed 2020. > Pour une utilisation au-dela de 2020, la taille minimale du module est de > 4096 bits For use beyond a 2020, the minimum module size is 4096 bits Pardon the bad cut/paste and google translate, but I believe you get the point. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 10/09/13 10:00, Guido Witmond wrote: Hi Peter, We really have different designs. I'll comment inline. On 09/09/13 19:12, Peter Fairbrother wrote: On 09/09/13 13:08, Guido Witmond wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, sorry, that should read "You don't give someone your address or telephone number". mea culpa. You can give them your name. you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. There is only one to remember, your own. If I read it correctly, each participant has one *single identity*? Yes - except of course you can have as many identities as you want. You create them yourself after all. The only assurance given by the scheme is that if a person gave you a hash which he generated himself, and you match it with a string and that string matches what you know about the person (eg their name or photo), then no-one else can have MTM'd it. (maybe the server returns two or three matches, as after a while there will be random birthday collisions. That's why you should check the string matches what you know about the person. But an attacker can't find a hash which matches a particular pre-chosen person by trying, it would take 2^100 work) You can have one for business, one for pretty girls, one for ugly girls - you just have to remember them all (except maybe the one for ugly girls). Or you can write them down. Or put them on your business card. The point is that for practical purposes the hash *is* your telephone number, and/or your email, and/or your facebook page - we just need to get everyone else to install the software to do the lookup, checking, translation etc automagically and behind the scenes in their telephones, browsers, email clients etc. (this was originally designed only for use in a single semi-secure comms program suite - but I don't see why it couldn't be more widely used) [...] As you and I have never met, I can't validate your photo, neither half your claimed penis size. ;-) How do I know it's not a Man in the Middle using your picture? See above. It would take on average 2^79 operations each of which would require 2^20 work to find a matching hash, starting with a picture. Or even just starting with a name, or whatever. -- Peter Fairbrother ___ 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
> Date: Tue, 10 Sep 2013 13:42:57 +0200 > From: Adam Back > To: "Perry E. Metzger" > Cc: Alexander Klimov , Cryptography List > , Adam Back > Subject: Re: [Cryptography] how could ECC params be subverted & other > ... > 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. I've talked a bit with someone I know with some background in the math here, who didn't see an obvious way for these curves to have been cooked. I don't have the number theory to have an opinion, but if someone can point me to an explanation of how they might have been cooked, I would very much appreciate it. I imagine any such potential backdoor will be very easy to get my management to take seriously right now. And that three months ago, we would not have been at all worried. I forsee a rather large change in institutional culture at NIST. > (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). It sure looks now like Dual EC DRBG was backdoored from the leaks and news stories, though I don't know of any hard proof. But we (NIST) have put SP 800-90 back up for public comment and have issued a bulletin telling people to stop using it until we figure out what to do about it. (The alternatives are to remove it or to fix it.) This DRBG was in the X9.82 document when I joined NIST and came onto the project in 2003. If you go to our website (csrc.nist.gov) you can see old slides and documents, and you can check the wayback machine to verify we haven't changed them. (We also had a public workshop, and participants may still have old copies of the documents.) This shows the development of the standard over time. I think the P and Q were the same in those old documents. If so, this tells you how far back this effort goes--at least to 2003, perhaps further back. I believe the X9.82 effort had been going on several years before that, though not making much progress--I'm not sure how long ago Dual EC DRBG was put in. I paid very little attention to the number theoretic constructions (two originally, one in the final version) because I didn't and don't think I know enough number theory to evaluate them. When we heard about the issue of selection of points (in an X9 meeting, I think in 2006 or early 2007), we discussed the issue, and it didn't seem like a serious threat. I sure didn't think the people I was working with on the document were trying to slip weak stuff in. Instead, it looked like they had generated some parameters randomly and hadn't worried about proving where the parameters came from. This seemed like a really weird place to put a backdoor, because it was insanely slow, and it seemed unlikely to get any significant use. 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. (Accidental screw-ups, sure, but not intentional engineered vulnerabilities.) At the time, the solution we came to--allow the use of the default points (which some people had allegedly baked into implementations in anticipation of the standard) and also allow generation of your own points, seemed adequate. But that was assuming a different world than we live in, apparently. If NSA had a program of intentionally inserting weaknesses in crypto standards, and inserted at least one into a NIST standard, then any potential backdoor parameters we have are scary as hell. No way can we leave them in a standard people are expecting to use. Having such a program burns a hell of a lot of bridges, too. I still don't *know* if this is true--convincing newspaper stories often get stuff wrong, and convincing leaked documents may not be authentic. But it sure looks like the way to bet, now. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Time for djb's Edwards curves in TLS?
Is there a TLS WG draft adding djb's Curve1174 to the list of named curves supported by TLS? If there's credible doubt about the safety of the NIST curves, it seems that Curve1174 (in Edwards form) would make a good choice for EECDH, perhaps coupled with a similar curve with ~512 bits. Slides with rationale: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Detailed paper motivating Curve1174: http://cr.yp.to/elligator/elligator-20130527.pdf The current situation with EECDH over the NIST prime curves not shown compromised, but no longer trusted is rather sub-optimal. -- Viktor. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On 2013-09-10, at 17:35, Ben Laurie wrote: > On 10 September 2013 22:04, Joe Abley wrote: > >> Suppose Mallory has access to the private keys of CAs which are in "the" >> browser list or otherwise widely-trusted. >> >> An on-path attack between Alice and Bob would allow Mallory to terminate >> Alice's TLS connection, presenting an opportunistically-generated >> server-side certificate with signatures that allow it to be trusted by Alice >> without pop-ups and warnings. Instantiating a corresponding session with Bob >> and ALGing the plaintext through with interception is then straightforward. > > CT makes this impossible to do undetected, of course. I don't feel qualified to endorse "impossible", but for the armchair crypto spectator it does sound very much like the right thing. Joe ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On 08/09/2013 21:51, Perry E. Metzger wrote: > On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter > wrote: >> Even for one-to-one discussions, these days, people want >> transparent movement across their hardware. If I'm in a chat >> session on my laptop and leave the house, I'd like to be able to >> continue on my phone. How do I hand off the conversation - and the >> keys? > > I wrote about this a couple of weeks ago, see: > > http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html Which is pretty spot-on and one of my biggest gripes about OTR. It just doesn't mesh at all with user's expectations. > In summary, it would appear that the most viable solution is to make > the end-to-end encryption endpoint a piece of hardware the user owns > (say the oft mentioned $50 Raspberry Pi class machine on their home > net) and let the user interact with it over an encrypted connection > (say running a normal protocol like Jabber client to server > protocol over TLS, or IMAP over TLS, or https: and a web client.) Sounds like another Freedom Box... Anyway, if we consider each device an end-point to a group-chat that has to be verified at least once by another end-point (and that is a somewhat doable thing, e.g. the socialist millionaire's problem), what about having end-points being able to vouch for other end-points? For example if I introduce my smartphone to an already existing instant messaging chat, I can vouch for it through my PC and if other end-points already trust my PC, there is no reason not to trust my smartphone either. If this is a dumb idea, feel free to point it out. Regards, Walter ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 09/10/13 19:08, Peter Fairbrother wrote: > The only assurance given by the scheme is that if a person gave you > a hash which he generated himself, and you match it with a string and > that string matches what you know about the person (eg their name or > photo), then no-one else can have MTM'd it. So what you have is a scheme that allows people who meet *in real life* to exchange keys. Why can't they just exchange an email address and shared password? Or the fingerprint of a GPG-key, it's shorter and must match the email address. Or hand out business cards with your public key in a qr-code. If you meet in person, you've already eliminated all MitM attacks. My scheme does the opposite. It allows *total strangers* to exchange keys securely over the internet. The scheme uses a common interest website where people write signed messages. The site is the *introducer* of the strangers. The technical design with DNSSEC and a Certificate Transparency service detect MitM attacks by a hostile site. (it can't prevent it). *One* secure message is enough to create new channels. Once you have exchanged the key with a stranger, you can create other secure channels. Either direct messaging, chat, voice and video. You name it. So far, the channels are only between two people. But once introduced via a web site, people will exchange other peoples identities between friends, relatives, coworkers. Creating a web of connections, all encrypted with the TLS version du jour. The beauty: the names are readable, human friendly, easy to give out and verify. The protocol does all the certificate validation. Each web site that adopts this scheme works as an introducer. There is no central point to attack. So if the feds would block one site, you don't lose your already validated keys. You won't even lose the connections to other people if you have already established an independent message channel with most of them. Regards, Guido Witmond. signature.asc Description: OpenPGP digital signature ___ 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 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] Fw: how could ECC params be subverted & other evidence
On Tue, 10 Sep 2013 16:45:23 -0400 John Kelsey 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] how could ECC params be subverted & other evidence
On Sep 10, 2013, at 5:45 PM, Perry E. Metzger 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 Also keep in mind that we're not seeing the full documents exfiltrated by Snowden. Snowden may have marked some material as "not for public release" when he gave it to the papers; the papers themselves go over it; and the papers have told us that they also talk to the government and sometimes are asked not to release certain material - though they may ignore the request. I would also assume that the newspapers have gotten some technically competent people involved to advise them as well. It's possible that the original documents hinted at other places that the the NSA mounted such attacks. This is getting very close to "means and methods", and the government may have requested that none of this be released. But the newspapers could well have pushed back and decided that the fact of such attacks is too important to suppress completely, so they compromised by only mentioning an attack with little practical import. -- Jerry PS After the harassment of David Miranda in the UK, Glenn Greenwald responded that in retaliation he would now release even more material than he had previously planned. And, in fact, there's been some recent trend for the material leaked to be more specific. I have my doubts that personal pique should have a role in the journalistic process, but Greenwald is only human. We're in an unprecedented situation - though one much discussed in many spy thriller and science fiction books in the past - where a small group of individuals has (apparently well protected) access to information that can do really serious damage to a large organization. One wonders if the intelligence community has quite come to grips with what a dangerous position they have found themselves in. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Thoughts on hardware randomness sources
I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Similarly, any hardware with an ADC input can be used as a hardware random noise source, simply by cranking up the gain to suitable levels where the low-order bit is sampling thermal noise. I currently play in the Software Defined Radio space, and there are these very-cheap SDR "dongles" that could easily be used as a hardware random noise source. I think it would be hard for NSA to hack *all* hardware that includes an ADC and some gain in front of it, since there's a dizzying array of it available, cheaply, for PC hardware. A related issue is getting sites to *use* enhanced random sources, even when "easy and cheap". -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 10 September 2013 18:00, zooko wrote: > On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote: > > On 6 September 2013 18:13, Perry E. Metzger wrote: > > > > > It would be good to see them abandon RC4 of course, and soon. > > > > > > > In favour of what, exactly? We're out of good ciphersuites. > > Please ask your friendly neighborhood TLS implementor to move fast on > http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt . > We prefer https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The One True Cipher Suite
On Tue, Sep 10, 2013 at 7:42 AM, Jerry Leichter wrote: > On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote: > > Steve Bellovin has made the same argument and I agree with it. > Proliferation of cipher suites is not helpful. > > > > The point I make is that adding a strong cipher does not make you more > secure. Only removing the option of using weak ciphers makes you more > secure. > I'm not so sure I agree. You have to consider the monoculture problem, > combined with the threat you are defending against. > I really hate the monoculture argument. It misses the fact that evolution of Internet applications and attack strategies is not according to Darwinian evolution. Diversity is only a successful strategy against Darwinian evolution. It does not work against intelligent design and malware is a product of intelligent design. Whether it is better to put all your eggs in one basket or in many baskets depends on the consequences of compromise. If the loss of one egg is acceptable then many baskets is the way to go. If on the other hand they are dragon eggs and the loss of just one is a catastrophe then putting them all in one basket is the lowest risk strategy. 1. If everyone uses the same cipher, the attacker need only attack that > one cipher. > 2. If there are thousands of ciphers in use, the attacker needs to attack > some large fraction of them. > But on the flip side the cost of developing ciphers is large and the vulnerabilities introduced into a protocol through support for algorithm negotiation are significant. Moreover as Newt Gingrich discovered, it only takes one party to your conversation to be using an old AMPS analog line for your conspiracy to be revealed. I would rather choose one algorithm and one additional strong algorithm as a backup than have the hundreds of algorithms. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59:37AM -0400, Marcus D. Leech wrote: > I wonder what people's opinions are on things like the randomsound > daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) B. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The One True Cipher Suite
At 04:42 AM 9/10/2013, Jerry Leichter wrote: On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote: > Steve Bellovin has made the same argument and I agree with it. Proliferation of cipher suites is not helpful. > The point I make is that adding a strong cipher does not make you more secure. Only removing the option of using weak ciphers makes you more secure. The reason you need to be able to support more than one cipher suite is so that you've got a mechanism for removing one if it's discovered to be weak in the future, and for adding a new one if none of your remaining suites are still strong. 1. If everyone uses the same cipher, the attacker need only attack that one cipher. 2. If there are thousands of ciphers in use, the attacker needs to attack some large fraction of them. If there are thousands of ciphers in use, it's generally easier for the attacker to get people to use one of the weak ones than to attack a large fraction of the not-currently-known-to-be-weak ones. The big problem PGP ran into with compatibility wasn't so much because of cipher suites (after Bass-O-Matic was replaced), though avoiding the IDEA patent became important after violating the RSA patent wasn't a problem, but because it did too much bit-twiddling to use variable-length fields and was sloppy about boundaries, which made it easy to exploit. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On 09/10/2013 12:04 PM, Rob Kendrick wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) I haven't actually looked at the code. Conceptually, anything with an ADC can produce thermal and or 1/f noise in the lowest-order bits. Even if it's somewhat biased (like having 60Hz hum embedded in it), with a suitable whitening function, it should produce high-quality entropy at rates of at least several hundred bits/second. The idea is to have *diversity* of physical random sources, to make it difficult for "bad actors" to subvert said hardware. It's fairly easy to "audit" these sources of random bits, since said bits won't have had any processing done to them in support of their random properties (unlike the Intel HW RNG). But this is just one aspect of a much-larger problem of "trusting trust" (in the Thompson sense). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On 10 Sep 2013, at 17:07, Walter van Holst wrote: > On 08/09/2013 21:51, Perry E. Metzger wrote: >> On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter >> wrote: >>> Even for one-to-one discussions, these days, people want >>> transparent movement across their hardware. If I'm in a chat >>> session on my laptop and leave the house, I'd like to be able to >>> continue on my phone. How do I hand off the conversation - and the >>> keys? >> >> I wrote about this a couple of weeks ago, see: >> >> http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html > > Which is pretty spot-on and one of my biggest gripes about OTR. It just > doesn't mesh at all with user's expectations. > >> In summary, it would appear that the most viable solution is to make >> the end-to-end encryption endpoint a piece of hardware the user owns >> (say the oft mentioned $50 Raspberry Pi class machine on their home >> net) and let the user interact with it over an encrypted connection >> (say running a normal protocol like Jabber client to server >> protocol over TLS, or IMAP over TLS, or https: and a web client.) > > Sounds like another Freedom Box... > > Anyway, if we consider each device an end-point to a group-chat that has > to be verified at least once by another end-point (and that is a > somewhat doable thing, e.g. the socialist millionaire's problem), what > about having end-points being able to vouch for other end-points? It's not a dumb idea at all but getting the 'introduction' mechanism right is tricky. I've implemented something similar where we 'trust' the first endpoint and then allow that well verified device to be bound to other entities. The mechanism I built was that each one gets its own identity and can be peer'ed into a conversation and that the group can in fact decide if it wants to allow the arrival of 'Walter on his Tablet' or 'Walter on his phone' depending on your level of paranoia or that of the group. I don't mind Walter on his PC at work but I don't like sending these messages to Walter on his phone especially when I know he has a habit of leaving his phone on the bus. > > For example if I introduce my smartphone to an already existing instant > messaging chat, I can vouch for it through my PC and if other end-points > already trust my PC, there is no reason not to trust my smartphone either. I've implemented the primary notion around a phone because it's a simple identity, it doesn't change much and it has multiple an out-of-band delivery channels which lends itself to multiple authentication factors. > > If this is a dumb idea, feel free to point it out. It allows other possibilities too, for instance, you can nominate the in-use end point and temporarily suspend others or even kick them out by refusing to complete an MPC protocol with them, exchange new keys and carry on the discussion. The idea of multiple sub-idenities lends itself well to keys which have different lifecycles. So chat for example, where a transient set of keys which, if lost isn't a massive problem but email for instance where loosing them and having stacks of encrypted email in your inbox which is now useless is unhelpful. I'm literally just in the process of building the master entity as a smart card component which can be used to 'introduce' the first device on an NFC capable android platform. From there you can bootstrap the other devices. What I don't know the answer to yet is if material changes need to be notionally signed by the master entity or if introductions can be done by devices as peers. Of course, compromise one device and it winds up with peer introducing rights. There is a usability trade off and I suspect until I've actually tried using it the answer is non obvious. Regards, Max > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Seed values for NIST curves
On Tue, Sep 10, 2013 at 3:36 AM, Joachim Strömbergson < joac...@strombergson.com> wrote: > 1. We as a community create a list of curves that we agree on are good. > The list is placed in a document, for example an RFC that clearly states > what criteria has been used, what the sources for the curves are and how > they has been generated. This allows any user to check the validity and > the provenance. This is more or less what djb did, sans the politics of an Internet standards process (others have written IETF-style guidelines for actually deploying his ciphers) djb's rationale for Curve25519's parameters are provided in the paper. The 2^255-19 constant was selected by a theorem (see Theorem 2.1): http://cr.yp.to/ecdh/curve25519-20060209.pdf -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] soft chewy center
much of the discussion these past few weeks seems to be centered on channel and container protection, secure paths, encrypted file systems, etc. much effort has gone into ensureing opaque environments for data to flow. and while interesting and perhaps useful, not a whole lot of effort seems to targeting the integrity of the data itself. wrapping the soft chewy middle with a hard candy shell can and does hide the fact that your core/data may be rotten. some years back, i was part of a debate on the relative value of crypto - and it was pointed out that for some sectors, crypto ensured _failure_ simply because processing the bits introduced latency. for these sectors, speed was paramount. think HFT or any sort of "Flash Mob" event where you want in/out as quickly as possible. crypto in and of itself is not a generator of value. Sprinkeling Security/Crypto pixie dust on -everything- can not be a good idea. Just my 0.02 lira. Jari and Stephen, please don't take the IETF there - its a wasteland. /bill ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] soft chewy center
On Tue, 10 Sep 2013 21:58:28 + bmann...@vacation.karoshi.com wrote: > some years back, i was part of a debate on the relative value of > crypto - and it was pointed out that for some sectors, crypto > ensured _failure_ simply because processing the bits introduced > latency. for these sectors, speed was paramount. > > think HFT or any sort of "Flash Mob" event where you want in/out as > quickly as possible. The latency cost of a stream cipher implemented in hardware can be as little as the time it takes a single XOR gate to operate -- which is to say, low even by the standards of my friends who do high frequency trading (many of whom do, in fact, claim to encrypt most of their communications). Certainly crypto is not the only (or even most important) way to make systems secure. In breaking in to a system, implementation bugs are where you look, not cracking cipher keys. However, latency qua latency seems like a poor reason to avoid encrypting your traffic. It might, of course, be a reason to avoid certain architectural decisions in how you use the crypto -- a public key operation per packet would clearly add unacceptable latency in many applications. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of "cooperative" end-points, PFS doesn't help)
(I apologize this message is not correctly threaded. I only subscribed to the list recently, and I have found no way to cannot construct a proper In-reply-to header from messages in the archive.) Peter Fairbrother wrote: > And most of their interception is passive, they just listen - you > generally need at least one plaintext/ciphertext pair to break a > cipher and find a session key, and most often they don't have the > plaintext, just the ciphertext. I agree with everything you have said, except for this. "GET / HTTP/1.1\r\n" is exactly 16 bytes, or one AES block. If the IV is sent in the clear -- which it is -- that is one plaintext-ciphertext pair right there for every HTTPS connection. In fact, _any_ aligned 16 bytes of plaintext in the conversation that are known, or that are in a guessable range, represent a plaintext/ciphertext pair if either of the following are true: 1) You sent the IV in the clear 2) You used CBC mode Of the modes I know (CBC, CTR, GCM, et. al.), the only one that does not freely give up such plaintext/ciphertext pairs is OCB. Of course, we assume our block ciphers are secure against even astronomical numbers plaintext/ciphertext pairs, because any evidence to the contrary would represent a publication-worthy if not Ph.D.-worthy result. But is it really such a good assumption against _this_ adversary? It seems to me that the IV could easily be negotiated at the same time as the session key. 2048-bit or 3072-bit RSA or DH already provide enough bits, so you can have a secret IV, independent of the session key, "for free". ECDH provides enough negotiated bits, too, once you are in the 256+ bit range. So, "avoid CBC" plus "negotiate the IV" seems like a simple way to stir extra entropy into the encryption. It does nothing for any security proofs, since those assume perfectly secure block ciphers... But it might make somebody's job just a little bit harder in practice. And since it would cost nothing, why not? - Nemo ___ 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 wrote: > On 2013-09-09, at 12:04, "Salz, Rich" wrote: > > > then maybe it's not such a "silly accusation" to think that > > root CAs are routinely distributed to multinational secret > > services to perform MITM session decryption on any form of > > communication that derives its security from the CA PKI. > > > > How would this work, in practice? > > Suppose Mallory has access to the private keys of CAs which are in > "the" browser list or otherwise widely-trusted. > > An on-path attack between Alice and Bob would allow Mallory to > terminate Alice's TLS connection, presenting an > opportunistically-generated server-side certificate with signatures > that allow it to be trusted by Alice without pop-ups and warnings. Note that the apparent attacks against Petrobras, SWIFT and others disclosed a few days ago appear to have used precisely this attack. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
On 10 September 2013 22:04, Joe Abley wrote: > Suppose Mallory has access to the private keys of CAs which are in "the" > browser list or otherwise widely-trusted. > > An on-path attack between Alice and Bob would allow Mallory to terminate > Alice's TLS connection, presenting an opportunistically-generated > server-side certificate with signatures that allow it to be trusted by > Alice without pop-ups and warnings. Instantiating a corresponding session > with Bob and ALGing the plaintext through with interception is then > straightforward. > CT makes this impossible to do undetected, of course. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59 AM, Marcus D. Leech wrote: > I wonder what people's opinions are on things like the randomsound daemon > that is available for Linux. I have not looked at that. A well thought out & well documented RNG based on a sound card is: http://www.av8n.com/turbid/paper/turbid.htm I wrote a very simple one (perhaps not yet trustworthy because it has not had much analysis) based on timer calls. Its documentation discusses a few others: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Random number generation influenced, HW RNG
On Sep 10, 2013, at 2:30 AM, ianG wrote: > The question of whether one could simulate a raw physical source is > tantalising. I see diverse opinions as to whether it is plausible, and > thinking about it, I'm on the fence. I don't think simulating a physical source is itself a big challenge. People simulate complicated probabilistic behavior all the time. The challenge is going to be sticking it into the chip in a way that doesn't show up when the chip is taken apart in a lab. How can we design the whole system so that some compromised or flawed pieces don't wreck us? I don't know how to ensure my chip's hardware RNG isn't hacked, but I have some hope of working out a design that will be robust even if it is hacked. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Squaring Zooko's triangle
On 10/09/13 05:38, James A. Donald wrote: On 2013-09-10 3:12 AM, Peter Fairbrother wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. 1. And they run away screaming. Sorry, I misspoke: you can of course give them your name, just not your telephone number or email address. You give them the hash instead of those. 2. It only takes 2^50 trials to come up with a valid fingerprint that agrees with your fingerprint except at four non chosen places. And that will help an attacker how? To use a hash to contact you Bob has to ask the semi-trusted server to find the hash and then return your matching input string - if he gets it wrong even in one place the server will return a different hash, or no hash at all. Bob can't use a hash which doesn't match exactly. Sound too restrictive? But Bob can't use a telephone number or email address which is wrong in one place, never mind four, either. I was even thinking of using a 60-bit hash fingerprint (with a whole lot of extra work added, to make finding a matching tailored preimage about 2^100 or so total work), so a hash would look like s-NN4H-JS7Y-OTRH but I haven't convinced myself that that would work yet. Mind you, I haven't ruled it out either. There is a flood attack, but it can be defeated by people paying a dollar to the server when they input a hash. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: Ending thread "The One True Cipher Suite"
I'm calling an end to the eggs, baskets, one cipher or a thousand discussion. I don't think more will provide additional insight for future protocol designers, and both major contributors have gotten several rounds in already. -- 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 Sep 10, 2013, at 12:43 PM, Nemo wrote: > "GET / HTTP/1.1\r\n" is exactly 16 bytes, or one AES block. If the IV is > sent in the clear -- which it is -- that is one plaintext-ciphertext > pair right there for every HTTPS connection. Phil Rogoway has a paper somewhere discussing the right way to implement cryptographic modes and API's. 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}) This eliminates known plaintext in the first block. If you use this definition for chained CBC - where you use the final block of a segment as the IV for the next segment - it also eliminates the known attack (whose name escapes me - it was based on an attacker being able to insert a prefix to the next segment because he knows the IV it will use before it gets sent) that even caused problems for CBC modes in either SSH or TLS. Beyond this, it changes the requirements on the IV as provided by the user from "random" to "never repeated for any given key" - an easier requirement that's much less likely to be accidentally violated. The cost of this is one extra block encryption at each end of the link, per CBC segment - pretty trivial. When I implemented a protocol that relied on CBC, I made this the exposed primitive. When I later learned of the prefix attack, I was gratified to see that my code was already immune. It actually amazes me that anyone uses the raw IV for the first XOR any more. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On Sep 9, 2013, at 9:10 PM, Tony Arcieri wrote: > On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie wrote: >> And the brief summary is: there's only one ciphersuite left that's good, and >> unfortunately its only available in TLS 1.2: >> >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > A lot of people don't like GCM either ;) Yes, GCM does have implementation sensitivities particularly around the IV generation. That being said, the algorithm is better than most and the implementation sensitivity obvious (don't ever reuse an IV).___ 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 Sep 10, 2013, at 5:49 PM, "Perry E. Metzger" 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...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. As I recall the proposal, it was the same key. (Generating a different one for this purpose is pointless - it would have to be random, in which case you might as well generate the IV randomly.) > 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... I searched around but couldn't find it; the proposal apparently was not Rogoway's. It apparently appears in NIST 800-38A (2001), with no citation. In searching around, I came across a recent, unpublished paper by Rogoway: http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf That paper - which does detailed analyses of a large number of modes - indicates that more recent work has shown that this technique for choosing an IV is *not* secure (against a certain class of attacks) and recommends against using it. I highly recommend that paper. In fact, I highly recommend everything Rogoway has written. We've been discussing authentication and session key exchange - he and Bellare wrote about the problem in 1993 http://cseweb.ucsd.edu/users/mihir/papers/eakd.pdf giving provably secure algorithms for the 2-party case, and two years later http://www.cs.ucdavis.edu/~rogaway/papers/3pkd.pdf extending the work to the 3-party case. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 10/09/13 14:03, Ben Laurie wrote: On 10 September 2013 03:59, james hughes mailto:hugh...@mac.com>> wrote: [...] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I retract my previous "+1" for this ciphersuite. This is hard coded 1024 DHE and 1024bit RSA. It is not hard coded to 1024 bit RSA. I have seen claims that some platforms hard code DHE to 1024 bits, but I have not investigated these claims. If true, something should probably be done. Yes - hard code them all to 1024-bit. Then dump TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 in the bin where it belongs. Then replace it with a suite such as TLS_DHE2048_WITH_RSA2048_WITH_AES_128_GCM_SHA256. Would a non-cryptographer know what TLS_DHE2048_WITH_RSA2048_WITH_AES_128_GCM_SHA256 meant? No. So for heaven's sake call it Ben's_suite or something, with a nice logo or icon, not TLS_DHE2048_WITH_RSA2048_WITH_AES_128_GCM_SHA256. They won't know what Ben's_suite means either, but they may trust you (or perhaps not, if you are still Working for Google ...) The problem with TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 is that you don't know what you are getting. [ The other problem is of course that the main browsers don't make it easy to find out which suite is actually in use ... :( ] Hmmm, can a certificate have several keylengths to choose from? And, if the suite allows it, can a certificate have an RSA key for authentication and a different RSA key for session key setup (cf RIPA)? -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] EFF press release on latest FISA opinions release
The documents haven't yet been completely processed, but they've already found some interesting features. Quoting: The NSA apparently believed that it had the authority to search the telephone records database in order to obtain the 'reasonable articulable suspicion' required to investigate those numbers. Essentially, they were conducting suspicionless searches to obtain the suspicion the FISA court required to conduct searches. https://www.eff.org/deeplinks/2013/09/government-releases-nsa-surveillance-docs-and-previously-secret-fisa-court Note that the USG has misleadingly claimed that this document release was part of an effort to be "transparent" -- in fact, these are the result of an EFF FOIA and were released at court order. -- 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 2013-09-09, at 12:04, "Salz, Rich" wrote: > ➢ then maybe it's not such a "silly accusation" to think that root CAs are > routinely distributed to multinational secret > ➢ services to perform MITM session decryption on any form of communication > that derives its security from the CA PKI. > > How would this work, in practice? Suppose Mallory has access to the private keys of CAs which are in "the" browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing the plaintext through with interception is then straightforward. This would be detectable by Bob by the visible client address, but that could be obfuscated (Mallory could exit the session through something tor-like, for example, to avoid advertising their topological location; this would just make it look like Alice is using tor). In the case where Alice is presenting a certificate specifically trusted by Bob, this wouldn't work so well. But my observation is that many TLS-protected streams used by consumers don't use client certificate authentication. As an aside, I see CAs with Chinese organisation names in my browser list. I don't know how to distinguish between enterprises and government from this side of the Pacific (so, presumably, assume they are all government). I had always assumed that this was already happening at the Great Firewall, as a working example of government-sponsored TLS interception with no requirement for expensive crunching of large integers. Joe ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sun, 8 Sep 2013 15:22:32 -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. 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
[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
[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 To: "Perry E. Metzger" Cc: Alexander Klimov , Cryptography List , Adam Back 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
Re: [Cryptography] The One True Cipher Suite
On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote: > Steve Bellovin has made the same argument and I agree with it. Proliferation > of cipher suites is not helpful. > > The point I make is that adding a strong cipher does not make you more > secure. Only removing the option of using weak ciphers makes you more secure. I'm not so sure I agree. You have to consider the monoculture problem, combined with the threat you are defending against. The large burst of discussion on this list was set off by Perry's request for ways to protect against the kinds of broad-scale, gather-everything attacks that Snowden has told us the NSA is doing. So consider things from the side of someone attempting to mount this kind of attack: 1. If everyone uses the same cipher, the attacker need only attack that one cipher. 2. If there are thousands of ciphers in use, the attacker needs to attack some large fraction of them. As a defender, if I go route 1, I'd better be really, really, really sure that my cipher won't fall to any attacks over its operational lifetime - which, if it's really universal, will extend many years *even beyond a point where a weakness is found*. On the other hand, even if most of the ciphers in my suite are only moderately strong, the chance of any particular one of them having been compromised is lower. This is an *ensemble* argument, not an *individual* argument. If I'm facing an attacker who is concentrating on my messages in particular, then I want the strongest cipher I can find. Another way of looking at this is that Many Ciphers trades higher partial failure probabilities for lower total/catastrophic failure probabilities. Two things are definitely true, however: 1. If you don't remove ciphers that are found to be bad, you will eventually pollute your ensemble to the point of uselessness. If you want to go the "many different ciphers" approach, you *must* have an effective way to do this. 2. There must be a large set of potentially good ciphers out there to choose from. I contend that we're actually in a position to create reasonably good block ciphers fairly easily. Look at the AES process. Of the 15 round 1 candidates, a full third made it to the final round - which means that no significant attacks against them were known. Some of the rejected ones failed due to minor "certificational" weaknesses - weaknesses that should certainly lead you not to want to choose them as "the One True Cipher", but which would in and of themselves not render breaking them trivial. And, frankly, for most purposes, any of the five finalists would have been fine - much of the final choice was made for performance reasons. (And, considering Dan Bernstein's work on timing attacks based on table lookups, the performance choices made bad assumptions about actual hardware!) I see no reason not to double-encrypt, using different keys and any two algorithms from the ensemble. Yes, meet-in-the-middle attacks mean this isn't nearly as strong as you might naively think, but it ups the resource demands on the attacker much more than on the defender. Now, you can argue that AES - the only cipher really in the running for the One True Symmetric Cipher position at the moment - is so strong that worrying about attacks on it is pointless - the weaknesses are elsewhere. I'm on the fence about that; it's hard to know. But if you're going to argue for One True Cipher, you must be explicit about this (inherently unprovable) assumption; without it your argument fails. The situation is much more worse for the asymmetric case: We only have a few alternatives available and there are many correlations among their potential weaknesses, so the Many Ciphers approach isn't currently practical, so there's really nothing to debate at this point. Finally, I'll point out that what we know publicly about NSA practices says that (a) they believe in multiple ciphers for different purposes; (b) they believe in the strength of AES, but only up to a certain point. At this point, I'd be very leery of taking anything NSA says or reveals about it practices at face value, but there it is. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sep 9, 2013, at 9:17 AM, Kent Borg wrote: >> Which brings into the light the question: Just *why* have so many random >> number generators proved to be so weak. > > Your three cases left off an important one: Not bothering to seed the PRNG at > all. I think the Java/Android cryptographic (!) library bug that just came > up was an instance of that. > > I think the root of the problem is that programs are written, and bugs > squashed, until the program works. Maybe throw some additional testing at it > if we are being thorough, but then business pressures and boredom says ship > it. > > That won't catch a PRNG that wasn't seeded, nor a hashed password that wasn't > salted, the unprotected URL, the SQL injection path, buffer overflow, etc. Good observations, but I think you're being too pessimistic. All the examples you give *could* be tested - but not by "ignorant black box testing" - testing that ignores not just what's inside the box, but the actual requirements on what the box is supposed to produce. A non-seeded PRNG, and even one seeded with a very small amount of entropy, will be caught by a test that runs multiple instances of the PRNG from the system starting state and ensures that the ensemble of first outputs (and, for good measure, the first *couple* of outputs) has the right statistics. Similarly, a test that inserts the same password into multiple instances of the same system in the same state can check that the hashed versions have the right statistics. No, these can't catch deliberate attack code which produces random-looking values that the attacker can predict - no test can. But it will catch a broad class of common errors. The others aren't cryptographic issues and require different approaches. The fact that there are bad testing practices - and that those bad practices are used all too often - doesn't mean there aren't good practices, and that they could not be applied. Where the testing is bad because of ignorance of what is actually important and how to test for it, learning from the failures of the past is the way forward - which was exactly the point of "PRMG failures" classification. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Squaring Zooko's triangle
On 2013-09-10 3:12 AM, Peter Fairbrother wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. 1. And they run away screaming. 2. It only takes 2^50 trials to come up with a valid fingerprint that agrees with your fingerprint except at four non chosen places. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Random number generation influenced, HW RNG
On 10/09/13 06:29 AM, John Kelsey wrote: But I am not sure how much it helps against tampered chips. If I can tamper with the noise source in hardware to make it predictable, it seems like I should also be able to make it simulate the expected behavior. I expect this is more complicated than, say, breaking the noise source and the internal testing mechanisms so that the RNG outputs a predictable output stream, but I am not sure it is all that much more complicated. How expensive is a lightweight stream cipher keyed off the time and the CPU serial number or some such thing to generate pseudorandom bits? How much more to go from that to a simulation of the expectdd behavior, perhaps based on the same circutry used in the unhacked version to test the noise source outputs? The question of whether one could simulate a raw physical source is tantalising. I see diverse opinions as to whether it is plausible, and thinking about it, I'm on the fence. I'd say it might be an unstudied problem -- for us. It's sounding like an interesting EE/CS project, masters or PhD level? If anyone has studied it, I'd bet fair money that the NSA has. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 10 September 2013 03:59, james hughes wrote: > > On Sep 9, 2013, at 2:49 PM, Stephen Farrell > wrote: > > On 09/09/2013 05:29 PM, Ben Laurie wrote: > > Perry asked me to summarise the status of TLS a while back ... luckily I > don't have to because someone else has: > > http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 > > In short, I agree with that draft. And the brief summary is: there's only > one ciphersuite left that's good, and unfortunately its only available in > TLS 1.2: > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > I retract my previous "+1" for this ciphersuite. This is hard coded 1024 > DHE and 1024bit RSA. > It is not hard coded to 1024 bit RSA. I have seen claims that some platforms hard code DHE to 1024 bits, but I have not investigated these claims. If true, something should probably be done. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
Hi Peter, We really have different designs. I'll comment inline. On 09/09/13 19:12, Peter Fairbrother wrote: > On 09/09/13 13:08, Guido Witmond wrote: > I like to look at it the other way round, retrieving the correct > name for a key. > > You don't give someone your name, you give them an 80-bit key > fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- > is common to all, it just says this is one of that sort of hash. > > There is only one to remember, your own. If I read it correctly, each participant has one *single identity*? Eccentric does it the other way around, with ecca, you have one or more different identities at *each* site. At least one. But if you want to blog different topics under different id's, no problem. Create another account. I think there are good reasons for having multiple *independent* identities. For example, if your writings get too hot for the blog site owner and they close one account, it doesn't affect the other accounts. If you want, you can destroy the private key so there is nothing that traces you to that account. Or if you want, you can post a proof of ownership of the private key of the account, to show that the site censured a really good post. They closed the account but can't invalidate your key. Again, other accounts are still unaffected. [Taken out technical description] > He then checks that you are someone he thinks you are, eg from the > photo, checks the fingerprint, and if he wants to contact you he has > already got your public key. As you and I have never met, I can't validate your photo, neither half your claimed penis size. ;-) How do I know it's not a Man in the Middle using your picture? Regards, Guido. signature.asc Description: OpenPGP digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie wrote: > And the brief summary is: there's only one ciphersuite left that's good, > and unfortunately its only available in TLS 1.2: > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > A lot of people don't like GCM either ;) So we're screwed! Well, aside from maybe this draft supporting Salsa20: http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02 -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
> > On Mon, Sep 09, 2013 at 06:41:23AM -0700, Andreas Davour wrote: >> >So there *is* a BTNS implementation, after all. Albeit >> >only for OpenBSD -- but this means FreeBSD is next, and >> >Linux to follow. >> >> I might add that as far as I know, this work has not been picked up >> yet by neither FreeBSD, nor Linux, so if you feel like giving the >> project a hand pushing it into the mainstream, I'm pretty sure mc >> would be very happy. I.e. I don't think anything is following on >> this work unless someone reading this helps making that happen. >> Personally I have neither the skills nor the contacts needed. > > To use btns, you need iked installed: > > from http://hack.org/mc/projects/btns/howto.html > > "Please note: The BTNS implementation is currently very experimental > and should be used with caution." > > Doesn't sound like this is production ready? It isn't. Thus my addition to Eugen's suggestion that other operating system implementations are to follow, and my suggestion that you might want to hack on the project. But, I wanted to let people engaged by the topic of btns know of an implementaion, since at least there is a start! /andreas -- "My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me." -- Edward Snowden's Father ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
Hi Hanno, Please send any comments on this draft to the TLS Working Group mailing list, t...@ietf.org. Thanks, Yaron On 09/10/2013 12:14 AM, Hanno Böck wrote: On Mon, 9 Sep 2013 17:29:24 +0100 Ben Laurie wrote: Perry asked me to summarise the status of TLS a while back ... luckily I don't have to because someone else has: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 In short, I agree with that draft. And the brief summary is: there's only one ciphersuite left that's good, and unfortunately its only available in TLS 1.2: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I don't really see from the document why the authors discourage ECDHE-suites and AES-256. Both should be okay and we end up with four suites: [...] ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 09/10/2013 02:01 PM, Ben Laurie wrote: >> Claiming that all the rest are no good also seems overblown, if >> that's what you meant. > > Other than minor variations on the above, all the other ciphersuites have > problems - known attacks, unreviewed ciphers, etc. There are issues, sure. And way too many ciphersuites certainly. > If you think there are other ciphersuites that can be recommended - > particularly ones that are available on versions of TLS other than 1.2, > then please do name them. Since they're talking about it now on the TLS wg list, I'll leave that them (and to folks who're qualified to figure if the NIST, brainpool etc curves are ok, which doesn't include me :-) What I was pointing out is that there's a bit of a gap between "no good" and "not what we'd recommend today." Since getting rid of deployment of old stuff takes years, I think its better that we don't overstate the issues that do exist. But I very much welcome Yaron's draft and hope it shoots along quickly. S. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ben Laurie writes: >We need to get an extension number allocated, since the one it uses clashes >with ALPN. It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 anywhere. (In any case -encrypt-then-MAC got there first, these Johnny-come-lately's can find their own ID to squat on :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG
On Sun, 2013-09-08 at 13:27 +0200, Eugen Leitl wrote: > - Forwarded message from "James A. Donald" - > On 2013-09-08 3:48 AM, David Johnston wrote: > > Claiming the NSA colluded with intel to backdoor RdRand is also to > > accuse me personally of having colluded with the NSA in producing a > > subverted design. I did not. > > 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. > > A decision that even assuming the utmost virtue on the part of the > designers, leaves open the possibility of malfunctions going > undetected. I may have missed this part of the thread, but I'm interested in knowing the rational for letting the hyper-visor intercept the RDRAND call and return any value it likes, bypassing the random hardware. I've had one person speculate it would be useful for keeping 2 CPUs in sync, (the TSC can also be intercepted), but it does worry me that RDRAND calls can be rendered predictable by a compromised VM. eric For those interested, Intel document 325462.pdf, "Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C" Page 'Vol. 3C 27-23', Table 27-12. Format of the VM-Exit Instruction-Information Field as Used for RDRAND ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Seed values for NIST curves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Tony Arcieri wrote: > The question is... suitable for what? djb argues it could be used to > find a particularly weak curve, depending on what your goals are: > http://i.imgur.com/o6Y19uL.png So, the question is then - how do we fix this? I (naively) see two approaches: 1. We as a community create a list of curves that we agree on are good. The list is placed in a document, for example an RFC that clearly states what criteria has been used, what the sources for the curves are and how they has been generated. This allows any user to check the validity and the provenance. 2. Create tools to easily create randomly generated curves including some tool to assess the goodness/quality. Either method should (I believe) be possisble to be integrated into TLS as part of the parameter exchange and negotiation. If I understand DJB correctly EC as such is sound and provides clear benefits compared to RSA. We just need curves that have completely open, traceable and varifiable specifications. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIu9iIACgkQZoPr8HT30QHziQCeLg8PgNPa2Iz0eB+ZJdgF6caB h1MAoJB/WTs+KrFsG3QjO84PipmyXlY0 =SdNy -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 9 September 2013 22:49, Stephen Farrell wrote: > > Hi Ben, > > On 09/09/2013 05:29 PM, Ben Laurie wrote: > > Perry asked me to summarise the status of TLS a while back ... luckily I > > don't have to because someone else has: > > > > http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 > > > > In short, I agree with that draft. And the brief summary is: there's only > > one ciphersuite left that's good, and unfortunately its only available in > > TLS 1.2: > > > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > I don't agree the draft says that at all. It recommends using > the above ciphersuite. (Which seems like a good recommendation > to me.) It does not say anything much, good or bad, about any > other ciphersuite. > > Claiming that all the rest are no good also seems overblown, if > that's what you meant. > Other than minor variations on the above, all the other ciphersuites have problems - known attacks, unreviewed ciphers, etc. If you think there are other ciphersuites that can be recommended - particularly ones that are available on versions of TLS other than 1.2, then please do name them. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
On 10 September 2013 11:29, Peter Gutmann wrote: > Ben Laurie writes: > > >We need to get an extension number allocated, since the one it uses > clashes > >with ALPN. > > It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 > anywhere. > > (In any case -encrypt-then-MAC got there first, these Johnny-come-lately's > can > find their own ID to squat on :-). > Feel free to argue the toss with IANA: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml . In the meantime, I suggest getting a new number would be more productive. Which, apparently, means first getting adopted by the TLS WG. Alternatively, allocate a random number. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography