lightweight encryption of text file
anthra.norell at bluewin.ch
Mon Jan 11 21:09:43 CET 2010
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':
>> > [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.
>> 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:
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
>> 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,
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?
Why EVER make anything yourself when you can buy it?
Another excellent point!
More information about the Python-list