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