John Kelsey critiques the proposal from Practical Cryptography:
> >"We do not know of any literature about how to fix the hash functions,
> >but here is what we came up with when writing this book. ... Let h be
> >one of the hash functions mentioned above. Instead of m->h(m), we use
> >m->h(h(m)
latter is chosen by
the CA and depending on its policies, may be easy or hard to predict.
The name "serial number" suggests a degree of sequentiality and some
CAs may follow such a policy, which could allow a motivated attacker to
predict the value with considerable accuracy.
Hal Finney
ons to collide. The chance of this happening for
any input is 1/2^n so it will take about 2^n work to find one. This is
the work necessary to find a collision between the lines. This level of
work is greater than that needed to invert the overall hash construction
hence does not represent an
(IV1) -> B1 -> B2 -> B3 -> ... Bk -> H1
(IV2) -> B1 -> B2 -> B3 -> ... Bk -> H2
and again combine H1 and H2. Here we run a hash function twice in
parallel but with two different IV values. Superficially it looks weaker
than John Denker's construction, because
Jerry Leichter writes:
> It all depends on how you define an attack, and how you choose to define your
> security. I explored the "outer edge": Distinguishability from a random
> function. For a random function from {0,1}*->{0,1}^k, we expect to have to do
> 2^k work (where the unit of work is a
vulnerability of
hashes that support incremental hashing, as any useful hash surely must,
then perhaps it is worth exploring.
Hal Finney
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
find a collision in the output of two independent
n-bit hashes from 2^n to n*2^(n/2). Your approach effectively makes
this (n^3)*2^(n/2) which is an improvement, but still not attaining
the exponential security increase expected from ideal hash functions.
Hal Finney
--
Dan Carosone writes:
> My immediate (and not yet further considered) reaction to the
> description of Joux' method was that it might be defeated by something
> as simple as adding a block counter to the input each time.
Right after the talk, Scott Fluhrer (I think it was) spoke up with
several qui
sage
Digest, where RIPE is the EU's RACE Integrity Primitives Evaluation
project, and I haven't been able to find out what RACE stands for.
RIPEM was an old implementation by Mark Riordan of the PEM (Privacy
Enhanced Email) standard which
with IV on M1
and M1', and you found a collision starting with the common output of
that stage on M2 and M2', your four collisions would be:
M1 || (M1 xor M2)
M1 || (M1 xor M2')
M1' || (M1' xor M2)
M1' || (M1'
row away half of the strength to produce
an output that avoids the Joux attack. I think cryptographers will look
harder to try to find a way of combining sub-blocks which will retain the
strength of the individual pieces rather than throwing half of it away.
Hal Finney
---
Matt Crawford writes:
> If you think of POW as a possible SPAM mitigation, how does the first
> receiving MTA assure the next MTA in line that a message was "paid
> for?" Certainly the mail relay doesn't want to do new work, but the
> second MTA doesn't know that the first isn't a spambot.
The
ons in the broken hashes very easily,
without having to go through the construction Joux described. That
doesn't change Joux's fundamental point about the weakness in iterative
hashes, but further demonstrates the power of the Wang technique.
Hal Finney
oosing the data values, which would
make it harder to attack HMAC since you presumably would not be able to
choose the data without knowing the IV. It may still be that you could
do something with HMAC built on one of the broken ciphers, but we will
have to wait for a fuller description of the
raffic control, etc?
It's possible that these things could happen, but that's not necessarily
bad. After all, if people ever got to where they would buy and sell
RPOWs for money, they could serve in place of ecash. The main question
is whether there will be any use for them so compell
source code which is open source and available
from rpow.net.
Hal Finney
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
onceivably you could get lucky and find a collision
without even knowing key2. But that seems like a very remote possibility.
Hal Finney
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
uced.
This model makes it even more important to move towards cryptographic
assurance for payment systems.
Hal Finney
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
101 - 118 of 118 matches
Mail list logo
