Cryptography-Digest Digest #959, Volume #8       Mon, 25 Jan 99 03:13:03 EST

Contents:
  Re: 3DES in EDE mode versus EEE mode (Scott Fluhrer)
  Re: [req]:Cryptanalysis tool - word pattern table ("Douglas A. Gwyn")
  Re: interview (JPeschel)
  Re: Pentium III... (Robert Yoder)
  a decyption task ([EMAIL PROTECTED])
  Re: Cryptanalysis of Simple Block Ciphers ("almis")
  Re: REQ: Info about any SSH client for Macintosh (Brandner01)
  Re: Who will win in AES contest ?? (Serge Vaudenay)

----------------------------------------------------------------------------

From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: 3DES in EDE mode versus EEE mode
Date: Mon, 25 Jan 1999 02:25:31 GMT

In article <78fo4c$2ni$[EMAIL PROTECTED]>,
        [EMAIL PROTECTED] wrote:
>In article <78e2l6$[EMAIL PROTECTED]>,
>  Scott Fluhrer <[EMAIL PROTECTED]> wrote:
>> In article <78dta9$sef$[EMAIL PROTECTED]>,
>>      [EMAIL PROTECTED] wrote:
>>
>> >
>> >You are correct -- however *if* the attacker knows it is a one-key 3-DES that
>> >can be attacked as a 1-DES.
>>
>>Actually, if he just suspects that it might be 1-DES, he'll try it.  After all,
>>since the work effort against 1-DES is so much smaller (2**56 times smaller),
>>it's absolutely insignificant against the work effort required for 3-DES.

>"If he suspects" is not granted if the cipher was negotiated as 3-DES by both
>sides -- even though both sides may use just one-key for speed, switching over
>to 1-DES loops instead of doing EDE in a brain-dead way...
What do you mean "not granted"?  Do you mean that the attacker isn't *allowed*
to check for low-probability events that would allow him to crack the cipher
quickly?  Do you think that weak keys cannot be exploited by an attacker,
because he cannot be certain that it is being used, and is "not granted" the
ability to check?  After all, that's one way of looking at DES: as weak key of
3-DES.

>Besides, if the attacker does a whole 1-DES attack he probably would not be
>able to efficiently use intermmediate results to brute-force two-key DES for
>example -- the attacker would have to start all over again. And, the same for
>three-key DES.
So?  Even if he has the throw everything away, there's still a time savings
for checking 1-DES first [1]

>However, if the cipher was offered either as 3-DES or 1-DES by Alice and Bob
>accepted it as 1-DES then there is no question -- attack it as 1-DES.
>Otherwise, you just have to formulate the question as a "decision problem" --
>and ask whether the cost of "miss" (not being 1-DES) outweighs the savings of
>a "hit" (it is 1-DES) *if* the cipher is two-key 3-DES or a three-key 3-DES.
Exactly.  Lets take a look at the costs assuming:

  - There is a 0.000001 probability that 1-DES is being used, otherwise, 3-DES
    is being used

  - 1-DES takes an expected 2**55/N microseconds to break, if it is a 1-DES
    message, and 2**56/N microseconds to check for, if the message is not a
    1-DES message       (where N is the number of DES chips the attacker has)

  - 3-DES takes an expected 2**111/N microseconds to break, and is always
    successful (the message is 3-DES, even if it is also 1-DES)

Then, checking for 1-DES first takes an expected:

   0.000001 * (2**55)/N + 0.999999 * ( (2**56)/N + (2**111)/N )    microseconds

   = 2.5961458e+33 / N microseconds, which is less than the 3-DES only time:

   (2**111)/N = 2.596144e+33 / N microseconds

(not by a lot, but that's because I made the probability of 1-DES so small).

And, checking 1-DES first gives a higher probability of the attacker getting
the encryption very early in the attack cycle.  Helps a lot if the attacker
has fewer than 8e+19 DES chips, and would see the see the message in less
than a year.



[1] Actually, when you look at the standard attack on 3-DES, it looks like
    you can check for 1-DES efficiently after decrypting the ciphertext
    using all possible 1-DES keys, and sticking them in your memory device.
    This is besides the point I'm trying to make above

-- 
poncho


------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: [req]:Cryptanalysis tool - word pattern table
Date: Mon, 25 Jan 1999 03:41:19 GMT

"����" wrote:
> It would list, for example, a pattern such as "ABACD" and then every
> word in the English lang which fit that pattern (for the above example:
> "every" fits).
> Does anyone know where such a table can be obtained?

One doesn't want a list of *every* pattern, just those of likely
words.  A good pattern table is in Military Cryptanalytics, Part I
Volume 2, Appendix 3.

------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: interview
Date: 25 Jan 1999 05:22:43 GMT

>Mok-Kong Shen <[EMAIL PROTECTED]>writes something like:

 Terry Ritter [a fellow American down on his luck] wrote:
>> 
>> On 19 Jan 1999 02:58:23 GMT, in
>> <[EMAIL PROTECTED]>, in sci.crypt
>> [EMAIL PROTECTED] (JPeschel) [that's me!] wrote:
>> 
>> >Phred Dobbs <[EMAIL PROTECTED]>, after coming back with bags of gold
>dust,
>> >writes:
>> >
>> >9) Do you require any licensing for your job?
>> >
>> >Licensing?  We dont need no stinkin' licensing!
>> 
>> That's true.
>> 
>> Unless, of course, we offer ourselves for hire to the public as an
>> "Engineer," in which case a license is required.
>
>If I understood correctly, there was, however, once an opinion by
>a professional to the effect that one should acquire sort of a 
>'license' from the profis before one publishes anything (unless one 
>is already a profi, of course.)

Mok, are you back to whining about your silly arguments with
Bruce? Why not sit back, grab a beer, and watch "The Treasure of
Sierra Madre," instead?

Joe




__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------

From: Robert Yoder <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Sun, 24 Jan 1999 19:43:42 -0700

Matthew Skala wrote:
> 
> In article <[EMAIL PROTECTED]>, Robert Yoder  <[EMAIL PROTECTED]> wrote:
> >I suspect that the CPU ID was driven by large commerical software
> >vendors who wanted a way to node-lock their licenses, and Intel is
> >trying cover the whole thing with a sugar-coating and convince the
> >consumers that this is good for us.
> 
> It's good for me.  I want to build large parallel processors; if each CPU
> has its own ID number, that may make it easier for then to talk to each
> other without interferance.  I don't really need it, I can get the same
> functionality in other ways, but it has a small nonzero dollar value.

Now I don't have any experience with multi-CPU Intel machines,
but I _DO_ have experience with multi-CPU SPARC machines, and
in that environment, every CPU has it's own ID based on _WHERE_
it is plugged in, and not on a CPU-specific hard-coded number.
e.g.

$ psrinfo -v
Status of processor 0 as of: 01/24/99 19:27:11
  Processor has been on-line since 01/15/99 16:57:08.
  The sparc processor operates at 248 MHz,
        and has a sparc floating point processor.
Status of processor 1 as of: 01/24/99 19:27:11
  Processor has been on-line since 01/15/99 16:57:12.
  The sparc processor operates at 248 MHz,
        and has a sparc floating point processor.
Status of processor 4 as of: 01/24/99 19:27:11
  Processor has been on-line since 01/15/99 16:57:12.
  The sparc processor operates at 248 MHz,
        and has a sparc floating point processor.
Status of processor 5 as of: 01/24/99 19:27:11
  Processor has been on-line since 01/15/99 16:57:12.
  The sparc processor operates at 248 MHz,
        and has a sparc floating point processor.
$ 

In this machine, (E6000), board slots 0 and 2 contain CPU/memory boards,
and each board hold 2 CPU's.  Surely an Intel machine can do something
equivalent w/o hard-coding a number into the CPU.

> I'm not afraid of it being used to identify me - ethernet cards, PC cases,
> and hard drives all have serial numbers on them already anyway. The CPU ID
> is less threatening because nobody's going to be able to read my CPU ID
> number without first being able to execute programs on my machine.  If
> someone is so stupid as to use my CPU ID (or more properly, what my
> machine *claims* is its CPU ID) for network security, then I can have some
> real fun.

But in the case of MAC-addresses, we haven't had a huge corporation
trying to tell us, (with a straight face), that the MAC address can
be used for user authentification.  Sun has had a "hostid" embedded
in a MB chip for ages which is used for s/w licensing, and HP has
had a similar feature for years, but neither of them have ever tried
to tell us this could be used for user authentication.  (And if you
look around the net you can find a s/w program that will circumvent
the Sun hostid.)

I don't have any _FEAR_ of the CPU-ID "feature";  I just resent having
my intelligence insulted by Intel lying to tell us about what it can
be used for.  And since I don't use third-rate proprietary OS's, I
have no worry that my CPU-ID could ever be transmitted w/o my
knowing. 


ry
-- 
[EMAIL PROTECTED]
"Unix:  The Solution to the W2K Problem."

------------------------------

From: [EMAIL PROTECTED]
Subject: a decyption task
Date: Mon, 25 Jan 1999 05:40:50 GMT

Hi. I need this statement decypted, but, alas, I do not know where to begin.
If I could get your help, I'd be very grateful.

"Kjg; kdbk ,a; iodakdh oakjdo da;gpt nft ktrglu x,dokt pdkkdo; sl kjd H.soav
vdtnsaohe Od;daoij kjd H.soav vdtnsaoh alh dbrpagl ,jgij tsf ,sfph ijs;d gy
tsf ,dod pdaolglu ks ktrd yso kjd ygo;k kgmde"

Thanks!!!!!
Kelly

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: "almis" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis of Simple Block Ciphers
Date: Mon, 25 Jan 1999 00:16:08 -0600

You might try using vector equations for each block.
Arrange the vectors into a matrix.
If you can determine a 'ranks' worth of solutions
the vector space can be determined.

 ...al

James Pate Williams, Jr. wrote in message
<78d1hk$4id$[EMAIL PROTECTED]>...
|I am using a genetic algorithm (steady-state uniform crossover
<etc.>
|



------------------------------

From: [EMAIL PROTECTED] (Brandner01)
Subject: Re: REQ: Info about any SSH client for Macintosh
Date: 25 Jan 1999 06:32:11 GMT

Hi Jim,

"BetterTelnet" by Rolf Braun in principle supports ssh.  Pls. take a look at
http://www.cstone.net/~rbraun/mac/telnet/faq.html - in particular Section 4.

Greetings,
Wolfgang

------------------------------

From: [EMAIL PROTECTED] (Serge Vaudenay)
Subject: Re: Who will win in AES contest ??
Date: 25 Jan 1999 08:01:47 GMT

In article <[EMAIL PROTECTED]>, Paul Crowley 
<[EMAIL PROTECTED]> writes:
|> this came out.)
|> 
|> My eyes hurt, so I'm not going to try and summarise the results on the 
|> CAESER or Brian Gladman pages; I encourage you to go and look.

Check http://www.dmi.ens.fr/~vaudenay/dfc.html as well.
you can find many documents about DFC and links to AES-related sites, for
instance http://www.dmi.ens.fr/~granboul/recherche/AES.html where many tests
have been performed.

One information which does not seem very popular is that DFC is still the
fastest AES candidate on 64-bit microprocessors (much less than 300 cycles
for one block encryption on EV6 which will run at 1GHz). It is the fastest
on Alpha and TurboSparc. On Alpha EV56, there is a 1.5 speed ratio between
DFC and the fastest AES candidates on 32-bit microprocessors (namely, RC6,
Rijndael, Twofish). When the AES will be adopted, rare 32-bit microprocessors
will survive. People says DFC has not enough rounds, which is why it is
faster. Then increase it from 8 to 12 rounds, and it will be as fast as the
popular ones!

Serge

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to