On Aug 26, 2009, at 1:39 PM, Zooko Wilcox-O'Hearn wrote:
...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?
"Good enough" for what purpose?
By hypothesis, "SHA-3" is secure, so computing some additional
function can't hurt v1.7 readers.
On the other hand, v1.6 readers are still relying on the the, by
hypothesis, fallen SHA-2, so you haven't *directly* helped them at all.
*Indirectly*, any v1.7 reader who noticed that the SHA-2 hashes agreed
but the SHA-3 matches did not would have detected the attack. The
question is, what could he do about it? You can fall back to extra-
protocol mechanisms - e.g., he's asked to send a message to the Tahoe-
LAFS mailing list about it - but if we posit a world of a large number
of independent users of Tahoe-LAFS, that probably won't reach the
right audience. Writing to the owner of the file sounds nice on
paper, but he may be anonymous, and even if he isn't, his *readers*
may be anonymous to him.
If you really want to rely on detection by v1.7 users actually
contributing to the safety of the larger community, you'd need to
build a support mechanism into the system itself. Something like a
"Caution!" flag - which, of necessity, anyone could set, and whose
semantics would be to give any user the warning "make sure you're
running the latest version of the software, someone has noticed
something odd about this file which your version isn't sensitive to" -
would work. If there's a reliable way to ensure that you're running
the latest version of the software, you can ignore the "Caution!"
flag, thus minimizing the effect of "caution flag spamming".
(Presumably, you store the latest version in Tahoe-LAFS somewhere ...
though you perhaps want to add some additional security on that, like
a separate signature, in case *it* gets its "Caution!" flag set.)
On a general note: The concatenation of multiple hashes can't
possibly be less secure than the most secure of the individual hashes
(at least in protocols where the actual data being hashed is already
known to the receiver; if first pre-image resistance matters to you,
the identity function as a hash will obviously give you problems).
The attacks known have to find delicate balancing changes to the
input. Even a very simple additional check - say a CRC - would block
them as they stand. (That's not to say matching on an additional CRC
couldn't be incorporated into an attack if someone was interested in
doing it.)
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
