Simple encryption proposal. Comments ?

[Bengt Richter]

On 30 Dec 2002 07:13:02 -0800, Paul Rubin <phr-n2002b at NOSPAMnightsong.com> wrote:

>"Thomas Weholt" <2002 at weholt.org> writes:
>> Hm .... are you saying I'm better off using rotor? My first attempts used
>> rotor, but storing rotor-encrypted data in values of HTTP-cookies didn't
>> work very good, since cookie-values must  be in the
>> string.lowercase+string.uppercase+'0123456789'-range ( in addition to the
>> normal ,.-_ etc. characters ). Rotor produced alot of unprintable data. If I
>> didn't mess it up somewhere that is.
>
>- Don't use rotor; it is not secure.
>
>- Also, don't use SmartCookie, since it uses pickling and malicious
>incoming cookies can potentially take over your server.
>
>- Just about any encryption scheme is going to result in unprintable
>  characters that you'll then have to encode printably.  I'm not sure
>  whether base64 characters are all permissible in cookies.  I think
>  they are.  Otherwise you may have to find some substitutions.

Re encoding (not encrypting) binary, I've used a base52 encoding to guarantee
only [A-Za-z] characters in the encoded string, so it can't screw up in a
context where they might become symbols or shouldn't possibly look like bad
numbers. One or a pair of binary bytes becomes 3 base52 characters.
Because 52**3 > 2**17:
 >>> 52**3, 2**17
 (140608, 131072)
there is room for two bytes plus a flag bit to say whether there's really
two bytes encoded. It's a 50% expansion from clear, but it's simple and
doesn't have to buffer more than two characters to produce the output.
It preserves byte order of a byte sequence, so endianness should be dealt
with separately, if using with something that gets bytes from chunks.

Regards,
Bengt Richter