lightweight encryption of text file

Robert Kern robert.kern at
Tue Jan 12 17:09:33 CET 2010

On 2010-01-12 05:59 AM, Anthra Norell wrote:
> 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:

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

Yes, being ethical is an interest of mine. It should be yours, too.

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

This is uncontroversial. It is one reason why the DES algorithm was repeated 
thrice to make the algorithm 3DES. However, it is not especially relevant. The 
point is that you are claiming this group's nonresponse to your challenge as 
evidence that it is strong. What's more, it turns out that you lied about the 
algorithm you used in the challenge. That undermines your claim drastically. 
Since your claim is targeted at convincing the OP to choose your algorithm over 
other choices that are better in every way, refuting your claim is necessarily 
on-topic. I didn't want to discredit you by calling you a liar, but you exposed 
yourself as one.

However, brute force key searching isn't why we think your algorithm is weak (or 
rather, the low key size from your originally stated algorithm was one reason, 
but it was hardly the most striking reason). You are using a linear random 
number generator in a mode that is susceptible to a number of standard attacks. 
It fails to have a number of properties that are necessary in an encryption 
system. One can break your algorithm with less computation than is necessary for 
brute force search. Repeating the algorithm many times will not increase the 
time necessary to break your repeated algorithm exponentially.

It is important that the OP understands this, and that your claims do not go 

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

Encryption is *always* about preventing malicious attacks. If you had called 
your algorithm a "no-security obfuscation algorithm", I wouldn't have much 
problem with it (although a real encryption algorithm like is also 
strictly better for obfuscation, too). I do have a problem with people claiming 
"unbreakable encryption" when it has been demonstrated to be false.

Words have meanings, and your words claim far too much. It's possible that you 
do not mean to claim so much, but you would then need to change your language. 
The reason that this is so important is that the OP necessarily cannot give you 
all of the information about his use case in a short post to comp.lang.python. 
How do you know that he won't be subject to malicious attacks? You cannot make 
this judgment for him. But you can describe your algorithm correctly. Calling an 
algorithm an "unbroken encryption algorithm" (let's ignore your claim of 
"unbreakable" for now) means a whole bunch of things, the most important of 
which is that attacks on the algorithm don't take less time than searching the 
entire key space.

If the OP uses a real encryption algorithm, he can rely on the fact that he can 
use the algorithm for large files or for plaintexts that a malicious agent might 
choose even if he did not communicate (or even know about!) those needs at the 
time. He cannot rely on those features with your algorithm, but you do not 
reveal those limitations of your algorithm. You simply assumed that the OP could 
deal with those limitations, and that does him a disservice.

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

More information about the Python-list mailing list