X-Loop: openpgp.net
From: David Honig <[EMAIL PROTECTED]>

> A hash needn't have this property.  A hash is just a mapping with a
smaller
> output space than input.  A cryptographically-strong hash does have this
> property.

That's what I wanted to say. :)

> >I'm using someone else's implementation.
>
> Trust no one is the rule.  Be glad you discovered the flaw
> through your observations.  Skepticism + observation is
> a good thing.

I think I have a pretty good idea of the original flaw (it was in my
implementation); I still have to run some tests, but it looks like Yarrow is
almost done.

> >Ok. I guess it's time to download the counterpane specifications again :)
>
> Presumably you mean download the code for whatever component
> (yarrow, *fish, etc.) you need.

No, I meant the docs (by Bruce Schneier et al), to implement them again.
OTOH, it seems like overkill - see below.

[From a past message]

> >Er.. do you mean that if I encrypt a 64-bit counter equal to zero, and
then
> >I increment it (and re-encrypt), I should get two very different values?
>
> Think about it.  If you *didn't*, then there would be a
> useful distance metric, where an output is related to its
> input in a way you could see without the secret key.

Ok, I am using a different implementation now. Using Blowfish, with the key
"key", a 64-bit counter equal to 0x0, in CFB mode, with a nil initialization
vector, gives me the result: 7DF219349C08D041. Incrementing the counter to
0x1, and encrypting it - with nothing else changed - gives me
7DF219349C08D040 (and it properly decrypts). [The implementation I use will
actually hash the key when initializing the cipher; I have used SHA-1 for
this.]

Are you saying that these results are wrong, and that they should in fact be
wildly different (compared to each other)?

Mark



Reply via email to