On Sunday, June 22, 2003, at 03:54 PM, Dar Scott wrote:
On Sunday, June 22, 2003, at 03:48 PM, Mark Brownell wrote:
If I used zeros to pad then I can strip them based on the number of chars in the original, a function may be used to strip these extra characters from the end of the string. For binary data I have read that the length of the data should be encrypted in a header, so that padding characters can be safely removed without accidentally destroying valid 0's at the end of the data stream.
Both should work. I don't know what is common practice.
If you need to pad and unpad binary, you can use that for text also. You can make the block size an optional parameter, but keep the default 8 bytes (8 chars).
If you learn that decompress() will always handle certain kinds of extraneous chars at the end--I'm too lazy to check the spec and test the idea, myself--then you don't have to worry about the size preservation in padding and unpadding; just pad with a safe char. You can combine the functions and call them prep() and unprep() or something.
Dar,
I'm thinking just do it at the end of each encrypt or decrypt process, before any save process. I'll run tests on all these things. How better is there a way to learn.
I'm interested in learning more about binary distribution techniques. If I compress the encrypted ascii text with Revolution's compress feature from a variable will it end up being corrupted like it does placing it into a field object and then saving that field as plain text. I haven't found anything that suggests what to do with I/O in the TD.
Save your files as binary. The easiest way is using URL (see TD), but you can do this with open-write-close, too.
Save like this (sorta):
makeBlowfishEnvironment blowfishKey
put blowfishEncrypt(pad(compress(myData))) into URL "binfile:my data.bf"
Get it back like this:
makeBlowfishEnvironment blowfishKey
put decompress(unpad(blowfishDecrypt(URL "binfile:my data.bf"))) into myData
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.
(I'm not suggesting that your basic blowfish functions/commands be as in the above example. That was just a way to illustrate how easy it is to handle this data in Revolution. Personally, I would make makeBlowfishEnv() a function that returns a string (say five lines, one for each box) and then use that as a parameter to my encrypt and decrypt functions which set up local vars from that parameter as needed when working or, alternately, to a setBlowfishEnv command. This way I would be able to cache several box-sets.)
Dar Scott
This is interesting. I purposely created a handler as a button click with all the parts hard coded inside the on mouseUp / end mouseUp. I did this because I wanted to not use any global variables or OOPs function calls. I did this to try to cover any trace or ram detection that might be easier to detect while the application is running. I'm so new to Transcript and Rev that I'm not sure how OOPs works. I should drop back and learn how this all goes together. Anyway this idea to break out different variants of encrypt and decrypt sequences into different uses could be an easy to create addition.
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
Mark
