<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Good point on the lack of need of Comb4P. If I understood correctly,
the argument against is (mostly) performance. I argue performance isn't
really a problem --- hash functions work over larger states (at least
512 bits), which allows them to do more work (using more rounds, too).
It evens things up. Most SHA-3 candidates are already much faster than
AES-256. Furthermore, we can exploit parallelism in hashes just like in
CTR-mode ciphers (e.g., 3.80 cpb Shabal, the plethora of
password-cracking SSE2 SHA-1/256 implementations, etc).<br>
<br>
I don't think hashes being mostly designed for collision resistance
represents a large problem. In fact, PRF-distinguishers are often made
from (partial) collisions. Of course, this doesn't mean distinguishers
are as hard as finding collisions, but it does seem to suggest that
resisting collisions is harder than making an indistinguishable
function.<br>
<br>
Best regards,<br>
Samuel Neves<br>
<br>
On 22-06-2010 22:50, David-Sarah Hopwood wrote:<br>
<blockquote cite="mid:4C213030.5020807@jacaranda.org" type="cite">
<pre wrap="">Samuel Neves wrote:
</pre>
<blockquote type="cite">
<pre wrap="">During the last few months, the 100 year cryptography project saw a
gradual convergence from postquantum/lattice/subset-sum based digital
signatures to hash-based signatures. The argument there is that since we
are using a hash function H anyway to hash the input, the strength of
the digital signatures is ultimately always dependent on H. Thus, a
H-based digital signature algorithm 'just makes sense'.
Hashing itself has been made more future-resilient by combining two
different hash functions by Comb4P. This function would be our above
mentioned H.
In all of this, encryption seems to be left out of the fun. Instead,
plans are to mix AES (in counter mode) and Salsa20. Why? My suggestion
here is to also use H for this as well. This can be done is two
different ways: by a Feistel network construction (suggested by Zooko)
or counter mode (not unlike Salsa20's mode of operation).
If I remember correctly, we need a 4-round Feistel network with a
perfect round function to achieve provable "strong" pseudorandom
permutation status. However, since we intend to encipher things in
counter mode (at least it would seem to, from the AES and Salsa20
usage), we would use this Feistel network in counter mode.
The alternative is to cut the middleman: we hash a secret key K and a
counter CTR and XOR it with our plaintext --- C = H(K||CTR) ^ P. This is
roughly how Salsa20 works, and seems to be secure as long as H is secure.
This would make all cryptographic primitives in the 100 year
cryptography project dependent on H, which itself amasses the strengths
of more than one hash function to achieve future-resilience.
</pre>
</blockquote>
<pre wrap="">
We require IND-CPA security for the cipher (since integrity is achieved
independently of encryption). The IND-CPA security of a hash in CTR mode
is dependent on the PRF property of the hash. This means that the Comb4P
combiner is not needed for this application; XOR is a robust combiner for
independently-keyed PRFs (i.e. C = H1(K1 || CTR) ^ H2(K2 || CTR) ^ P,
where K1 and K2 are derived using a secure KDF).
The argument against using a hash in CTR mode as a cipher, is that the
design criteria for a hash normally focus on other properties than the
PRF property, such as collision-resistance. Since collision-resistance
typically requires more rounds, this may make the hash unnecessarily more
costly than a cipher with comparable security. Or if a hash and a cipher
have the same overall cost, then the hash might to be less secure when
used as a PRF, all else being equal, because its design is not focussed
on achieving the PRF property.
Also note that the argument for using hash-based signatures is primarily
that it would remove a dependency on any public-key trapdoor function.
Trapdoor one-way functions are fundamentally more difficult to construct,
and potentially more susceptible to new analysis techniques within the
next 100 years [*], than plain one-way functions or second-preimage-
resistant hashes. This argument doesn't really apply to the cipher,
which already uses only symmetric crypto.
[*] I'm personally more worried about new cryptanalysis than I am by
quantum computers.
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
tahoe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a>
<a class="moz-txt-link-freetext" href="http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev">http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>