On 10/03/2013 06:59 PM, Watson Ladd wrote:
On Thu, Oct 3, 2013 at 3:25 PM,leich...@lrw.com wrote:
On Oct 3, 2013, at 12:21 PM, Jerry Leichterleich...@lrw.com wrote:
As *practical attacks today*, these are of no interest - related key
attacks only apply in rather unrealistic scenarios, even
On 10/04/2013 01:23 AM, James A. Donald wrote:
On 2013-10-04 09:33, Phillip Hallam-Baker wrote:
The design of WSDL and SOAP is entirely due to the need to impedance match COM
to HTTP.
That is fairly horrifying, as COM was designed for a single threaded
environment, and becomes and
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,
On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker hal...@gmail.com wrote:
...
Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had no
impact on the security of certificates issued using MD5 until the attack was
dramatically improved and the second pre-image attack became
Some have said...
this [Snowden meta arena] has been a subject of discussion on
the [various] lists as well
Congrats, torproject :-D
Tor Stinks means you're doing it right; good job Tor devs :)
good news everybody; defense in depth is effective and practical!
Yes, fine work all hands,
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 Oct 3, 2013, at 7:33 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
XML was not intended to be easy to read, it was designed to be less painful
to work with than SGML, that is all
More to the point, it was designed to be a *markup* format. The markup is
metadata describing various
On Fri, Oct 4, 2013 at 10:23 AM, John Kelsey crypto@gmail.com wrote:
On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker hal...@gmail.com
wrote:
...
Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had
no impact on the security of certificates issued using MD5 until the
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
On Mon, Sep 30, 2013 at 7:44 PM, arxlight arxli...@arx.li wrote:
Just to close the circle on this:
The Iranians used hundreds of carpet weavers (mostly women) to
reconstruct a good portion of the shredded documents which they
published (and I think continue to publish) eventually reaching
On 4/10/13 11:17 AM, Peter Gutmann wrote:
Trying to get back on track, I think any attempt at TLS 2 is doomed. We've
already gone through, what, about a million messages bikeshedding over the
encoding format and have barely started on the crypto. Can you imagine any
two people on this list
On 2/10/13 00:16 AM, James A. Donald wrote:
On 2013-10-02 05:18, Jerry Leichter wrote:
To be blunt, you have no idea what you're talking about. I worked at
Google until a short time ago; Ben Laurie still does. Both of us have
written, submitted, and reviewed substantial amounts of code in the
http://keccak.noekeon.org/yes_this_is_keccak.html
--John___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
I think redoing TLS just to change the encoding format is to tilt at
windmills. Same for HTTP (not a fan of CORE over DTLS), same for PKIX.
But doing all three at once would actually make a lot of sense and I can
see something like that actually happen. But only if the incremental cost
of each
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
b. There are low-end environments where performance really does
matter. Those often have rather different properties than other
environments--for example, RAM or ROM (for program code and S-boxes)
may be at a premium.
Such environments are getting very rare these days. For example, an
On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote:
So, it seems that instead of AES256(key) the cipher in practice should be
AES256(SHA256(key)).
Is it not the case that (assuming SHA256 is not broken) this defines a cipher
effectively immune to the related-key attack?
Yes, but think about
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 Oct 2, 2013, at 7:46 AM, John Kelsey crypto@gmail.com wrote:
Has anyone tried to systematically look at what has led to previous crypto
failures? T
In the case we are now, I don't think that it is actually crypto failures
(RSA is still secure, but 1024 bit is not. 2048 DHE is still
23 matches
Mail list logo