[tahoe-dev] a crypto puzzle about digital signatures and future compatibility

[Nathan]

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<zooko at zooko.com> wrote:
> Folks:
>
> My brother Nathan Wilcox asked me in private mail about protocol
> versioning issues.  (He was inspired by this thread on
> cryptography at metzdowd.com [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/cryptography@metzdowd.com/msg10791.html
> [2] http://www.mail-archive.com/cryptography@metzdowd.com/msg10807.html
> [3] http://www.mail-archive.com/cryptography@metzdowd.com/msg10805.html
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>