[146993] in cryptography@c2.net mail archive
Re: [Cryptography] soft chewy center
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Tue Sep 10 19:05:48 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 10 Sep 2013 19:05:40 -0400
From: "Perry E. Metzger" <perry@piermont.com>
To: bmanning@isi.edu
In-Reply-To: <20130910215828.GB3840@vacation.karoshi.com.>
Cc: bmanning@vacation.karoshi.com, cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Tue, 10 Sep 2013 21:58:28 +0000 bmanning@vacation.karoshi.com
wrote:
> some years back, i was part of a debate on the relative value of
> crypto - and it was pointed out that for some sectors, crypto
> ensured _failure_ simply because processing the bits introduced
> latency. for these sectors, speed was paramount.
>
> think HFT or any sort of "Flash Mob" event where you want in/out as
> quickly as possible.
The latency cost of a stream cipher implemented in hardware can be as
little as the time it takes a single XOR gate to operate -- which is
to say, low even by the standards of my friends who do high frequency
trading (many of whom do, in fact, claim to encrypt most of their
communications).
Certainly crypto is not the only (or even most important) way to make
systems secure. In breaking in to a system, implementation bugs are
where you look, not cracking cipher keys. However, latency qua
latency seems like a poor reason to avoid encrypting your traffic. It
might, of course, be a reason to avoid certain architectural
decisions in how you use the crypto -- a public key operation per
packet would clearly add unacceptable latency in many
applications.
Perry
--
Perry E. Metzger perry@piermont.com
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
