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':
>
> [fetchin...@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
--
http://mail.python.org/mailman/listinfo/python-list
