Poor man's encrypted data

[Richard Gaskin]

Dave Cragg wrote:

> At 9:46 am -0800 5/4/03, Richard Gaskin wrote:
>> Dave Cragg wrote:
>> 
>>> At 8:21 am -0800 5/4/03, Richard Gaskin wrote:
>>>> For sending data across the net in a semi-secure format, can you think of
>>>> any downsides to simply storing the data in custom props in a
>>>> password-protected stack?
>>> 
>>> One possible downside is that, although the contents of the custom
>>> props will be encrypted, if someone is able to get the entire stack
>>> data, then with a copy of Rev/Metacard (the starter kit will do) you
>>> can still "get" the custom props. (Password-protecting only denies
>>> access to the scripts.)
>> 
>> It was my successful test that prompted my post: with the MC 2.4.3 engine it
>> seems custom props are also encrypted.
> 
> The custom props are encrypted when you view the file data, but if
> you open the stack with Rev or Metacard, you can still "get" a custom
> property without setting the passkey.

It should be easy for Scott to lock that custom prop access along with
script editing.

In the meantime, I just wrote these two simple handlers to tuck sizable data
into a script by just making sure it only occupies one line:

on SuckUp
  answer file "Select a file:"
  if it is empty then exit to top
  put url ("binfile:"&it) into s
  put compress(s) into s
  -- Convert to ASCII:
  put base64encode(s) into s
  -- Remove returns:
  replace cr with "<RETURN_PLACEHOLDER>" in s
  set the script of fld 1 to s
end SuckUp

on SpitOut
  ask file "Name new file:"
  if it is empty then exit to top
  put the script of fld 1 into s
  replace "<RETURN_PLACEHOLDER>" with cr in s
  put base64decode(s) into s
  put decompress(s) into s
  set the filetype to "MSIEWAFF"
  put s into url ("binfile:"&it)
end SpitOut

The filetype is only a convenience for my testing -- I used an MSIE page
archive as it has a nice mix of ASCII and binary data, and I have several
lying around that are a few hundred k.

Interestingly, MC's limit of 64k per line only seems to affect fields, but
not the script property itself.  I just ran this on a 142k file and it
worked great.  The base64 adds some overhead to the file size, but at least
withu any control chars its very save for transport.  Conceivably, one could
use this to store up to 10 files per script with the scriptlimits at play.

So with that out of the way, we're back to the original question:  for what
uses would a hard-to-break but not military-grade encryption be acceptable?

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc