baseConvert() & 32-bit ops

[Mark Brownell]

On Sunday, June 22, 2003, at 10:44  PM, Dar Scott wrote:

>
> On Sunday, June 22, 2003, at 10:07 PM, Mark Brownell wrote:
>
>>     f = S1[a] + S2[b]
>>     f = bitXor( f , S3[c] )
>>     f = bitAnd( f + S4[d], -1 )
>
> 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.)


> So your F function could be just 3 lines, then: the binaryEncode, the 
> binaryDecode and the above 3 combined in the return.
>
> function F halfBlock
>    put binaryEncode(...
>    put binaryDecode(...
>    return ( (  ((S1[a] + S2[b]) mod 2^32) bitXor S3[c]  ) + S4[d] ) 
> mod 2^32
> end F
>
> Dar Scott

> put binaryEncode("N",xLprime) into fourChars
>
> This is the inverse of what you did for creating half blocks and you 
> will also do this in converting from blocks to a string.

I was hoping there was an inverse process like this.

>
> 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. 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. It will be nice to test this for speed 
once I have added these optimizations.

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?

Later,
Mark