My brother Nathan Wilcox asked me in private mail about protocol versioning issues. (He was inspired by this thread on [1, 2, 3]). After rambling for a while about my theories and experiences with such things, I remembered this vexing "future-compatibility" issue that I still don't know how to solve:

Here is a puzzle for you (I don't know the answer).

Would it be a reasonable safety measure to deploy a Tahoe-LAFS v1.6, which used SHA-2 but didn't know how to use SHA-3 (because it hasn't been defined yet), and then later deploy a Tahoe-LAFS v1.7, which did know how to use SHA-3, and have v1.7 writers produce new files which v1.6 readers can integrity-check (using SHA-2) and also v1.7 readers can integrity-check (using SHA-3)?

So far this seems like an obvious win, but then you have to say what if, after we've deployed v1.7, someone posts a perl script to sci.crypt which produces second-pre-images for SHA-2 (but not SHA-3)? Then writers who are using Tahoe-LAFS v1.7 really want to be able to *stop* producing files which v1.6 readers will trust based on SHA-2, right? And also, even if that doesn't happen and SHA-2 is still believed to be reliable, then what if some sneaky v1.7 user hacks his v1.7 software to make two different files, sign one of them with SHA-2 and the other wish SHA-3, and then put both hashes into a single immutable file cap and give it to a v1.6 reader, asking him to inspect the file and then pass it on to his trusted, v1.7-using, partner?


This at least suggests that the v1.7 readers need to check *all* hashes that are offered and raise an alarm if some verify and others don't. Is that good enough?





The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to