[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
	 > 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.