hedging our bets -- in case SHA-256 turns out to be insecure

[Sandy Harris]

On 11/12/09, David-Sarah Hopwood <david-sarah at jacaranda.org> wrote:
> Sandy Harris wrote:
>  > On 11/8/09, Zooko Wilcox-O'Hearn <zooko at 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 at metzdowd.com