[1141] in cryptography@c2.net mail archive
Re: Better DES challenge update
daemon@ATHENA.MIT.EDU (Dave Emery)
Wed Jul 2 15:01:44 1997
From: Dave Emery <die@pig.die.com>
In-Reply-To: <y8a67uudvag.fsf@horten.artcom.de> from "Andreas Bogk" at "Jul 2, 97 04:47:51 am"
To: andreas@artcom.de (Andreas Bogk)
Date: Wed, 2 Jul 1997 00:40:57 -0400 (EDT)
Cc: die@die.com, eli@gs160.sp.cs.cmu.edu, cryptography@c2.net,
crisp@netcom.com
Reply-To: die@die.com
Andreas Bogk wrote :
> >>>>> "Dave" == Dave Emery <die@pig.die.com> writes:
>
> Dave> card with little added support overhead. Most previous
> Dave> proposals presumed that additional tests would be done in
> Dave> software past the initial trial decryption of 8 bytes - this
> Dave> would require a lot of chip to chip communications and all
> Dave> the baggage in the form of wide busses and fast interchip
> Dave> communications that this would entail.
>
> In the classic DES case, false hits won't happen very often. If you
> target ATM machines, where you know only part of the plaintext (the
> PIN), such additional tests on-chip were neccessary, of course.
Not sure what the classic DES case really is. A real world
working DES decryptor would almost certainly see a lot unknown plaintext
or incompletely known plaintext to chew on. Certainly a major example
of this (as others have pointed out) is otherwise unknown ASCII text
with the upper parity bits either all 0 or all 1 or all even or odd
parity on the byte. But there are other obvious examples, such as less
than 8 byte long strings at known offsets in a message (such as
compression algorithm headers) or partially known strings with several
variable bytes (like time/date headers where the exact time might not be know
due to clock skews). Some of these specify enough bits so the false
hit rate would be very low, but others - such as the very important ASCII
text case - generate hits as often as once every 256 keys tried.
A real world machine would want the most flexible hit testing
architecture possible.
Dave
