Encryption with Python

[Peter Hansen]

I wouldn't call the above an "encryption" function -- it looks
to be nothing more than a substitution cipher. (I don't know how "cnt"
is determined, but translate will, for any given invocation, return the
same output character for any repeat occurrences of the input. A good
encryption algorithm should not do that -- ideally, "bookkeeper" will
encrypt with no repeated characters in the oo, kk, ee*e positions)

Kamilche *did* state clearly that it was "not secure, but it should
be enough to ward off casual hacking".

Also, if we're both using the same version of English, a substitution
cipher is still encryption, just a weak form.

See http://en.wikipedia.org/wiki/Cipher and related links, which point
out that even DES can be considered "from a sufficiently abstract
perspective", a substitution cipher on an enormously large binary
alphabet. ;-)

-Peter

 

[Dennis Lee Bieber]

Kamilche *did* state clearly that it was "not secure, but it should
be enough to ward off casual hacking".

About to the level of the old "CryptoGrams" puzzles some
newspapers run (though they usually give you one starting substitution
-- but in a long missive, that type of hint may not be needed).

It would be a slow implementation in Python, but one
"improvement" I'd consider (since it looks like there are already
multiple tables): Using just a..z0..9 (ignoring case and punctuation
characters) would be to create 36 substitution tables, then use the
output of one character substitution as the index to the table for the
next character's translation.

This would avoid the "bookkeeper" type input from giving hints
in the output. The reverse (decryption) gets a tad more difficult.

--

 

[Peter Hansen]

About to the level of the old "CryptoGrams" puzzles some
newspapers run (though they usually give you one starting substitution
-- but in a long missive, that type of hint may not be needed).

It would be a slow implementation in Python, but one
"improvement" I'd consider (since it looks like there are already
multiple tables): Using just a..z0..9 (ignoring case and punctuation
characters) would be to create 36 substitution tables, then use the
output of one character substitution as the index to the table for the
next character's translation.

This would avoid the "bookkeeper" type input from giving hints
in the output. The reverse (decryption) gets a tad more difficult.

But why would anyone want to improve the security of this approach?
If one wants casual obscurification(tm), it does just fine as-is.
If one wants real security, one would be insane to use anything
less than Blowfish, 3DES, AES and their ilk...

-Peter

 

[Paul Rubin]

If you are happy xoring then there is an even faster method: use
numarray. For me xoring a numarray.array is twice as fast as
string.translate is on the corresponding string for UInt8 arrays and
four times as fast for UInt64 arrays. (But adding the two conversions
between strings and numarrays makes the two methods comparable).

If you can use numarray, there's a pretty good chance that you could
instead use pycrypt or pyaes or some other C extension that does real
encryption. The idea of encrypting in pure python is you don't always
have the opportunity to use external modules like pycrypt or numarray.