lightweight encryption of text file

[Anthra Norell]

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.
>>
>> 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