baseConvert() & 32-bit ops

[Mark Brownell]

On Monday, June 23, 2003, at 07:40  AM, Dar Scott wrote:

>
> 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).
>

check -- the format function; TD; description; 
format(baseString[,valuesList])

> 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.

It still uses some of this optimization in the first regeneration of 
the P=box. I'm trying to tweak every speed enhancement into this thing. 
There are going to be some long winded authors out there that want to 
publish and encrypt their version of War & Peace.

>
>>> 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.

That will be easy to test for, The + 1 and the - 1 are in regards to 
one of the 256 positions  in the S-boxes. I'm starting to talk like a 
max zoomed dweeb...

>
>> 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

Yes, I did mean building up the blocks, and more than 500 other 
iterations before character transformation is completed. I'm used to 
tweaking Director, where doing things in arrays (Lists) is the fastest 
way to do things. In a modular version I can test for process oriented 
speed advantages.

Thanks Dar,

Mark