[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What price security?



Phil Karn <karn@qualcomm.com> writes:

> Alex,
> 
> >5 to 7 uS per 100 bytes v.s about 15 uS per 100 bytes.  Unfortunately
> >the key setup is more expensive, about 200 uS v.s. 80 uS.  For lots of 
> >short messages which require different keys it is slower than D3DES.  
> 
> The key setup in my code is slower because I never optimized the key
> scheduling code. I wasn't out to crack keys, and I figured that it was
> better anyway to handle the multiple key case by just creating each
> key schedule once and passing the appropriate one to the encrypt and
> decrypt routines. That's faster than continually calling even the
> fastest key scheduling function...

> Phil

This is one place where the work that went into the DES cracking 
effort can be applied. With a little one-time, startup work, you 
can generate key schedules much faster than Phil's code.

If you study the way DES sets up key schedules, you'll find that each
bit in the subkeys mirrors the setting of one bit in the original key. 
To generate key schedules quickly, at startup time I generated 56 key
schedules using Phil's routine, each for a key with one bit set. 

To generate the key schedule for an arbitrary key, I had only to OR
together the schedules corrosponding to set bits in the key. This is
much faster than the canonical method.

The breakeven point is somewhere around 60 keys - if your app will 
use >60 keys during it's run, you win with this method. You could 
lower the breakeven point by putting the 1-bit schedules into a 
header file, instead of calculating them at startup time.

[This is NOT a criticism of Phil - he had no reason to
 optimize this part of the system.]

Peter Trei
trei@process.com 



Follow-Ups: