Re: Notes... The case for an open client

> Prior to the start of RC5-72, there was some internal discussion about
> ignoring the mangling requirements and simply incrementing natively, 
> but it
> was decided to instead stay with standard RC5 mangling that had been 
> done in
> RC5-56 and RC5-64 rather than introduce any possible problems.  There 
> had
> been timings done of the performance difference gained by removing the 
> extra
> mangle/unmangle operations, and it turned out to be relatively trivial 
> (less
> than a few percent in keyrate, I think).  Although speed improvements 
> here
> and there are always good, picking the safety of past implementation
> prevailed.

This way, we can keep the first few S-boxes dependant on L[0] and L[1] 
(I think). The 1/256 of the time that it overflows will always be a 
problem, then be too much (though you could increment key.mid by 0x100 
and check for an overflow, which would save you the 1/65536 and 1/16M 
chance that other bytes overflow).

...

> In any case, changing the incrementing of the "high" bits much above 
> 32-bits
> would not really be possible without (effectively) discarding all of 
> the
> work that had already been done.

Of course, since this is (currently) done by proxies, it's not the 
biggest deal in the world (and 1/2^32 of the time is quite small).

- Purr

_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware