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
--
http://mail.python.org/mailman/listinfo/python-list
