On 10/04/2013 07:38 AM, Jerry Leichter wrote:
On Oct 1, 2013, at 5:34 AM, Ray Dillinger b...@sonic.net wrote:
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed.
If you're going to choose a single
On Oct 5, 2013, at 6:12 PM, Ben Laurie wrote:
I have to take issue with this:
The security is not reduced by adding these suffixes, as this is only
restricting the input space compared to the original Keccak. If there
is no security problem on Keccak(M), there is no security problem on
On Oct 6, 2013, at 6:29 PM, Jerry Leichter leich...@lrw.com wrote:
On Oct 5, 2013, at 6:12 PM, Ben Laurie wrote:
I have to take issue with this:
The security is not reduced by adding these suffixes, as this is only
restricting the input space compared to the original Keccak. If there
is no
On Oct 6, 2013, at 11:41 PM, John Kelsey wrote:
...They're making this argument by pointing out that you could simply stick
the fixed extra padding bits on the end of a message you processed with the
original Keccak spec, and you would get the same result as what they are
doing. So if
On 05/10/13 20:00, John Kelsey wrote:
http://keccak.noekeon.org/yes_this_is_keccak.html
Seems the Keccac people take the position that Keccak is actually a way
of creating hash functions, rather than a specific hash function - the
created functions may be ridiculously strong, or far too
On 05/10/13 00:09, Dan Kaminsky wrote:
Because not being fast enough means you don't ship. You don't ship, you
didn't secure anything.
Performance will in fact trump security. This is the empirical reality.
There's some budget for performance loss. But we have lots and lots of
slow
On Oct 7, 2013, at 6:04 PM, Philipp Gühring p...@futureware.at wrote:
it makes no sense for a hash function: If the attacker can specify
something about the input, he ... knows something about the input!
Yes, but since it's standardized, it's public knowledge, and just knowing
the padding
On 5 October 2013 20:18, james hughes hugh...@mac.com wrote:
On Oct 5, 2013, at 12:00 PM, John Kelsey crypto@gmail.com wrote:
http://keccak.noekeon.org/yes_this_is_keccak.html
From the authors: NIST's current proposal for SHA-3 is a subset of the
Keccak family, one can generate the test
On Sat, 2013-10-05 at 12:18 -0700, james hughes wrote:
and the authors state that
You know why other people than the authors are doing cryptoanalysis on
algorithms? Simply because the authors may also oversee something in the
analysis of their own algorithm.
So while the argument the original
Most applications of crypto shouldn't care much about performance of the
symmetric crypto, as that's never the thing that matters for slowing things
down. But performance continues to matter in competitions and algorithm
selection for at least three reasons:
a. We can measure performance,
Because not being fast enough means you don't ship. You don't ship, you
didn't secure anything.
Performance will in fact trump security. This is the empirical reality.
There's some budget for performance loss. But we have lots and lots of
slow functions. Fast is the game.
(Now, whether my
On Oct 1, 2013, at 5:34 AM, Ray Dillinger b...@sonic.net wrote:
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed.
If you're going to choose a single standard cryptographic algorithm, you have
to
On Fri, Oct 4, 2013 at 12:27 AM, David Johnston d...@deadhat.com wrote:
On 10/1/2013 2:34 AM, Ray Dillinger wrote:
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed. ~
What makes you think Keccak is
On Oct 3, 2013, at 9:27 PM, David Johnston d...@deadhat.com wrote:
On 10/1/2013 2:34 AM, Ray Dillinger wrote:
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed. ~
What makes you think Keccak is
http://keccak.noekeon.org/yes_this_is_keccak.html
--John___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Jerry Leichter wrote:
Currently we have SHA-128 and SHA-256, but exactly why one should choose one
or the other has never been clear - SHA-256 is somewhat more expensive, but
I can't think of any examples where SHA-128 would be practical but SHA-256
would not. In practice, when CPU is thought
On 2013-10-05 16:40, james hughes wrote:
Instead of pontificating at length based on conjecture and conspiracy
theories and smearing reputations based on nothing other than hot air
But there really is a conspiracy, which requires us to consider
conjectures as serious risks, and people
On Oct 5, 2013, at 11:54 AM, radi...@gmail.com wrote:
Jerry Leichter wrote:
Currently we have SHA-128 and SHA-256, but exactly why one should choose
one or the other has never been clear - SHA-256 is somewhat more
expensive, but I can't think of any examples where SHA-128 would be
On Oct 5, 2013, at 12:00 PM, John Kelsey crypto@gmail.com wrote:
http://keccak.noekeon.org/yes_this_is_keccak.html
From the authors: NIST's current proposal for SHA-3 is a subset of the Keccak
family, one can generate the test vectors for that proposal using the Kecca
kreference code. and
On 10/1/2013 2:34 AM, Ray Dillinger wrote:
What I don't understand here is why the process of selecting a
standard algorithm for cryptographic primitives is so highly focused
on speed. ~
What makes you think Keccak is faster than the alternatives that were
not selected? My implementations
On 2013-10-01 10:24, John Kelsey wrote:
If you want to understand what's going on wrt SHA3, you might want to look at
the nist website
If you want to understand what is going on with SHA3, and you believe
that NIST is frank, open, honest, and has no ulterior motives, you might
want to look
What I don't understand here is why the process of selecting a standard
algorithm for cryptographic primitives is so highly focused on speed.
We have machines that are fast enough now that while speed isn't a non issue,
it is no longer nearly as important as the process is giving it precedence
Okay, I didn't express myself very well the first time I tried to say this.
But as I see it, we're still basing the design of crypto algorithms on
considerations that had the importance we're treating them as having about
twelve years ago.
To make an analogy, it's like making tires when
On Tue, 2013-10-01 at 02:34 -0700, Ray Dillinger wrote:
What I don't understand here is why the process of selecting a
standard algorithm for cryptographic primitives is so highly focused
on speed.
We have machines that are fast enough now that while speed isn't a non
issue, it is no
24 matches
Mail list logo