[145084] in cryptography@c2.net mail archive
Re: hedging our bets -- in case SHA-256 turns out to be insecure
daemon@ATHENA.MIT.EDU (Sandy Harris)
Tue Nov 17 08:28:16 2009
In-Reply-To: <4AFB50E0.6040605@jacaranda.org>
Date: Tue, 17 Nov 2009 12:39:09 +0800
From: Sandy Harris <sandyinchina@gmail.com>
To: Cryptography <cryptography@metzdowd.com>
On 11/12/09, David-Sarah Hopwood <david-sarah@jacaranda.org> wrote:
> Sandy Harris wrote:
> > On 11/8/09, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
> >
> >> Therefore I've been thinking about how to make Tahoe-LAFS robust against
> >> the possibility that SHA-256 will turn out to be insecure.
>
> [...]
>
> > Since you are encrypting the files anyway, I wonder if you could
> > use one of the modes developed for IPsec where a single pass
> > with a block cipher gives both encrypted text and a hash-like
> > authentication output. That gives you a "free" value to use as
> > H3 in my scheme or H2 in yours, and its security depends on
> > the block cipher, not on any hash.
>
>
> Tahoe is intended to provide resistance to collision attacks by the
> creator of an immutable file: the creator should not be able to generate
> files with different contents, that can be read and verified by the same
> read capability.
>
> An authenticated encryption mode won't provide that -- unless, perhaps,
> it relies on a collision-resistant hash.
I was suggesting using the authentication data in the construction:
C(x) = H1(H2(x)||A(x))
where H1 is a hash with he required output size, H2 a hash with
a large block size and A the authentication data from your
encryption.
This is likely a very bad idea if you already use that data in some
other way, e.g. for authenticating stored data. However, if C is
going to be your authentication mechanism, then this might be
a cheap way to get one input to it.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
