Re: [cryptography] the spell is broken
Jon Callas j...@callas.org writes: In Silent Text, we went far more to the one true ciphersuite philosophy. I think that Iang's writings on that are brilliant. Absolutely. The one downside is that you then need to decide what the OTS is going to be. For example Mozilla (at least via Firefox) seems to think it involves Camellia (!!!?!!?). One True Suite works until that suite is no longer true, and then you're left hanging. One way to deal with this that got discussed some time ago over dinner (dining geeks, not cryptographers) is to swap at random among a small number of probably-OK suites and/or algorithms, a sort of probabilistic-security defence against the OTS having a problem. It's not like there's a shortage of them in... well, SSH, SSL/TLS, PGP, S/MIME, etc, anything really. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 04/10/13 08:52, Peter Gutmann wrote: Jon Callas j...@callas.org writes: In Silent Text, we went far more to the one true ciphersuite philosophy. I think that Iang's writings on that are brilliant. Absolutely. The one downside is that you then need to decide what the OTS is going to be. For example Mozilla (at least via Firefox) seems to think it involves Camellia (!!!?!!?). Surely that's precisely because they (and SSL/TLS generally) _don't_ have a One True Suite, they have a pick a suite, any suite approach? Weird/vanity/local ciphers are preferred in the sense that NSS assumes that if you put a cipher that no-one normal uses in your list of acceptable ciphers, you probably really wanted to use it. http://crypto.stackexchange.com/a/6548/5249 https://bug430875.bugzilla.mozilla.org/attachment.cgi?id=319703 So when servers and browsers that aren't required to use it by the Japanese government include it just because it's lying around and why not, it gets chosen over AES for no particular reason. But that's not the same as making it part of the One True Suite. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-talk] Guardian Tor article
Some have said... this [Snowden meta arena] has been a subject of discussion on the [various] lists as well Congrats, torproject :-D Tor Stinks means you're doing it right; good job Tor devs :) good news everybody; defense in depth is effective and practical! Yes, fine work all hands, everyone have a round at their favorite pub/equivalent tonight. Of course, this is also from 2007. It's been a long time since then. Yet whether from 2007 or last week... when Monday rolls around, we must channel all this joy and get back to work. For the risks and attackers that we all face are real, motivated, well funded, and do not play fair by any set of rules. They do not stop and neither can we. Wins that do not result in elimination from the game are but temporary gains. We must always be better... train, practice, discipline, and enter ourselves into every race... leaving only a continuous cloud of dust behind for our adversaries to choke on. Till Monday, I got this round :) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04, at 4:24 AM, Alan Braggins alan.bragg...@gmail.com wrote: Surely that's precisely because they (and SSL/TLS generally) _don't_ have a One True Suite, they have a pick a suite, any suite approach? And for those of us having to choose between preferring BEAST and RC4 for our webservers, it doesn’t look like we are really seeing the expected benefits of “negotiate a suite”. I’m not trying to use this to condemn the approach; it’s a single example. But it’s a BIG single example. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On Fri, Oct 4, 2013 at 4:58 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: On 2013-10-04, at 4:24 AM, Alan Braggins alan.bragg...@gmail.com wrote: Surely that's precisely because they (and SSL/TLS generally) _don't_ have a One True Suite, they have a pick a suite, any suite approach? And for those of us having to choose between preferring BEAST and RC4 for our webservers, it doesn’t look like we are really seeing the expected benefits of “negotiate a suite”. I’m not trying to use this to condemn the approach; it’s a single example. But it’s a BIG single example. That's because so many ciphersuites shared the same damned problems. When we went through the chained CBC problems in SSHv2 at least we had CTR modes to fallback on. There's a lesson here. I'll make it two for now: a) algorithm agility *does* matter; those who say it's ETOOHARD should do some penitence; b) algorithm agility is useless if you don't have algorithms to choose from, or if the ones you have are all in the same family. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04, at 5:19 PM, Nico Williams n...@cryptonector.com wrote: There's a lesson here. I'll make it two for now: a) algorithm agility *does* matter; those who say it's ETOOHARD should do some penitence; Mea culpa! (Actually I never spoke up on this before) But I do think that difficulty of implementation matters enormously in what gets adopted. There are plenty of application developers who will respond to too high demands with, “ah, I don’t need all of that stuff; I’ll write my own based on Enigma.” ETOOHARD is an errno that has a lot of impact on a lost of software that people use, and so should be given some respect. b) algorithm agility is useless if you don't have algorithms to choose from, or if the ones you have are all in the same family”. Yep. And even though that was the excuse for including Dual_EC_DRBG among the other DBRGs, doesn’t take away from the what you say. I would add a third. c) The set of suites need to be maintained over time, with a clear way to signal deprication and to bring new things in. If we are stuck with the same set of suites that we had 15 years ago, everything in there may age badly. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On Fri, Oct 4, 2013 at 6:55 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: b) algorithm agility is useless if you don't have algorithms to choose from, or if the ones you have are all in the same family”. Yep. And even though that was the excuse for including Dual_EC_DRBG among the other DBRGs, doesn’t take away from the what you say. I've never seen this reason given as an excuse for having Dual_EC (though I can believe it). I was referring to ciphersuites anyways; one does not negotiate RNGs, after all! (But, yes, RNGs frameworks should be pluggable.) I would add a third. c) The set of suites need to be maintained over time, with a clear way to signal deprication and to bring new things in. If we are stuck with the same set of suites that we had 15 years ago, everything in there may age badly. Legacy is a difficult problem. We should be less afraid to cut old things off, but... it always proves too risky, so instead we hobble along until the risk of continuing to allow very old legacy code to interop overwhelms the risk of disabling interop with said old code. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On Thu, Oct 3, 2013 at 10:32 PM, James A. Donald jam...@echeque.com wrote: On 2013-10-04 11:41, Jeffrey Walton wrote: We could not get rid of Trustwave in the public sector (so much for economics). What is wrong with trustwave? The company operates in an industry where trust is a commodity. The company violated the trust,which essentially means they have no product. Rewarding bad behavior was the last thing that should have happened. There's no way we can get rid of the US agency responsible for crypto standards If no one pays attention to their standards, we have gotten rid of them. Well, that's going to be a tough sell for US Federal US DoD, and a number of private sector organizations, such as some in US Financial. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-05 10:44, Jeffrey Walton wrote: On Thu, Oct 3, 2013 at 10:32 PM, James A. Donald jam...@echeque.com wrote: On 2013-10-04 11:41, Jeffrey Walton wrote: We could not get rid of Trustwave in the public sector (so much for economics). What is wrong with trustwave? The company operates in an industry where trust is a commodity. The company violated the trust,which essentially means they have no product. Rewarding bad behavior was the last thing that should have happened. Trustwave should have had its certificate authority revoked from browsers, but it is not in the CA business. It is in the spying business, not in the trust business, but in the distrust business. The scandal is not that it abused its CA authority, but that it was given CA authority. Trustwave spies. That is its job. Soldiers kill people and break things. That is their job. Trustwave's behavior is not scandalous. Mozilla playing footsie with trustwave is scandalous. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] cryptographic agility (was: Re: the spell is broken)
On 10/4/13 3:19 PM, Nico Williams wrote: b) algorithm agility is useless if you don't have algorithms to choose from, or if the ones you have are all in the same family. Yes, I think that's where TLS failed. TLS supports four block ciphers with a 128-bit block size (AES, Camellia, SEED, and ARIA) without (as far as I'm aware) any clear tradeoff between them. As opposed to, say, if Serpent had been provided as the alternative to AES, where there would be a fairly clear trade-off. (Since Serpent was generally recognized as being more conservative, albeit slower, than AES, it would make a nice back-up cipher.) Or, today, the 1024-bit block size version of ThreeFish would add interesting diversity, since it has a radically different blocksize. And, of course, the big problem was that RC4 was the only stream cipher supported by TLS. There's now work to remedy that with a Salsa20 or ChaCha cipher suite, but that should have been done long ago, since everyone knew RC4 was getting old and broken-ish. So, my point is that you should pick certain axes such as stream versus block, or security versus speed, and then choose a small number of ciphersuites which are radically different on those axes. There's no point in defining many cipher suites that cover areas that are already well-covered. And, conversely, if a particular area is only covered by cipher suites that are getting long in the tooth, it's time to proactively cover that area with something new. --Patrick ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] cryptographic agility (was: Re: the spell is broken)
On 2013-10-04, at 10:46 PM, Patrick Pelletier c...@funwithsoftware.org wrote: On 10/4/13 3:19 PM, Nico Williams wrote: b) algorithm agility is useless if you don't have algorithms to choose from, or if the ones you have are all in the same family. Yes, I think that's where TLS failed. TLS supports four block ciphers with a 128-bit block size (AES, Camellia, SEED, and ARIA) without (as far as I'm aware) any clear tradeoff between them. The AES “failure” in TLS is a CBC padding failure. Any block cipher would have “failed” in exactly the same way. So you might be right in general, but this is not a useful example for illustrating your point about different kinds of block ciphers. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
