baseConvert() & 32-bit ops

[Mark Brownell]

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

> The last four lines look like the first steps of the F function in 
> your Feistel network (more, crypto jargon, folks, not that I speak > it):
>
>>   a = bitAnd( bitAnd( xL, -16777216 ) / 16777216, 255 ) + 1
>>   b = ( bitAnd( xL, 16711680 ) / 65536 ) + 1
>>   c = ( bitAnd( xL, 65280 ) / 256 ) + 1
>>   d = bitAnd( xL, 255 ) + 1

     f = S1[a] + S2[b]
     f = bitXor( f , S3[c] )
     f = bitAnd( f + S4[d], -1 )

     That's right. Could have fooled me.

> I think, when you use those as S-box lookup, those will become 
> numerals (strings) of those numbers to become keys when you access the 
> array.  So, should you be adventuresome, why not use a single char 
> (think byte) as the key and skip some work?  (Make sure the 
> caseSensitive property is true if you try this.)  If you do this, use 
> "aaaa" instead of "CCCC".

   -- a = 155
   -- b = 124
   -- c = 234
   -- d = 75

>
> (Are you sure about -16777216 in your code?  It will act like 0 in 
> bitAnd.)

correct again, it must have acted like zero + 1

-- a = 1 in Transcript test
-- a = 115 in Lingo test

>>   put ( xL bitAnd -16777216 ) / 16777216 into zap
>
> 4278190080 not -16777216.
>
> (Soap box diatribe about our C heritage deleted.)
>
> Dar Scott

put ( xL bitAnd 4278190080 ) / 16777216 into zap
a = 115 in Transcript test now.

> As far as organizing your code, I'd put all the blowfish functions and 
> local variables you are working on in the stack script.  I'd use a 
> common prefix on names so you can cut and paste this code anywhere (or 
> use this stack as a library, once you are comfortable with that).  I'd 
> put common testing scripts in the card script.  These might know about 
> card objects such as fields.  I'd have button scripts call the others. 
>  When you are done, you will have a nice Blowfish script in the stack 
> script.  You can even use the whole stack as a library.
>
> It looks as though your model code of Blowfish integrated the F 
> function into the double half-block encrypt/decrypt.  To make your 
> code easier to follow as you are tinkering with it, I'd break it out 
> as a separate F function until you are happy with that; it should take 
> a number representing a half block and return a number.  (pp337-338, 
> pp647-648, Schneier)

I have a separate F function broken out already. I just got done hard 
coding it into a button click. I took all the external functions and 
coded them lineally and repetitiously where ever they occur.

Mark