On 6/01/12 03:56 AM, Thor Lancelot Simon wrote:
On Thu, Jan 05, 2012 at 12:45:14PM +1300, Peter Gutmann wrote:
Thor Lancelot Simon<t...@panix.com> writes:
However, while looking at it I have been wondering why something simpler and
better analyzed than the "folded" SHA should not be used.
Folding the output is belt-and-suspenders security, it denies an attacker
direct access to the raw output of whatever the last stage of processing
(3DES/AES/SHA1/HMAC-xxx/whatever) is. For example my generator is designed on
the basis that any part of it should be able to fail completely (replacing a
crypto step with memcpy() or using all-zero keys) without it affecting the
security of the overall design, and to do that you need a lot of redundant
security. Sure, using HMAC is cryptographically sound, but what happens if
your HMAC key is compromised, or an attacker can glitch the hashing operation,
or something else goes wrong?
I'm proposing to use HMAC with two different, non-secret keys: one to
generate the data supplied to the output stage, one to generate the
data mixed back in. It seems to me this uses the same number of
invocations of the hash function per output byte, and, unless I'm missing
something, the "folding" surely isn't _more_ secure.
The way I treat this problem is that it is analogous to inventing ones
own algorithm. From that perspective, one can ask:
1. is the current one broken? really broken?
2. does the algorithm really rely on it, or is it just a nice to have?
3. why not just use a bigger bazooka?
4. will spending time on this "unproven" issue take away time on a more
important issue?
5. does the replacement just kick the can along a bit further?
The way I see it, the requirement is to stop looking back from the
output into the mixer. SHA1 should be fine for that, and if that's not
good, just up the generation to SHA2.
my 2 bits of entropy...
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
