|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
|
> > DES keys are 56 bits, which makes it 8192 times as
> > hard on average, not 32.
>
> I said full DES, which uses a 64 bit key. Standard
> DES uses a 56 bit
> key.
Maybe I'm mistaken. The only DES (single DES, not
triple) that I know has 64 bit keys, but every 8th bit
is a parity bit, and is ignored. Could you send me
pointer to the variant that you've mentioned? I'd
like to read up on it.
> > The paper hasn't been released yet, but as I
> > understand it, this is just to generate one
> collision.
> > It doesn't mean that if you have a hash that you
> can
> > create another object that has the same hash
> value.
>
> The point of a cryptographic message digest is to
> produce a unique and
> irreversible transformation on the data source
> within the period. If an
> implementation fails this premise it should not be
> used since the
> cryptographic implementations that include such a
> digest require it to
> provide those properties in order to perform their
> functions correctly.
> If one piece is failing, the integrity of the entire
> chain is at risk.
Yes. I think that we all understand the point of a
cryptographic hash. (I think that you might want to
choose a different word than "unique" though. They're
not unique, which is why we have a problem.)
> Also, only in public key cryptography do there exist
>
> better-than-brute-force attacks possible against a
> technique that don't
> render that technique "broken" (e.g. QFS, NFS).
> SHA-1 is not public key
> cryptography.
Could you expand on this?
> > This still takes 2^(160) operations.
>
> This is the worst case. The average case would be
> approximately 2**80
> iterations.
Are you sure? 2**80 is for a birthday attack. We're
not talking about the birthday attack here. The
average should be half of 2**160, which is 2**159.
> > Of course you can string many machines together to
> do
> > this in parallel, and there's Moore's Law, and
> while I
> > agree with you that there's nothing wrong with
> > switching to SHA-256, 385, or 512, I just don't
> think
> > that there's any reason for everyone to go
> bananas.
>
> I never advocated going bananas. I advocated
> replacing SHA-1 with an
> as-yet-unbroken message digest algorithm.
I didn't think that you were going bananas. You
suggested using a SHA with a longer digest, which
seems perfectly reasonable to me.
> If the
> lock broke on your
> front door, wouldn't you replace it?
I would hope so (but I admit I have been lazy about
home repair in the past). If you were to pose the
question a different way, for example, "If thieves
attempted to break the lock on your front door, and an
as yet unpublished paper by reputable Chinese
cryptographers said that they theoretically could
break it in 18,700 years, would you replace the
lock?", I might change the lock, but I don't think
that I'd do so with any great haste. (You have my
apologies for what might be the longest run on
sentence ever.)
> The real problem here is that SHA-* and RIPEMD* are
> all based on the
> same unbalanced Feistel network structure and are
> thus potentially
> vulnerable to the same type of attack. I would like
> to see
> cryptographic implementations start to implement MDs
> that do not use
> this technique.
I agree. There should be more research into secure
hash functions. There aren't enough of them, and the
ones that you mention are all similar. (Are you sure
that these are considered to be Feistel though?)
It should be interesting to read the published paper.
I'll have a bottle of aspirin handy. I'm sure it
won't be easy reading.
John
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|