OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: RE: IRC & Host Masks...
From: Heyman, Michael (Michael_HeymanNAI.com)
Date: Mon Aug 21 2000 - 10:01:32 CDT

>
> "Heyman, Michael" wrote:
> >
> > > From: ANTGamezaol.com [mailto:ANTGamezaol.com]
> > > [SNIP]
> > > The problem with the current format is while it is always
> > > the same, it is easily crackable, ( A simple XOR with the ip)
> > > also, SHA tends to be very processor intensive...
> > >
> > SHA-1 block is 64 bytes or 55 bytes for the last one due to
> > padding. I believe that most of the time one SHA-1 block should
> > be enough.
> >
> > 100 per minute --> 100 SHA-1 64 byte blocks
> >
> > 1133 cycles per block (optimized C on 450MHz Celeron)
> > See www.eskimo.com/~weidai/benchmarks.html
> > (Wei Dai's Crypto++ benchmarks)
> >
> > 225000 clock cycles needed per minute.
> > Approx 2x leeway given for CPU cache misses
> > - and ease of math :-)
> >
> > 450000000 clock cycles available
> >
> > 225000/450000000 = .0005 = .05%.
> >
> > This is 100 times less cpu then you have allocated assuming a
> > 450MHz Celeron. If bad caching delays don't happen, you use
> > half the cpu. If you have a big-endian processor, SHA-1 is
> > faster. If you use assembly, you can get 10% faster. If you
> > use non-optimized C code, you will run at half speed, but
> > with such an excess of CPU, it really doesn't matter.
>
> To take a real test, OpenSSL's SHA-1 implementation on my
> not-so-fast P2 can do 8545.26 kB/s on 64 byte blocks, which
> is 133519.6875 blocks per sec, 8011181.25 blocks per min, so
> 100 per min is .001% of CPU (hmmm ...one of us has slipped a
> zero or 2 somewhere).
>
Oops, I was doing 100/second. What I meant to say was .0008% CPU :-)

And I learn yet again, it is always a good idea to check wacky theoretical
results with actual results.

-Michael Heyman