lightweight encryption of text file

Anthra Norell anthra.norell at bluewin.ch
Tue Jan 12 23:38:31 CET 2010


Robert Kern wrote:
> 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 unchallenged.
>
>> 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 p3.py 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,
   let's stop this nonsense. If you don't, I certainly will. You take me 
to the task for intentions you invent for the purpose, like claiming 
this or that. I don't claim anything, least of all the supremacy of my 
proposal. The idea of it! If someone else makes a better proposal I'd be 
the idiot you crave to make me look if I denied the fact. This is an 
interest group, not a religion with a clergy devoted to keeping heresies 
at bay. In my perception of an interest group, everyone's contribution 
is welcome and the common benefit results from the discussions of those 
contributions, absolutely none of which comes with a warranty, as 
absolutely no poster deems himself infallible and no OP expects it. Your 
accusation I was abusing the confidence of an OP by representing a sham 
as the ultimate solution is so utterly ludicrous that I can let it pass 
and that concludes the matter as far as I am concerned.

Frederic




More information about the Python-list mailing list