Re: how to encrypt and integrity-check with only one key
Zooko Wilcox-O'Hearn wrote: following-up to my own post: On Monday,2009-09-14, at 10:22 , Zooko Wilcox-O'Hearn wrote: David-Sarah Hopwood suggested the improvement that the integrity-check value V could be computed as an integrity check (i.e. a secure hash) on the K1_enc in addition to the file contents. Oops, that's impossible. What David-Sarah Hopwood actually said was that this would be nice if it were possible, but since it isn't then people should pass around the tuple of (v, K1_enc) whenever they want to verify the integrity of the ciphertext. http://allmydata.org/pipermail/tahoe-dev/2009-September/002798.html Zooko is referring to the argument after the first '-' in that post. Note that the argument after the second '-' was wrong; see the correction in http://allmydata.org/pipermail/tahoe-dev/2009-September/002801.html. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Aug 27, 2009, at 2:57 PM, Brian Warner wrote: I've no idea how hard it would be to write this sort of plugin. But I'm pretty sure it's feasible, as would be the site-building tools. If firefox had this built-in, and web authors used it, what sorts of vulnerabilities would go away? What sorts of new applications could we build that would take advantage of this kind of security? What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases. In the meantime, mobile device makers would track you down for the express purpose of breaking into your house at night to pee in your Cheerios, as retaliation for making them explain to their customers why their mobile web browsing is either half the speed it used to be, or not as secure as on the desktop, with no particularly explicable upside. It bugs the hell out of me when smart, technical people spend time and effort devising solutions in search of problems. You need to *start* with the sorts of vulnerabilities you want to do away with, or the kinds of new applications you can build that current security systems don't address, and *then* work your way to solutions that enable those use cases. It's okay to do it in reverse order in the academia, but you seem to be talking about real-world systems. And in real-world systems, you don't get to play Jeopardy with cryptography. Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
Ivan Krsti wrote: What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases. In the meantime, mobile device makers would track you down for the express purpose of breaking into your house at night to pee in your Cheerios, as retaliation for making them explain to their customers why their mobile web browsing is either half the speed it used to be, or not as secure as on the desktop, with no particularly explicable upside. The ideas used in Tahoe are useful tools that can be used to solve important problems. It is true that just dumping them on end users and hoping that end users will use them correctly to solve important problems will fail It is our job to apply these tools, not the end user's job, the hard part being user interface architecture, rather than cryptography protocols. Yurls are one example of an idea for a user interface wrapping Tahoe like methods to solve useful problems. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
