At 06:13 PM 3/9/2006 +0000, Ben Laurie wrote:
Steven M. Bellovin wrote:
> On Thu, 09 Mar 2006 02:10:58 -0500
> [EMAIL PROTECTED] wrote:
>
>> This is very useful for encrypting things like video
>> streams without an expensive hardware cryptographic accelerator card.
>>
> I think you vastly overestimate how much hardware one needs to do
> something like AES. I ran
>
> dd if=/dev/zero bs=32k count=1024| openssl speed aes-128-cbc
I presume you were expecting this to test encrypting a long stream of
data. It doesn't. "openssl speed" does encryption internally - the stuff
on stdin was ignored. Something like:
dd if=/dev/zero bs=32k count=1024 | openssl enc -aes-128-cbc > /dev/null
is probably what you want (untested).
You have to be careful. I meant in regards to the incremental overhead of
the cipher once the cleartext is loaded from DRAM into L1 cache. And
the cleartext data is constantly streaming in enough to cause the L1 cache
to be refreshed constantly during the timing test. Of course if the Vernam
cipher's pad is constantly loading in too, then it's DRAM overhead must
be counted against it. The best ones tend to place as much of the
original random material as possible in L1 and randomly remix the pads
inside. It's very tricky, balancing speed against the decay rate of the cipher
(and countering things like partial key attacks).
- Alex
--
- Alex Alten
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
