On Friday, June 20, 2003, at 02:12 PM, Dar Scott wrote:
In many cases you will not need to know whether Revolution uses string numerals or an internal form of the number.
The above test two and three will put numeral strings into the arrays. If you find that the encryption box is more efficient with internal numbers in the array, then put (zap+0) into myList[i]. As you use the numbers and replace them with calculated values, they will become and stay the faster internal form. Unless you do some weird magic, the key is always a numeral.
Like:
repeat with eip = 1 to 16
xL = bitXor( xL, myP2array[eip] )
----------- hexF
a = bitAnd( bitAnd( xL, -16777216 ) / 16777216, 255 ) + 1
etc...
The guy that thought this S-box, bit-shift stuff up has got to be a full-blown max-zoomed dweeb. It messes with your mind just to visualize the path taken by 8 characters split in half, shifted back and forth through four S-boxes and shifted at each level based on the cypher key at each change.
This gives me some things I can test for platform differences and speed tests
-- put (zap+0) into myList[i] --- I will test this for optimization
All results are strings once they get to the message box. The property numberFormat is used to convert. Your numbers are hardly affected. The quote marks will not show up on strings unless you put them in the strings.
-- nice to know this. I'll check out the property numberFormat. There might be some stuff there that helps.
Because the Blowfish S-boxes have only 256 entries, you might see if using numToChar(i) as the key gives you any speed advantage. Also, since Blowfish uses 32-bit numbers, you might consider extracting four char sets using a char chunk expression from a string instead of an array and then use binaryEncode/binaryDecode.
Dar Scott
I'm definitely interested in binaryEncode/binaryDecode for many parts of this in Rev. My own hex-converter loop is a real dog; I'm sure I'll discover some speed improvements there. I was reading about it last night.
The bit shifting process with bitXOr is fine for the S-boxes, however there is always more than one way to skin a cat. I can't imagine doing bit-shifting in a numerical environment that had a consideration for charToNum/numToChar S-boxes. Interesting idea. The 64 bit block cypher broken into two 32 bit halves and sent left and right does work best as a char chunk expression from a string instead of an array. The text being encrypted is never placed into an array except while 64 bits are hashed based on the key. This idea to binaryEncode before encrypt wouldn't work as the block cypher works on 1 char at a time in 8 char chunks at a time. There is definitely a need to binaryEncode before placing encrypted text into a field object.
I was wondering if a binaryEncoded variable can be compressed and saved to the hard drive using Rev? Can it then be opened, decompressed, and binaryDecoded back into a variable?
Using numToChar:
you might see if using numToChar(i) as the key gives you any speed advantage.
It won't. It would even break the inventor's prerequisite advise to make the algorithm easier to implement. On the other hand it will extend the available number of unique keys that can exist in a key set; by using charToNum() to set 64 bit and 128 bit keys with more choices for keys. ... charToNum(204)
Thank you for your input on these arrays. I definitely have some experiments to work on, thanks to you.
Mark
