lightweight encryption of text file

[Robert Kern]

On 2010-01-09 03:52 AM, Anthra Norell wrote:
> Daniel Fetchinson wrote:
>  > I have a plain text file which I would like to protect in a very
>  > simple minded, yet for my purposes sufficient, way. I'd like to
>  > encrypt/convert it into a binary file in such a way that possession of
>  > a password allows anyone to convert it back into the original text
>  > file while not possessing the password one would only see the
>  > following with the standard linux utility 'file':
>  >
>  > [fetchinson at fetch ~]$ file encrypted.data
>  > encrypted.data: data
>  >
>  > and the effort required to convert the file back to the original text
>  > file without the password would be equivalent to guessing the
>  > password.
>  >
>  > I'm fully aware of the security implications of this loose
>  > specification, but for my purposes this would be a good solution.
>  >
>  > What would be the simplest way to achieve this using preferably stock
>  > python without 3rd party modules? If a not too complex 3rd part
>  > module made it really simple that would be acceptable too.
>
> Daniel,
>
> Here's what looks like another thread veering off into package-ology,
> leaving a stumped OP behind.
>
> "Don't use a random generator for encryption purposes!" warns the
> manual, of which fact I was reminded in no uncertain terms on this forum
> a few years ago when I proposed the following little routine in response
> to a post very similar to yours. One critic challenged me to encode my
> credit card data and post it. Which I did.

Actually, you just "encrypted" your credit card number and challenged 
comp.lang.python to crack it. No one challenged you to do anything of the sort. 
Fortunately, the ever-watchful eye of Google was upon us that day:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/5fb9ffada975bae9?pli=1

> Upon which another critic
> conjured up the horror vision of gigahertzes hacking my pathetic little
> effort to pieces as I was reading his message. Of the well-meaning kind,
> he urged me to put an immediate stop to this foolishness. I didn't.
>
> No unplanned expenditures ensued.

That's because comp.lang.python is not full of thieves, not because your 
algorithm is worth a damn.

p3.py imposes no more overhead than this, but it has some real security 
properties. To quote Paul Rubin from that previous thread:

"""
Since good encryption schemes that don't have significant performance
penalties are widely available, why mess with a crap scheme EVER?  Why
use a solution that "might or might not be adequate" when you can use
one that's definitely ok?
"""

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco