Robert Kern wrote:
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
My dear Robert. Thank you for the clarification. You are right. The
thread recorded by Google doesn't mention the credit card detail. I
remember it distinctly, though. I also remember that it wasn't my idea.
And I recall being urged by another, well-mannered, member of this group
to call it off right away. He wrote--I pretty much quote: "...there must
be a number of machines out there grinding away at your code right
now!"
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.
You're right about the thieves. You have a point about my algorithm,
although you might express it in a fashion that lives up to its merits.
My algorithm would not resist a brute-force attack that iterates through
all possible keys and analyzes the outcome for non-randomness. I knew
that then and so I posted a second-level encryption, that is, an
encryption of an encryption. Thus the brute-force attack wouldn't find
anything non-random. By not disclosing the detail I may have breached
some formal rule of the craft. If I had disclosed it, I have my doubts
that the processing power available at a sensible cost would have done
the job. The keys I said I used were long integers. There are roughly
4.3 billion of them. Cycling through all of them would surely take a
considerable number of hours on a PC. If each one of the 4.3 billion
top-level decryptions required another bottom-level run many hours long,
the chances of cracking the code before dying of old age are very, very,
very remote.
I may be wrong about that. If you know better, your knowledge
would serve the community a lot better than your ill temper.
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?
"""
Excellent point!
Why EVER make anything yourself when you can buy it?
Another excellent point!
Cheers
Frederic
--
http://mail.python.org/mailman/listinfo/python-list
