baseConvert() & 32-bit ops

[Dar Scott]

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.

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

(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