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