Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Eric Rescorla e...@networkresonance.com writes: At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote: Steven M. Bellovin s...@cs.columbia.edu writes: So -- who supports TLS 1.2? Not a lot, I think. The problem with 1.2 is that it introduces a pile of totally gratuitous incompatible changes to the protocol that require quite a bit of effort to implement (TLS 1.1 - 1.2 is at least as big a step, if not a bigger step, than the change from SSL to TLS), complicate an implementation, are difficult to test because of the general lack of implementations supporting it, and provide no visible benefit. Why would anyone rush to implement this when what we've got now works[0] just fine? Ordinarily I wouldn't bother to respond to Peter's curmudgeon act, :-). but since I was obviously heavily involved with TLS 1.2, I think a bit of context is in order. I'm aware of why the changes were made, but the point of my comment was to explain their consequences in the lack of support for TLS 1.2. I had (AFAIK) one of the first implementations of TLS 1.1, an incremental upgrade of TLS 1.0 (and then had some fun trying to find things to interop against) but for TLS 1.2 I haven't implemented it and have no plans to implement it because it provides absolutely no benefit over TLS 1.1 and a great many downsides. Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those between SSL and TLS. I'm not particularly happy about that either, but it's what we felt was necessary to do a principled job. It may have been a nicely principled job but what actual problem is the switch in hash algorithms actually solving? Making changes of such magnitude to a very, very widely-deployed protocol is always a tradeoff between the necessity of the change and the pain of doing so. In TLS 1.2 the pain is proportionate to the scale of the existing deployed base (i.e. very large) and the necessity of doing so appears to be zero. I don't know of any attack or threat to the existing dual-hash mechanism that TLS 1.2 addresses, and it may even make things worse by switching from the redundant dual-hash (a testament to the original SSL designers) to a single algorithm. This is why I called the changes gratuitous, there is no threat that they address - it can even be argued (no doubt endlessly) that they make the PRF weaker rather than stronger - but they come at considerable cost. SSL/TLS is (and has been for many years) part of the Internet infrastructure. You don't make significant, totally incompatible changes to the infrastructure without very carefully weighing the advantages and disadvantages. Maybe there'll be a sudden flood of unexpected TLS 1.2 implementations right after I post this, but at the moment it seems that implementors have weighed up the cost and said no thanks. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Sat, Jan 24, 2009 at 2:36 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: You seem to be out of touch I am afraid. Just look at what many O/S distributions do. They adopt a new OpenSSL 0.9.Xy release from time to time (for some initial y) and back-port security fixes never changing the letter. One can't actually tell from openssl version what version one is running and which fixes have been applied. Why am I back-porting patch-sets to 0.9.8i? Is that because there is no demand for bugfix releases? There is indeed demand for real bugfix releases, just that people have gotten used to doing it themselves, but this is not very effective and is difficult to audit. It is not that I am unaware of this, I was pointing out what we actually do. But you do have a fair point and I will take it up with the team. However, I wonder how this is going to pan out? Since historically pretty much every release has been prompted by a security issue, but also includes new features and non-security bugfixes, in order to release 0.9.8j the way you want us to, we would also have to test and release security updates for 0.9.8 - 0.9.8i, for a total of 10 branched versions. I think this is asking rather a lot of volunteers! Don't suggest that we should release feature/bugfix versions less often, I think we already do that less often than we should. Perhaps the answer is that we security patch every version that is less than n months old, and end-of-life anything before that? Suggestions for reasonable values of n? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bitcoin v0.1 released
Jonathan Thornburg writes: In the modern world, no major government wants to allow untracable international financial transactions above some fairly modest size thresholds. (The usual catch-phrases are things like laundering drug money, tax evasion, and/or financing terrorist groups.) To this end, electronic financial transactions are currently monitored by various governments their agencies, and any but the smallest of transactions now come with various ID requirements for the humans on each end. But if each machine in a million-node botnet sends 10 cents to a randomly chosen machine in another botnet on the other side of the world, you've just moved $100K, in a way that seems very hard to trace. To me, this means that no major government is likely to allow Bitcoin in its present form to operate on a large scale. Certainly a valid point, and one which has been widely discussed in the debates over the years about electronic cash. Bitcoin has a couple of things going for it: one is that it is distributed, with no single point of failure, no mint, no company with officers that can be subpoenaed and arrested and shut down. It is more like a P2P network, and as we have seen, despite degrees of at least governmental distaste, those are still around. Bitcoin could also conceivably operate in a less anonymous mode, with transfers being linked to individuals, rather than single-use keys. It would still be useful to have a large scale, decentralized electronic payment system. It also might be possible to refactor and restructure Bitcoin to separate out the key new idea, a decentralized, global, irreversible transaction database. Such a functionality might be useful for other purposes. Once it exists, using it to record monetary transfers would be a sort of side effect and might be harder to shut down. I also worry about other domestic ways nasty people could exploit a widespread Bitcoin deployment: * Spammer botnets could burn through pay-per-send email filters trivially (as usual, the costs would fall on people other than the botnet herders spammers). * If each machine in a botnet sends 1 cent to a herder, that can add up to a significant amount of money. In other words, Bitcoin would make botnet herding and the assorted malware industry even more profitable than it already is. It's important to understand that the proof-of-work (POW) aspect of Bitcoin is primarily oriented around ensuring the soundness of the historical transaction database. Each Bitcoin data block records a set of transactions, and includes a hash collision. Subsequent data blocks have their own transactions, their own collisions, and also chain to all earlier hashes. The result is that once a block is buried under enough new blocks, it is essentially certain (given the threat model, namely that attackers cannot muster more than X% of the compute power of legitimate node operators) that old transactions can't be reversed. Creating new coins is indeed currently also being done by POW, but I think that is seen as a temporary expedient, and in fact the current software phases that out over several years. Hence worries about botnets being able to manufacture large quantities of POW tokens are only a temporary concern, in the context of Bitcoin. There have been a number of discussions in the past about POW tokens as anti spam measures, given the botnet threat. References are available from Proof-of-work system on Wikipedia. Analyses have yielded mixed results, depending on the assumptions and system design. If POW tokens do become useful, and especially if they become money, machines will no longer sit idle. Users will expect their computers to be earning them money (assuming the reward is greater than the cost to operate). A computer whose earnings are being stolen by a botnet will be more noticeable to its owner than is the case today, hence we might expect that in that world, users will work harder to maintain their computers and clean them of botnet infestations. Countermeasures by botnet operators would include moderating their take, perhaps only stealing 10% of the productive capacity of invaded computers, so that their owners would be unlikely to notice. This kind of thinking quickly degenerates into unreliable speculation, but it points out the difficulties of analyzing the full ramifications of a world where POW tokens are valuble. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
At Sat, 24 Jan 2009 14:55:15 +1300, Peter Gutmann wrote: Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those between SSL and TLS. I'm not particularly happy about that either, but it's what we felt was necessary to do a principled job. It may have been a nicely principled job but what actual problem is the switch in hash algorithms actually solving? Making changes of such magnitude to a very, very widely-deployed protocol is always a tradeoff between the necessity of the change and the pain of doing so. In TLS 1.2 the pain is proportionate to the scale of the existing deployed base (i.e. very large) and the necessity of doing so appears to be zero. I don't know of any attack or threat to the existing dual-hash mechanism that TLS 1.2 addresses, and it may even make things worse by switching from the redundant dual-hash (a testament to the original SSL designers) to a single algorithm. This is why I called the changes gratuitous, there is no threat that they address - it can even be argued (no doubt endlessly) that they make the PRF weaker rather than stronger - but they come at considerable cost. I agree that given the current set of attacks on SHA-1 and MD5, there was no existing attack on the protocol. However, that doesn't mean that improvements in analysis wouldn't lead to such attacks and so the general feeling of the community was to err on the side of safety. No doubt if we hadn't done so, there would be people screaming about how TLS still used MD5. Indeed, that's how this thread started. So, once again, I don't share your opinions about these changes being gratuitous. Moreover, the bulk of the changes weren't to the PRF. That's actually quite a trivial change to implement, but rather to have accurate signalling about what combinations of hashes and signatures implementations could support--something that was painfully non-orthogonal in SSLv3 and earlier versions of TLS. Again, one could argue that we could have hacked around this and indeed the original Bellovin-Rescorla paper described a number of such hacks, but the general feeling of the TLS WG was that it was more important to get it right. SSL/TLS is (and has been for many years) part of the Internet infrastructure. You don't make significant, totally incompatible changes to the infrastructure without very carefully weighing the advantages and disadvantages. Which we did--including having the very discussion we are having now--and concluded that the course of action we took was the right one. You're of course free to weigh the evidence yourself and come to a different conclusion, and even to hold the opinion that those who agree with you are complete fools, but it's simply not accurate to imply, as you do here, that we didn't think about it. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bitcoin v0.1 released
h...@finney.org (Hal Finney) on Saturday, January 24, 2009 wrote: Countermeasures by botnet operators would include moderating their take, perhaps only stealing 10% of the productive capacity of invaded computers, so that their owners would be unlikely to notice. This kind of thinking quickly degenerates into unreliable speculation, but it points out the difficulties of analyzing the full ramifications of a world where POW tokens are valuble. Some people tell me that the 0wned machines are among the most secure on the network because botnet operators work hard to keep others from compromising their machines. I could see the operators moving toward being legitimate security firms, protecting computers against compromise in exchange for some of the proof of work (POW) money. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
