Re: [Cryptography] PGP Key Signing parties
If someone wants to try organise a pgp key signing party at the Vancouver IETF next month let me know and I can organise a room/time. That's tended not to happen since Ted and Jeff don't come along but we could re-start 'em if there's interest. S. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10 Oct 2013, at 17:06, John Kelsey crypto@gmail.com wrote: Just thinking out loud The administrative complexity of a cryptosystem is overwhelmingly in key management and identity management and all the rest of that stuff. So imagine that we have a widely-used inner-level protocol that can use strong crypto, but also requires no external key management. The purpose of the inner protocol is to provide a fallback layer of security, so that even an attack on the outer protocol (which is allowed to use more complicated key management) is unlikely to be able to cause an actual security problem. On the other hand, in case of a problem with the inner protocol, the outer protocol should also provide protection against everything. Without doing any key management or requiring some kind of reliable identity or memory of previous sessions, the best we can do in the inner protocol is an ephemeral Diffie-Hellman, so suppose we do this: a. Generate random a and send aG on curve P256 b. Generate random b and send bG on curve P256 c. Both sides derive the shared key abG, and then use SHAKE512(abG) to generate an AES key for messages in each direction. d. Each side keeps a sequence number to use as a nonce. Both sides use AES-CCM with their sequence number and their sending key, and keep track of the sequence number of the most recent message received from the other side. The point is, this is a protocol that happens *inside* the main security protocol. This happens inside TLS or whatever. An attack on TLS then leads to an attack on the whole application only if the TLS attack also lets you do man-in-the-middle attacks on the inner protocol, or if it exploits something about certificate/identity management done in the higher-level protocol. (Ideally, within the inner protcol, you do some checking of the identity using a password or shared secret or something, but that's application-level stuff the inner and outer protocols don't know about. Thoughts? Suggest it on the tls wg list as a feature of 1.3? S --John ___ 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] TLS2
On 29 Sep 2013, at 08:51, ianG i...@iang.org wrote: On 28/09/13 20:07 PM, Stephen Farrell wrote: b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well SSL/TLS is a history of fiddling around at the edges. If there is to be any hope, start again. Remember, we know so much more now. Call it TLS2 if you want. Start with a completely radical set of requirements. Then make it so. There are a dozen people here who could do it. Why not do the requirements, then ask for competing proposals? Choose 1. It worked for NIST, and committees didn't work for anyone. A competition for TLS2 would bring out the best and leave the bureaurats fuming and powerless. Sounds like a suggestion to make on the tls wg list. It might get some support, though I'd guess not everyone would want to do that S S iang ___ 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] Gilmore response to NSA mathematician's make rules for NSA appeal
On 09/27/2013 05:30 AM, james hughes wrote: The thing that this list can effect is the creation of standards with a valuable respect for Moore's law and increases of mathematical understanding. Stated differently, just enough security is the problem. This past attitude did not respect the very probably future that became a reality. I think there probably are some fair criticisms that we were a bit complacent after the clipper and export stuff seemed to be sorted out and the whole NIST/NSA thing with the AES and SHA-3 competitions seemed to be ticking over nicely. Are we going to continue this behavior? IMHO, based on what I have been seeing on the TLS list, probably. That's more than a bit silly though IMO. The sensible approach here is to a) see what's the best we can do now with deployed code given that we know it takes years to get anything near everything updated, but also b) figure out what do we want to do, knowing that it'll take years for deployment to happen no matter how small a change we make. a) is Yaron's BCP draft b) is TLS1.3 (hopefully) and maybe some extensions for earlier versions of TLS as well Arguing for (b) only, and that we ignore (a) would be dumb. For (a), we are entirely constrained in what we can do, basically, the only thing we can do is say how to better configure already deployed code. S. Jim ___ 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] RSA equivalent key length/strength
On 09/22/2013 01:07 AM, Patrick Pelletier wrote: 1024 bits is enough for anyone That's a mischaracterisation I think. Some folks (incl. me) have said that 1024 DHE is arguably better that no PFS and if current deployments mean we can't ubiquitously do better, then we should recommend that as an option, while at the same time recognising that 1024 is relatively short. S. ___ 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] What TLS ciphersuites are still OK?
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. S. ___ 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
