baseConvert() & 32-bit ops

[Dar Scott]

On Monday, June 23, 2003, at 12:36 AM, Mark Brownell wrote:

>> There are a couple problems, I think the same functionality is the 
>> cause though.
>
> From TD:  the largest long integer allowed by the current operating 
> system. (On most operating systems, this is 2^32, or 4,294,967,296.)

Less one.

Where did you find this?  I didn't find anything in the dictionary 
entries on the limits of numbers for bitAnd, bitNot, bitXor and bitOr.  
And I didn't see what would happen when the limits are exceeded 
(nearest valid).

It would be nice if this was extended a few more bits, say to 48 bits 
instead of 32.  That might mean simply substituting an unsigned 64-bit 
integer for an unsigned 32-bit integer if all applicable compilers have 
it.

> I wonder if a hard coded button script is faster than a broken out 
> version using function calls like for function F and similar parts of 
> P & S-box regeneration? When this is done there will be both examples 
> for implementation. then I will know. I wonder if there will be anyone 
> interested in using this?

Unless you are passing large arrays or strings many times, there is 
little overhead for the call.  But you are right, eventually you might 
want to try embedding functions and the F function is one that is 
repeated often.  Don't worry about P & S box generation.  In Blowfish 
you do that once per key.  And it will use the basic block encipher & 
decipher with F, so concentrate on those 3 functions.

>> You can pick out the codes for each of those chars with 
>> 'charToNum(char 1 of fourChars)', but this might work, too:
>>
>> put binaryDecode("CCCC",fourChars,a,b,c,d) into numConverted
>> -- either ignore numConverted or check that it is 4
>
> I'll try out things until I get these working. This could speed things 
> up quite a bit.

Don't forget, those are my versions that don't add one.  If you take 
out the +1 here, you might need to in the box building, also.

> I was using all the assembly loops and long math equations in the 
> Lingo version, Director 7 on Mac X; OS 9.2 where the processor is 
> running at about 240 megahertz. That would encrypt about 40 kbts of 
> text per second. My experience is that some things in Rev are much 
> faster than Director.

Revolution will not compete with well written assembly language code.  
(Or do you mean building up the blocks?)  However, the built-in 
compress will be fast and also will shorten the data to be encrypted.  
It might be your #1 speed enhancer.  (And it probably improves the 
security of block ciphers unless it uses 64-bit blocks, too.)  And if 
you need the final product in base64, Revolution is fast there.  I 
suspect your bottle neck might be S-box lookup, but perhaps array 
lookup with numerical keys is faster than I think.

Dar Scott