[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Security Last Call Initial Questions
smb@research.att.com says:
> I'm afraid it's a simple matter of arithmetic.
>
> Let's look at Joe Touch's performance numbers. He got DES speeds
> ranging from 20-37 Mbps. To make the arithmetic easy, let's just sa
y
> 32 Mbps. At 64 bits per block, that's .5 M encryptions/second, or 2
> microseconds per encryption.
But Steve, isn't this bulk-rate encryption speed? I.e. key setup
is done once, and then you pipe your data in as fast as you can?
While during cryptanalysis you must perform a new key setup with
every encryption (thus slowing down considerably)?
Any numbers on how many key schedule setups per second can one do?
I tried accounting for this with my factor of five between the bulk encryption
rate and the trial rate, but there's no substitute for real numbers.
So -- I tried some tests on ... well, let's call it a stream cipher
that I picked up off the net, a cipher that's very fast, but has a
relatively slow key setup time. I changed it to use a macro instead of
a subroutine to swap bytes. The machine was a SPARCserver 1000 running
Solaris 2.4; the compiler was gcc with the -O option specified.
Key setup time was 200 microseconds. That's rather higher (well, a
factor of 20 higher) than I'd guessed, but I suspect that
hand-optimized assembler would do better. For that matter, my driver
isn't optimized even at the C level. Even so, at worst we're talking
about less than a month to crack this 40-bit cipher.
Btw -- if you need incentive to work on this, check out
http://www.c3.lanl.gov/~mcn/watcher.html, a pointer to which was widely
posted yesterday. I'm not sure I'll dare log in from Danvers if I
can't get encryption deployed between now and next week; I'm quite sure
I wouldn't dare do it a month from now.
Follow-Ups: