The scenario of a 1.7 client producing two malicious files is a little off, IMO.
Instead, an attacker would claim to be the older client and just produce a single malicious Hypothetically-Compromised-SHA2 reference, feeding different contents to different victims. The victims would be all versions which trust SHA2, so both 1.6 and 1.7. This is a downgrade attack: pretend to be the version which only can handle the weakest protocol parameters. Think of it this way: The vulnerable set is all versions which support the vulnerable protocol parameter. A given revision is vulnerable to attacks against the union of all supported protocol parameters. Also, for simplicity, I consider altering which protocol parameters are acceptable to require upgrading the software version. In other words, I consider most configuration options to be equivalent to source code. (In fact, I tend to promote removing configuration options whenever feasible.) Flexibility is the enemy. =T Nathan Wilcox On Wed, Aug 26, 2009 at 10:39 AM, Zooko Wilcox-O'Hearn<[email protected]> wrote: > Folks: > > My brother Nathan Wilcox asked me in private mail about protocol > versioning issues. (He was inspired by this thread on > [email protected] [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? > > Hm... > > 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? > > :-/ > > Regards, > > Zooko > > [1] http://www.mail-archive.com/[email protected]/msg10791.html > [2] http://www.mail-archive.com/[email protected]/msg10807.html > [3] http://www.mail-archive.com/[email protected]/msg10805.html > > _______________________________________________ > tahoe-dev mailing list > [email protected] > http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev > _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
