RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Weger, B.M.M. de b.m.m.d.we...@tue.nl writes: Bottom line, anyone fielding a SHA-2 cert today is not going=20 to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? I have a general outline of a timeline for adoption of new crypto mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see Question J about 2/3 of the way down. It's not meant to be definitively accurate for all cases but was created as a rough guideline for people proposing to introduce new crypto mechanisms to give an idea of how long they should expect to wait to see them adopted. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
Weger, B.M.M. de wrote: In my view, the main lesson that the information security community, and in particular its intersection with the application building community, has to learn from the recent MD5 and SHA-1 history, is that strategies for dealing with broken crypto need rethinking. On the other hand, compared to many other aspects of our security infrastructure, even MD5 does quite well. Of course, that is not meant to be taken as an excuse. I agree with your call to have smooth transition systems to go from one cipher to another, but when to make the transition is a difficult decision to make. PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) offering the video and audio files of the 25c3 presentation MD5 considered harmful today, provide for integrity checking of those files their, uhm, MD5 hashes. It seems to me they are only provided to protect against transmission errors, and they are fine for that. Otherwise, it would be a more serious mistake to transfer them in-band. Security is a spectrum. Thanks, Marcus - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What risk is being defended against here?
* Jerry Leichter: Any speculations (beyond bureaucracy at its finest)? I wild guess would be fraudulent testing organizations which claim to have been subject to fraud themselves, and the testing standards body answered with some sort of regulation. (For certain German language test instances at certain sites, there used to me impossibly high participation numbers. The alleged certificates of the results were probably simply forged, but that's where I got the idea from.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [Opensim-dev] Technical assessment of Cable Beach asset server
From: Toni Alatalo ant...@kyperjokki.fi Subject: Re: [Opensim-dev] Technical assessment of Cable Beach asset server To: opensim-...@lists.berlios.de Date: Thu, 15 Jan 2009 18:47:00 +0200 Reply-To: opensim-...@lists.berlios.de Eugen Leitl kirjoitti: On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote: As an aside from the peanut gallery, it would be nice to have asset storage in a distributed cryptographic filestore like Tahoe http://allmydata.org/~warner/pycon-tahoe.html that has been my understanding as well. basically after worked a bit with the guys who pushed it in the Fenfire project (in 2002). i've understood that basically by using URIs as references to assets we get that: URLs for current http stuff and location independent URNs with distributed things like p2p networks. seems that Tahoe also uses short URI-like strings - dunno why 'URI-like' and not just URIs but anyway :) .. also as SL and OpenSim already uses UUIDs i guess some things are basically kind of ready for this. http://www.ht03.org/papers/pdfs/24.pdf is about the work in that area i was interested back long ago, dunno about the current implementations whether Tapestry, that Tahoe or something I haven't heard of is the thing, but i guess the basic idea is the same. in that Fenfire Storm the idea was to use content based hashes as IDs of files (like images), similar to Freenode -- the goal not being anonymous publishing in a secure p2p net, but instead having a nice storage system for both local own files and publishing them on the net. goals included the secure storage via redundancy, that seems to be emphasized in Tahoe and is indeed a great motivation for these things. looking forward to learning more, perhaps by testing Tahoe ~~Toni ___ Opensim-dev mailing list opensim-...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bitcoin v0.1 released
Dustin D. Trammell wrote: Satoshi Nakamoto wrote: You know, I think there were a lot more people interested in the 90's, but after more than a decade of failed Trusted Third Party based systems (Digicash, etc), they see it as a lost cause. I hope they can make the distinction that this is the first time I know of that we're trying a non-trust-based system. Yea, that was the primary feature that caught my eye. The real trick will be to get people to actually value the BitCoins so that they become currency. I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite. It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. Send X bitcoins to my priority hotline at this IP and I'll read the message personally. Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial. It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. Satoshi Nakamoto http://www.bitcoin.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Mon, 12 Jan 2009 16:05:08 +1300 pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote: Weger, B.M.M. de b.m.m.d.we...@tue.nl writes: Bottom line, anyone fielding a SHA-2 cert today is not going=20 to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? I have a general outline of a timeline for adoption of new crypto mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see Question J about 2/3 of the way down. It's not meant to be definitively accurate for all cases but was created as a rough guideline for people proposing to introduce new crypto mechanisms to give an idea of how long they should expect to wait to see them adopted. My analysis is similar to Peter's: 2-3 years for an RFC, 2-3 years for design/code/test, 2 years average delay for the next major release of Windows which will include it, 5 years for most of the older machines to die off. I've mentioned it before, but I'll point to the paper Eric Rescorla wrote a few years ago: http://www.cs.columbia.edu/~smb/papers/new-hash.ps or http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: if you're running a public-facing web server, you *can't* offer a SHA-2 certificate because you have no way of knowing if the client supports SHA-2. Fixing that requires a TLS fix; see the above timeline for that. -- --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bitcoin v0.1 released
On Sat, 17 Jan 2009, Satoshi Nakamoto wrote: [[various possible uses of Bitcoin et al]] Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. 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. 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. Is there something obvious I've missed? Is there a clever aspect of the design which prevents botnets from exploiting the system? Is there a way for every major government to monitor all Bitcoin transactions to watch for botnet-to-botnet sending? -- -- From: Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
