On 11/12/09, David-Sarah Hopwood david-sa...@jacaranda.org wrote:
Sandy Harris wrote:
On 11/8/09, Zooko Wilcox-O'Hearn zo...@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.
[...]
On Wed, Nov 11, 2009 at 10:03:45AM +0800, Sandy Harris wrote:
C(x) = H1(H1(x) || H2(x))
This requires two hash(x) operations. A naive implementation needs
two passes through the data and avoiding that does not appear to
be trivial. This is not ideal since you seem very concerned about
On Nov 11, 2009, at 10:03 AM, Sandy Harris wrote:
On 11/8/09, Zooko Wilcox-O'Hearn zo...@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.
NIST are dealing with that via the AHS process.
On 11/8/09, Zooko Wilcox-O'Hearn zo...@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.
NIST are dealing with that via the AHS process. Shouldn't you just use
their results?
We could use a
On Nov 8, 2009, at 6:30 AM, Zooko Wilcox-O'Hearn wrote:
I propose the following combined hash function C, built out of two
hash functions H1 and H2:
C(x) = H1(H1(x) || H2(x))
I'd worry about using this construction if H1's input block and output
size were the same, since one might be able
Folks:
We're going to be deploying a new crypto scheme in Tahoe-LAFS next
year -- the year 2010. Tahoe-LAFS is used for long-term storage, and
I won't be surprised if people store files on Tahoe-LAFS in 2010 and
then rely on the confidentiality and integrity of those files for
many
