baseConvert() & 32-bit ops

[Dar Scott]

On Sunday, June 22, 2003, at 06:55 PM, Mark Brownell wrote:

>> You can handle these files (or send the data) as you would any binary 
>> data.  If you need printable ASCII of binary files or strings, then 
>> run them through base64 (see TD).  If you need to store encrypted 
>> data in stacks, consider custom properties.
>
> What about conversion to hex (base^16) and then saving it as a text 
> file? This seems like an excelant cross-platform technique for sharing 
> my encrypted files.

You can.  base64Encode is also portable and will handle line breaks and 
all.  It uses Revolution internal line ends, so you might need a way to 
convert.

However, Just about every OS can handle a binary file of n bytes.  I'd 
go with that.

As long as you do the encrypting and decrypting, you should have to 
worry about compression and padding.

>
> Here is another possible optimization point.
> What can you and Rev do with this:
>
> xL = 0
> xL = bitXor( xL, bfP2[i] ) -- bfP2[i] = 608135816
>   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
>
> let me guess :
> put binaryDecode("N", bitXor( xL, 608135816 ),a,b,c,d) into 
> numConverted
> or
> put binaryDecode("N", bitXor( xL, 608135816 ),d,c,b,a) into 
> numConverted

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

...so I'll concentrate on that and skip the xor and call the value I'm 
working on xL'.  This might not be exactly the above, but it is 
probably what you intended.  For example, I don't add the 1; arrays can 
start at 0.

First you need to take a view of your number as a 32-bit number and 
convert it to a binary string.  Something like this (off the top of my 
head):

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.

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 could have the order backwards.  (Check the TD.)

Either of those create numbers.

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

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


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)

Dar Scott