lightweight encryption of text file

[Anthra Norell]

Robert Kern wrote:
> On 2010-01-11 14:09 PM, Anthra Norell wrote:
>> Robert Kern wrote:
>>> On 2010-01-09 03:52 AM, Anthra Norell wrote:
>
>>>> "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!"
>
> You are probably remembering James Stroud's post, but it came in 
> response to your challenge.
>
> http://www.opensubscriber.com/message/python-list@python.org/1393006.html
>
>>>> 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.
>
> So, you're saying that you lied about the encryption algorithm used in 
> your challenge. USENET has no (or very few) formal rules for you to 
> breach, but lying certainly isn't ethical behavior. Honestly, it's 
> okay to not be a good cryptographer. I'm not. But it is very much not 
> okay to be a liar.
>
I am not a bad cryptographer. I am not a cryptographer. A liar? Your 
judgment is evidence of a commendable broad-mindedness that complements 
computer science with psychology, even ethics, as fields of interest. If 
I may suggest, take your fields of interest other than computer science 
to the more responsive audiences of respective interest groups. You may 
try www.justrage.com for a starter. Also find some reference reading at 
http://www.cnn.com/2008/TECH/11/03/angry.internet/index.html and at 
http://www.recovery-man.com/abusive/rage_vs_anger.htm. On my part I 
would offer you this quote by...I forget whom: You can't sling mud 
without soiling yourself. And if you sling at someone out of range, 
you're the only one getting dirty.
      Isn't it unfortunate that Robert Kern the ethicist takes the stage 
with a contribution totally irrelevant on this forum, let alone to the 
OP's question, and thus crowds out Robert Kern the cryptographer who 
could comment on a much more relevant matter, namely my--possibly rash, 
so what?--conjecture that any brute-force key-guessing attack can be 
foiled by stacking a number of encryptions sufficient to keep the 
fastest super computer busy until the sun goes out five billion years 
from now. It doesn't take all that many. The way I understand it the 
encoding time, the keyed decoding time and the size of the key data grow 
linearly with the number of encryption levels, whereas the 
brute-force-decoding time grows exponentially. Right?
      I finally would point out that my proposals have always been 
attempts to solve the posted problem, no less, no more. I therefore 
consider any criticism to miss the point if it judges the proposal by 
criteria that transcend the posted problem. You'll recall that the 
problem is now, and was then, a simple encryption scheme for private 
use. Private use excludes malicious attacks and so immunity against them 
is not an applicable quality criterion.

Regards

Frederic