Re: [Cryptography] Suite B after today's news
On 10 September 2013 11:29, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@links.org 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
Re: [Cryptography] Suite B after today's news
Ben Laurie b...@links.org 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] Suite B after today's news
On 09/05/2013 07:00 PM, Jon Callas wrote: I don't think they're actively bad, though. For the purpose they were created for -- parallelizable authenticatedencryption -- it serves its purpose. You can have a decent implementor implement them right in hardware and walk away. Given some of the things in the Snowden files, I think it has become the case that one ought not trust any mass-produced crypto hardware. It is clearly on the agenda of the NSA to weaken the communications infrastructure of American and other business, specifically at the level of chip manufacturers. And chips are too much of a black-box for anyone to easily inspect and too much subject to IP/Copyright issues for anyone who does to talk much about what they find. Seriously; microplaning, micrography, analysis, and then you get sued if you talk about what you find? It's a losing game. Given good open-source software, an FPGA implementation would provide greater assurance of security. An FPGA burn-in rig can be built by hand if necessary, or at the very least manufactured in a way that is subject to visual inspection (ie, on a one-layer circuit board with dead-simple 7400-series logic chips). It would be a bit of a throwback these days, but we're deep into whom-can-you- trust territory at this point and going for lower tech is worth it if it means tech that you can still inspect and verify. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Hi, BTW, I do not really agree with your argument it should be done via TLS extension. It's done that way based on discussions on (and mostly off) the TLS list by various implementers, that was the one that caused the least dissent. I've followed that list for a while. What I find weird is that there should be much dissent at all. This is about increasing security based on adding quite well-understood mechanisms. What's to be so opposed to there? Does adding some ciphersuites really require an extension, maybe even on the Standards Track? I shouldn't think so, looking at the RFCs that already do this, e.g. RFC 5289 for AES-GCM. Just go for an Informational. FWIW, even HTTPS is Informational. It really boils down to this: how fast do we want to have it? I spoke to one of the TACK devs a little while ago, and he told me they'd go for the IETF, too, but their focus was really on getting the code out and see an effect before that. The same seems to be true for CT - judging by their commit frequency in the past weeks, they have similar goals. I don't think it hurts to let users and operators vote with their feet here. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
On 09/08/2013 10:13 AM, Thor Lancelot Simon wrote: On Sat, Sep 07, 2013 at 07:19:09PM -0700, Ray Dillinger wrote: Given good open-source software, an FPGA implementation would provide greater assurance of security. How sure are you that an FPGA would actually be faster than you can already achieve in software? Thor Depends on the operation. If it's linear, somewhat certain. If it's parallizable or streamable, then very certain indeed. But that's not even the main point. It's the 'assurance of security' part that's important, not the speed. After you've burned something into an FPGA (by toggle board if necessary) you can trust that FPGA to run the same algorithm unmodified unless someone has swapped out the physical device. Given the insecurity of most net-attached operating systems, the same is simply not true of most software. Given the insecurity of chip fabs and their management, the same is not true of special-purpose ASICs. Ray ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ralph Holz ralph-cryptometz...@ralphholz.de writes: I've followed that list for a while. What I find weird is that there should be much dissent at all. This is about increasing security based on adding quite well-understood mechanisms. What's to be so opposed to there? There wasn't really much dissent (there was some discussion, both on and off- list, which I've tried to address in updates of the draft), it's just that the WG chairs don't seem to want to move on it. Does adding some ciphersuites really require an extension, maybe even on the Standards Track? I shouldn't think so, looking at the RFCs that already do this, e.g. RFC 5289 for AES-GCM. Just go for an Informational. FWIW, even HTTPS is Informational. I've heard from implementers at Large Organisations that having it non- standards-track makes it hard to get it adopted there. I guess I could go for Informational if all else fails. I don't think it hurts to let users and operators vote with their feet here. That's what's already happened/happening, problem is that without an RFC to nail down at least the extension ID it's a bit hard for commercial vendors to commit to it. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Hi, On 09/07/2013 12:50 AM, Peter Gutmann wrote: But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS 1.0. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of these, I just can't get any traction on it from the TLS WG chairs. Maybe Exactly, precious little movement on that front. Sadly. BTW, I do not really agree with your argument it should be done via TLS extension. I think faster progress could be made by simply introducing new allowed cipher suites and letting the servers advertise them and client accept them - this possibly means bypassing IETF entirely. Or, to keep them in, do it in TLS 1.3. But do it fast, before people start using TLS 1.2. I don't really see the explosion of cipher suite sets you give as a motivation - e.g. in SSH, where really no-one seems to use the standards, we have a total of 144 or so cipher suites found in our scans. Yet the thing works, because clients will just ignore the weird ones. It should be possible in SSL, too, unless openssl/gnutls/nss barfs at an unexpected suite name - but I don't think so. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Hi, Same here. AES is, as far as we know, pretty secure, so any problems are going to arise in how AES is used. AES-CBC wrapped in HMAC is about as solid as you can get. AES-GCM is a design or coding accident waiting to happen. But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS 1.0. RC4 was good enough for a while, but with djb's new work - it's just waiting to be improved and made practical by someone. FWIW, we still use RC4 on our servers, but I'd be happy to see something else that is practical. Of course, the above attacks are probably not one of your worries when you're up against the NSA - your own system is probably much more endangered. Ralph ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
I think that any of OCB, CCM, or EAX are preferable from a security standpoint, but none of them parallelize as well. If you want to do a lot of encrypted and authenticated high-speed link encryption, well, there is likely no other answer. It's GCM or nothing. OCB parallelizes very well in software and I see no reason it would not also do so in hardware; each block of both the plaintext and associated data can be processed independently of the others, and all of OCB's operations (xor, GF(2^128) doubling, Grey codes) seem like they would be well suited to a fast hardware implementation. And actually McGrew and Viega's original 2003 paper on GCM specifically mentions that OCB scales to high speeds in hardware, though they do not provide references to specific results. Jack ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ralph Holz ralph-cryptometz...@ralphholz.de writes: But for right now, what options do we have that are actually implemented somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.), and I don't see any move towards TLS 1.0. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of these, I just can't get any traction on it from the TLS WG chairs. Maybe they're following http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 6, 2013, at 11:41 AM, Jack Lloyd ll...@randombit.net wrote: I think that any of OCB, CCM, or EAX are preferable from a security standpoint, but none of them parallelize as well. If you want to do a lot of encrypted and authenticated high-speed link encryption, well, there is likely no other answer. It's GCM or nothing. OCB parallelizes very well in software and I see no reason it would not also do so in hardware; each block of both the plaintext and associated data can be processed independently of the others, and all of OCB's operations (xor, GF(2^128) doubling, Grey codes) seem like they would be well suited to a fast hardware implementation. And actually McGrew and Viega's original 2003 paper on GCM specifically mentions that OCB scales to high speeds in hardware, though they do not provide references to specific results. I confess that I might not explain very well a controversy that I lie on a different side of -- I'm using CCM, myself. My above explanation is what GCM proponents have told me -- that if you are doing multiple high-speed streams and have hardware you can throw at it, then it's what you want. There is/was an additional OCB issue specifically that there is/was IP around it. Univ. of California has recently relaxed them, but it's still needlessly complex. I confess I tend to think of OCB as a footnote -- the cool thing we can't use -- only. My decision tree is that I think in a perfect world, one would use OCB, but the IP nixes it. CCM was created specifically because it's not OCB, and EAX as an alternative to the alternative CCM. GCM is too easy to screw up and is slow in software (yes, there's galois multiply on Intel processors, but most of what I do is ARM). There's nothing wrong with EAX, but CCM is there and standardized in a number of places. Other people might end up with a different place for their own reasons. I don't think that any of them are bad, including the decision of using GCM and just making sure you do it right. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKm8XsTedWZOD3gYRAjUuAKC2sqp6C0wCrg+KydfhroBjYahqjwCgo+4d tLx/6e9TaWxRuknLWHEvF5w= =M7s8 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2013, at 6:16 PM, Dan McDonald dan...@kebe.com wrote: Consider the Suite B set of algorithms: AES-GCM AES-GMAC IEEE Elliptic Curves (256, 384, and 521-bit) Traditionally, people were pretty confident in these. How are people's confidence in them now? My opinion about GCM and GMAC has not changed. I've never been a fan. My objection to them is that they are tetchy to use -- hard to get right, easy to get wrong. It's pretty much what is in Niels's paper: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf I don't think they're actively bad, though. For the purpose they were created for -- parallelizable authenticated encryption -- it serves its purpose. You can have a decent implementor implement them right in hardware and walk away. I think that any of OCB, CCM, or EAX are preferable from a security standpoint, but none of them parallelize as well. If you want to do a lot of encrypted and authenticated high-speed link encryption, well, there is likely no other answer. It's GCM or nothing. Remember that every intelligence agency has a SIGINT branch and an IA (Information Assurance) branch. Sometimes they are different agencies (at least titularly) like GCHQ/CESG, BND/BSI, etc. The NSA does not separate its SIGINT directorate and the IA directorate into different agencies. I think the IA people have shown they do a good job, but they are humans too and make mistakes. Heck, there are things that various IA people do and recommend that I disagree with from weakly to strongly. I weakly disagree with GCM -- I think it's spinach and I say to hell with it, as opposed to thinking it's crap. Would a signals intelligence organization that finds a flaw in what the IA people did tell the IA branch so people can fix it? That's the *real* question. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKTc3sTedWZOD3gYRAhsoAKCP0xlsuWIE5CMDeBMwqQQ4hVIInwCg7LJX XHkmG7DzCxPubNay86/UL7U= =Eo6n -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 5, 2013, at 7:15 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Jon Callas j...@callas.org writes: My opinion about GCM and GMAC has not changed. I've never been a fan. Same here. AES is, as far as we know, pretty secure, so any problems are going to arise in how AES is used. AES-CBC wrapped in HMAC is about as solid as you can get. AES-GCM is a design or coding accident waiting to happen. This isn't the 1990s, we don't need to worry about whether DES or FEAL or IDEA or Blowfish really are secure or not, we can just take a known-good system off the shelf and use it. What we need to worry about now is deployability. AES- CTR and AES-GCM are RC4 all over again, it's as if we've learned nothing from the last time round. How do you feel (heh, I typoed that as feal) about the other AEAD modes? Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKTwesTedWZOD3gYRAgyXAJ0X7q9+1DRM+1p/eQ13Hlu0P4s4vQCgsQLG zs8/592lHqurlVWlghRTdJg= =Ni0l -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Jon Callas j...@callas.org writes: My opinion about GCM and GMAC has not changed. I've never been a fan. Same here. AES is, as far as we know, pretty secure, so any problems are going to arise in how AES is used. AES-CBC wrapped in HMAC is about as solid as you can get. AES-GCM is a design or coding accident waiting to happen. This isn't the 1990s, we don't need to worry about whether DES or FEAL or IDEA or Blowfish really are secure or not, we can just take a known-good system off the shelf and use it. What we need to worry about now is deployability. AES- CTR and AES-GCM are RC4 all over again, it's as if we've learned nothing from the last time round. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Jon Callas j...@callas.org writes: How do you feel (heh, I typoed that as feal) about the other AEAD modes? If it's not a stream cipher and doesn't fail catastrophically with IV reuse then it's probably as good as any other mode. Problem is that at the moment modes like AES-CTR are being promulgated as fashion statements without any consideration about operational deployment, when what we should be promoting is something that's safely and effectively deployable. Someblockcipher-CBC + HMAC is a nice safe bet, run your HMAC, do a constant-time compare of the result, toss the encrypted data if you get a verify failure, otherwise decrypt, it's pretty straightforward. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
