Cryptography-Digest Digest #804, Volume #11      Wed, 17 May 00 23:13:00 EDT

Contents:
  Re: Quake Encryption ([EMAIL PROTECTED])
  Re: Theoretical question (Bryan Olson)
  Re: Chosen plaintext attack, isn't it absurd? (Joe Durusau)
  Encrypting random data (Darren New)
  Re: Interesting differentials in BREAKME (Raphael Phan)
  Re: Quake Encryption (Thomas Luzat)
  Re: Interesting differentials in BREAKME (Tom St Denis)
  Re: Definition of "Broken" Cipher (Tom St Denis)
  Re: Encrypting random data (zapzing)
  Re: Fixed the stream cipher "Slime"? (Tom St Denis)
  Re: Encrypting random data (Tom St Denis)
  Re: Crypto & UNICODE??? (John Savard)
  Is H() a NP problem (Tom St Denis)

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

From: [EMAIL PROTECTED]
Subject: Re: Quake Encryption
Date: Wed, 17 May 2000 23:21:23 GMT

In article <[EMAIL PROTECTED]>,
  Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> "Donald R. McGregor" wrote:
>
> > A student is attempting to reverse-engineer the Quake III protocol.
> >
> > It seems that the data in UDP packets it sends out is encrypted.
> > Anyone have any ideas about the scheme used? I figure it can't
> > be that complex, since they can't spend a lot of CPU or time
> > decoding the data, which is sent out at framerate.
>
> And you yourself don't have ANY pointer to that (which appears not
> to be very popular)? Thanks.

Some packet analysis shows that, after a few initial probe packets
and a packet with some client machine configuration data in
it that is sent back to idsoft, the server does a simple plaintext
challenge-response. The server generates a plaintext integer,
sends it to the cient, and the client just echoes it back.
This logs the client into the server.

After this the client sends a packet to the server. The server
responds with an aprox. 1300 byte packet of binary data. This
is almost certainly key material. if the client just sends replay
data from an old session to the server the server will continue
to respond with 1300 byte key material packets. Different key
material is sent with every game started.

Probably the client does something really simple like XOR the
data in the packets with the key material. I can't see them
spending the CPU cycles to do something crypto-secure for
something so time-sensitive.

So if you had the plaintext you could probably puzzle out the
scheme used--work from the plaintext to the crypto text,
deduce the XOR pattern, and try to figure out what part of
the key material sent was being used for the XOR. New key
material is never or infrequently sent. Basically a small
OTP that is massively reused.

Don McGregor





Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Theoretical question
Date: Thu, 18 May 2000 00:21:03 GMT

Mok-Kong wrote:
[...]
> Or, as I
> asked, is ANY arbitrary function mapping from a given domain
> to a given codomain eligible to be a candidate in the present
> context?

Yes.  If the given domain is m and codomain is n, then
a random function is a selection such that each of the
|n|^|m| distinct m->n functions is choosen with
probability |n|^-|m|.

--Bryan
--
email: bolson at certicom dot com


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Joe Durusau <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack, isn't it absurd?
Date: Wed, 17 May 2000 20:48:44 -0400

        The classic example of a known-plaintext attack 
(in the military anyway) is to drop a few mortar rounds near that
enemy transmitter.  Then notice that he sends a message to someone 
further behind the lines almost immediately, and that the party 
to which he sent the message can be counted on the send messages
to several other stations, differing only slightly in length.

        If you know the enemy doctrine (and you are expected to
know it), you have a really good idea about the text of each of
the messages.  You knowledge of the plaintext will not be prefect,
but it will be pretty good, particularly if you try this several
nights in a row, and compare the results.

Speaking only for myself,

Joe Durusau


Manuel Pancorbo wrote:
> 
> I mean, if the attacker is able to access the encipher machinery (but not
> the actual key) and then test the ciphertexts she wants, what stops her to
> access the DEcipher machinery?
> 
> I posted here some months ago a question about the security of an algorithm
> with involution property, that is cryptosystem where encryption =
> decryption:
> Ek(Ek(m)) = m
> 
> If the above argument is really silly (counterarguments, please) I will
> quickly understand why involution algorithms are weak!
> 
> --
> ____________________________________________________________________________
> _________
> 
>  Manuel Pancorbo
>  [EMAIL PROTECTED]
>  "...
>    Más vale aprender una sola línea de Ciencia
>    que postrarse cien veces en oración. (Corán)
> 
>    Pli valoras lerni ech nur unu linion de Scienco
>    ol preghe genui cent fojojn. (Korano)
>  ..."
> ____________________________________________________________________________
> _________

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

From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Encrypting random data
Date: Thu, 18 May 2000 00:59:34 GMT

Just a thought...

Say one has a hardware RNG generating truely random numbers (as opposed to
PRNs). If this hardware is on one machine, and you want to use the random
numbers on a different machine, would it suffice to encrypt the random pad
with a stream cypher like (say) RC4, then send the numbers? Is there any way
to break such, assuming the RC4 key was distributed securely? 

If that pad is then decrypted and used as a OTP, is it noticably harder to
break the resulting encrypted message than to break the RC4 encryption?

Just wondering. :-) TIA!

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.
"I can't believe the whole diswasher is full, and no chopsticks."


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

Date: Thu, 18 May 2000 09:21:42 +0800
From: Raphael Phan <[EMAIL PROTECTED]>
Subject: Re: Interesting differentials in BREAKME

This is a multi-part message in MIME format.
==============6D96ADFC3E6166B5DCF733A8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Tom St Denis wrote:

> He made it with sboxgen, but I doubt you can really make secure 8x4
> sboxes anyways.  I think he told me the max differential was 32/256
> which is 1/8, which is what you found in the round function right?

I thought the probability of 1/8 was due to the fact that 0x65 -> 0x0 had an
entry of 2
in the difference distribution table corresponding to a probability of 2/16
= 1/8?

--

" Contentment is not the fulfilment of what you want, it is the
 realization of how much you already have.  "

"   When you were born, you cried and the world rejoiced.
  Live your life in such a manner that when you die,
         the world cries and You rejoice...          "


==============6D96ADFC3E6166B5DCF733A8
Content-Type: text/plain; charset=us-ascii;
 name="breakme.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="breakme.txt"

  0 : 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
  1 : 0 2 0 2 4 0 0 0 2 2 0 2 0 2 0 0 
  2 : 0 0 2 0 0 2 4 0 0 0 0 0 2 0 6 0 
  3 : 0 2 0 0 0 2 2 2 2 0 2 0 0 2 0 2 
  4 : 0 4 2 2 0 0 4 0 2 0 0 0 2 0 0 0 
  5 : 0 2 4 0 0 4 0 2 0 2 2 0 0 0 0 0 
  6 : 4 0 0 0 2 0 2 0 0 0 2 0 0 2 0 4 
  7 : 0 0 0 0 4 0 0 4 0 2 0 4 2 0 0 0 
  8 : 2 0 4 0 0 4 0 2 2 0 2 0 0 0 0 0 
  9 : 0 8 0 4 0 0 0 0 0 0 2 0 0 0 0 2 
 10 : 2 0 0 0 2 0 2 2 0 2 0 2 2 0 2 0 
 11 : 0 0 0 2 2 0 0 4 0 0 0 0 0 6 0 2 
 12 : 2 0 0 4 2 0 4 0 0 0 2 2 0 0 0 0 
 13 : 2 0 4 2 0 0 0 4 0 0 0 2 0 2 0 0 
 14 : 0 0 0 0 2 4 2 0 4 0 2 0 0 2 0 0 
 15 : 0 4 0 0 0 4 0 0 0 0 0 2 4 0 2 0 
 16 : 0 0 1 4 1 1 0 0 1 1 2 1 1 0 2 1 
 17 : 0 0 2 2 1 0 0 2 1 2 1 2 0 1 1 1 
 18 : 0 1 2 0 3 0 1 0 1 1 0 1 1 4 0 1 
 19 : 0 1 0 0 2 5 0 1 1 1 0 1 1 0 0 3 
 20 : 2 2 3 0 1 0 0 1 2 2 0 1 0 0 0 2 
 21 : 0 2 0 0 1 0 2 0 2 1 3 0 1 0 1 3 
 22 : 1 1 1 0 1 2 0 3 0 1 1 1 1 0 1 2 
 23 : 0 0 0 2 2 0 1 2 4 2 0 0 0 1 1 1 
 24 : 0 2 3 1 2 0 1 0 1 1 2 2 1 0 0 0 
 25 : 1 0 1 2 0 1 0 0 0 2 1 1 2 1 1 3 
 26 : 0 0 1 0 4 2 0 0 0 1 3 1 0 0 2 2 
 27 : 1 0 1 2 0 2 0 3 0 1 1 0 1 2 2 0 
 28 : 3 0 1 0 0 2 0 1 0 3 1 0 0 1 3 1 
 29 : 1 2 1 2 0 0 0 1 3 2 1 0 1 0 1 1 
 30 : 0 0 4 1 1 0 1 4 1 1 0 1 0 0 1 1 
 31 : 0 0 1 1 0 0 3 0 1 1 1 1 1 0 1 5 
 32 : 1 1 0 1 0 1 1 0 0 4 1 1 1 3 1 0 
 33 : 2 2 2 0 3 2 0 0 1 0 0 0 1 0 2 1 
 34 : 2 0 0 4 0 2 0 3 1 0 1 1 0 0 1 1 
 35 : 1 1 1 2 1 0 1 0 1 0 2 1 1 0 3 1 
 36 : 1 1 0 0 0 4 0 1 1 0 0 2 2 2 1 1 
 37 : 1 1 1 3 2 0 0 1 2 0 1 0 2 1 0 1 
 38 : 1 1 1 2 0 0 1 1 0 1 1 4 1 1 0 1 
 39 : 0 1 4 0 2 2 2 0 1 0 1 0 0 1 1 1 
 40 : 0 1 0 3 1 2 1 1 0 0 0 1 0 1 3 2 
 41 : 1 1 1 1 0 0 2 1 1 0 1 1 0 2 3 1 
 42 : 2 1 2 1 0 1 0 0 1 2 1 1 0 2 1 1 
 43 : 3 1 0 1 3 0 2 1 1 1 1 1 0 0 1 0 
 44 : 1 0 2 2 0 2 0 2 1 2 0 1 1 0 0 2 
 45 : 0 0 1 0 3 1 2 0 0 0 1 1 1 2 1 3 
 46 : 0 2 1 2 2 4 0 0 0 2 0 0 2 1 0 0 
 47 : 2 2 1 0 1 1 0 0 4 0 1 1 2 1 0 0 
 48 : 0 0 0 2 3 1 0 1 1 0 0 4 1 1 2 0 
 49 : 1 0 2 3 0 0 1 2 1 0 1 1 3 0 0 1 
 50 : 1 0 2 0 0 1 1 0 0 2 2 2 0 3 1 1 
 51 : 0 0 2 0 2 0 1 0 1 2 2 0 1 3 2 0 
 52 : 1 1 2 1 0 3 0 1 0 3 0 1 0 1 0 2 
 53 : 1 1 2 0 2 0 1 0 0 0 2 1 1 2 2 1 
 54 : 1 2 0 1 1 1 0 3 1 0 0 4 0 1 0 1 
 55 : 0 0 0 0 0 1 0 0 4 0 3 0 4 0 0 4 
 56 : 0 1 1 3 1 0 1 0 0 4 1 1 0 1 1 1 
 57 : 1 2 1 0 1 1 2 1 0 0 2 1 1 1 1 1 
 58 : 0 1 0 0 0 1 0 3 2 0 1 3 2 1 0 2 
 59 : 1 0 0 3 0 1 0 0 2 1 3 1 2 0 1 1 
 60 : 1 2 1 0 0 1 0 2 1 0 0 2 1 1 1 3 
 61 : 2 1 0 2 1 0 2 1 3 0 1 0 2 0 0 1 
 62 : 2 0 1 0 0 0 1 1 0 3 0 1 0 2 3 2 
 63 : 0 0 3 0 0 1 1 0 2 1 3 0 0 1 2 2 
 64 : 0 0 3 0 1 1 1 0 1 2 0 1 1 3 0 2 
 65 : 3 0 0 1 1 0 3 0 0 0 2 1 3 0 1 1 
 66 : 0 1 0 2 0 0 0 1 3 0 0 1 1 2 3 2 
 67 : 1 0 0 0 3 2 0 0 0 0 6 0 2 1 1 0 
 68 : 0 1 1 1 0 2 0 1 0 1 1 0 1 2 4 1 
 69 : 3 0 1 1 1 1 0 1 1 1 3 1 2 0 0 0 
 70 : 1 1 1 0 1 0 0 0 4 2 0 2 0 2 0 2 
 71 : 0 0 0 0 1 1 4 0 1 1 2 1 3 2 0 0 
 72 : 1 2 0 1 0 1 0 3 0 2 1 0 0 3 1 1 
 73 : 0 0 0 3 0 1 1 1 2 1 1 0 2 1 3 0 
 74 : 0 1 0 0 0 1 0 2 0 0 0 6 0 3 1 2 
 75 : 2 0 2 0 0 0 1 1 1 2 0 0 1 1 2 3 
 76 : 1 2 1 0 1 0 1 0 2 1 1 3 0 2 0 1 
 77 : 1 0 1 1 1 1 2 1 1 0 1 0 1 0 1 4 
 78 : 0 0 0 0 0 0 1 5 1 1 1 2 1 2 1 1 
 79 : 0 1 1 1 0 1 0 0 2 4 2 0 1 0 3 0 
 80 : 1 0 0 0 3 2 0 1 1 1 2 1 1 1 2 0 
 81 : 1 1 1 2 0 1 0 1 2 0 1 2 2 1 1 0 
 82 : 2 0 4 1 1 2 1 0 0 0 3 0 1 0 0 1 
 83 : 0 0 0 0 1 1 3 0 1 1 0 2 1 3 2 1 
 84 : 1 1 3 0 0 1 1 0 1 2 1 1 3 1 0 0 
 85 : 0 1 2 1 1 0 1 1 2 2 1 1 0 2 1 0 
 86 : 2 0 1 1 3 0 0 2 1 2 0 1 2 0 1 0 
 87 : 1 2 1 0 0 1 0 2 3 0 1 0 2 3 0 0 
 88 : 1 2 2 1 1 0 1 1 1 1 1 1 1 1 0 1 
 89 : 0 1 0 0 1 1 1 1 2 2 0 1 0 1 2 3 
 90 : 0 1 1 0 0 2 1 4 1 1 2 0 1 0 0 2 
 91 : 1 1 0 3 0 0 1 1 0 1 2 2 1 2 1 0 
 92 : 0 1 0 0 0 1 1 2 1 3 2 1 1 1 1 1 
 93 : 2 0 0 3 1 1 2 0 1 1 1 0 0 2 1 1 
 94 : 1 1 1 1 2 1 1 1 0 2 0 0 2 1 1 1 
 95 : 1 0 0 0 1 3 2 0 4 0 0 1 0 1 0 3 
 96 : 1 3 1 2 2 0 1 1 1 0 0 2 0 1 0 1 
 97 : 2 0 0 2 0 0 2 1 3 1 1 1 2 0 0 1 
 98 : 1 1 0 1 0 3 3 0 0 1 1 1 1 1 0 2 
 99 : 1 2 1 0 1 1 1 0 0 1 0 1 1 1 5 0 
100 : 2 1 1 1 1 0 1 0 0 2 4 1 1 1 0 0 
101 : 2 4 1 0 2 1 0 1 2 1 0 0 0 0 1 1 
102 : 0 1 1 1 4 0 1 1 0 0 0 1 2 1 2 1 
103 : 0 0 1 1 0 0 2 3 1 0 3 0 3 0 0 2 
104 : 1 1 0 0 0 0 3 2 0 2 2 2 2 0 0 1 
105 : 0 2 4 1 1 1 0 2 1 0 0 0 1 0 3 0 
106 : 1 2 1 0 4 1 0 0 1 0 0 1 0 1 1 3 
107 : 1 1 0 0 2 0 2 1 0 1 2 1 5 0 0 0 
108 : 2 2 2 2 1 0 0 2 0 0 0 2 0 1 1 1 
109 : 1 0 0 3 0 2 0 1 1 1 2 2 1 0 1 1 
110 : 1 0 1 3 0 1 4 1 0 2 0 1 2 0 0 0 
111 : 0 1 1 0 0 1 0 2 1 0 1 2 0 3 3 1 
112 : 2 1 2 2 0 0 0 1 0 2 1 1 1 0 2 1 
113 : 0 0 3 1 1 0 1 2 0 0 1 2 0 1 0 4 
114 : 1 0 0 0 1 2 1 3 1 0 1 0 0 3 3 0 
115 : 0 2 1 2 3 3 1 0 1 1 0 0 2 0 0 0 
116 : 1 2 0 0 0 1 1 1 3 1 1 1 0 0 2 2 
117 : 1 0 1 3 2 1 2 0 0 1 1 0 1 0 2 1 
118 : 1 1 1 1 2 2 2 0 0 1 0 0 1 0 1 3 
119 : 2 1 2 0 2 1 1 1 2 1 1 0 0 1 0 1 
120 : 1 1 1 2 1 2 0 0 1 1 1 1 2 1 1 0 
121 : 3 1 0 2 1 1 0 0 3 0 2 0 0 1 1 1 
122 : 1 0 3 1 1 3 1 0 0 1 1 0 1 1 0 2 
123 : 0 1 1 0 4 1 2 1 0 1 1 1 0 1 2 0 
124 : 0 0 2 1 1 2 0 0 1 3 0 0 2 3 0 1 
125 : 1 4 2 0 1 0 1 1 1 2 0 1 1 0 1 0 
126 : 0 0 1 5 1 1 0 4 1 1 0 1 0 0 1 0 
127 : 0 1 2 1 0 2 0 2 1 0 1 1 1 1 1 2 
128 : 2 0 2 1 0 1 0 1 1 4 2 0 0 1 0 1 
129 : 2 0 2 2 2 0 1 0 0 2 1 1 1 2 0 0 
130 : 1 0 0 0 1 3 1 1 2 2 0 1 2 0 2 0 
131 : 1 3 0 0 0 1 0 2 2 0 2 0 3 1 1 0 
132 : 0 2 0 0 1 3 1 0 2 0 1 1 1 2 1 1 
133 : 2 2 0 1 0 3 0 1 0 1 1 1 3 0 1 0 
134 : 1 0 2 1 2 1 1 1 2 1 0 1 0 0 1 2 
135 : 1 0 1 1 1 0 1 0 0 2 1 2 1 2 1 2 
136 : 0 0 2 1 0 0 0 2 1 0 3 1 2 2 1 1 
137 : 1 2 1 2 0 1 3 1 2 1 1 0 0 0 1 0 
138 : 1 1 2 0 3 0 0 0 0 1 0 1 1 4 2 0 
139 : 0 0 0 1 3 1 1 1 2 2 1 0 0 1 0 3 
140 : 2 1 0 0 3 0 1 0 0 0 1 2 0 3 0 3 
141 : 1 0 1 1 2 2 1 1 1 3 0 1 0 0 1 1 
142 : 0 2 1 1 0 3 1 1 0 0 3 1 1 1 1 0 
143 : 0 1 1 1 0 0 1 1 3 1 0 1 1 1 3 1 
144 : 1 0 1 1 1 1 2 2 1 1 0 0 1 4 0 0 
145 : 0 3 1 2 1 2 0 0 1 1 0 1 2 0 2 0 
146 : 2 1 0 3 1 2 2 0 0 1 1 1 1 0 0 1 
147 : 0 1 0 0 1 1 1 1 3 0 1 2 1 1 2 1 
148 : 3 3 0 0 1 2 2 0 0 0 0 1 1 0 2 1 
149 : 0 0 2 1 3 1 0 0 2 2 2 0 1 1 1 0 
150 : 0 0 3 1 0 1 1 1 1 1 2 3 0 1 0 1 
151 : 0 1 1 1 1 0 2 3 1 0 3 0 1 0 2 0 
152 : 1 0 3 2 0 0 1 0 2 0 0 3 0 1 0 3 
153 : 0 1 2 3 0 0 3 2 0 0 0 1 1 0 3 0 
154 : 0 1 0 0 0 2 3 1 1 3 1 1 1 0 1 1 
155 : 2 2 0 1 1 2 0 1 1 1 1 1 0 1 2 0 
156 : 0 1 1 3 1 2 0 1 0 4 1 1 0 0 0 1 
157 : 1 3 1 0 0 1 2 1 0 0 2 0 0 1 3 1 
158 : 2 0 1 1 1 1 1 2 0 3 0 0 0 1 0 3 
159 : 0 1 1 1 1 1 1 1 4 0 0 2 2 1 0 0 
160 : 0 0 1 3 2 1 3 0 1 0 1 1 1 1 1 0 
161 : 1 1 3 1 0 1 0 1 2 0 1 0 0 3 1 1 
162 : 1 0 1 2 1 0 0 1 2 0 1 0 1 3 1 2 
163 : 1 1 0 2 1 1 1 1 0 0 0 3 1 1 2 1 
164 : 1 1 3 0 1 1 1 2 1 0 1 0 2 1 0 1 
165 : 0 1 0 1 2 1 2 1 0 2 1 2 2 0 1 0 
166 : 0 2 1 0 2 0 1 0 1 3 1 1 4 0 0 0 
167 : 1 1 4 0 1 1 0 0 2 1 0 0 2 3 0 0 
168 : 0 1 2 3 1 0 0 1 1 3 1 0 2 0 1 0 
169 : 3 1 0 0 0 1 0 5 0 1 2 0 1 1 0 1 
170 : 1 1 2 0 1 0 2 3 0 0 3 0 1 0 0 2 
171 : 0 0 2 1 0 0 1 0 0 3 0 1 1 0 4 3 
172 : 1 0 0 1 2 4 1 1 2 0 1 0 0 1 1 1 
173 : 1 2 0 1 1 0 3 0 1 2 0 2 1 0 1 1 
174 : 1 2 0 2 0 0 3 0 1 1 0 2 2 1 1 0 
175 : 1 1 0 0 0 2 1 1 3 1 1 0 0 2 2 1 
176 : 2 1 4 0 0 0 0 0 0 0 1 0 1 0 5 2 
177 : 1 2 1 2 2 0 1 2 0 2 2 0 0 1 0 0 
178 : 2 1 0 0 3 0 0 1 1 0 0 2 4 1 1 0 
179 : 2 1 0 0 2 1 2 1 0 2 0 1 0 0 1 3 
180 : 2 2 1 1 1 0 2 2 1 0 0 1 0 2 0 1 
181 : 2 0 1 1 0 1 1 1 1 1 1 3 1 0 0 2 
182 : 1 1 2 1 1 1 2 0 1 0 0 2 0 1 2 1 
183 : 0 0 0 0 1 1 4 1 1 5 2 0 0 0 1 0 
184 : 0 0 2 1 1 2 0 1 1 0 1 3 2 2 0 0 
185 : 3 4 0 3 1 0 0 0 0 0 0 0 1 1 0 3 
186 : 0 2 0 0 2 1 0 0 1 2 2 1 1 1 3 0 
187 : 0 2 1 3 1 3 1 0 0 1 1 0 1 0 0 2 
188 : 0 2 2 1 3 3 0 0 1 0 2 0 0 1 1 0 
189 : 1 1 1 0 0 2 1 1 1 2 0 0 1 2 2 1 
190 : 0 0 0 0 2 1 3 3 2 0 1 3 1 0 0 0 
191 : 1 1 0 2 1 0 1 1 0 1 1 2 2 0 1 2 
192 : 1 2 1 2 2 3 0 2 0 1 0 0 1 1 0 0 
193 : 1 2 1 0 1 1 0 1 0 0 3 0 1 1 4 0 
194 : 1 2 3 1 0 0 0 2 1 0 0 3 1 0 1 1 
195 : 1 1 0 1 2 1 2 1 2 1 1 2 1 0 0 0 
196 : 1 0 2 2 2 1 0 1 0 0 1 1 1 2 0 2 
197 : 1 0 0 2 0 0 6 2 1 0 0 3 1 0 0 0 
198 : 0 2 1 2 2 1 2 1 1 1 2 0 0 0 1 0 
199 : 2 1 0 2 0 2 0 0 2 0 1 1 1 3 1 0 
200 : 3 2 0 0 1 1 2 0 0 1 0 1 1 2 0 2 
201 : 2 0 1 1 1 2 4 0 1 0 0 0 1 2 1 0 
202 : 0 0 0 2 0 1 1 3 1 2 1 1 1 0 1 2 
203 : 2 2 0 3 0 0 3 1 2 0 0 0 0 1 2 0 
204 : 1 1 1 1 0 2 2 3 1 1 1 0 1 0 0 1 
205 : 0 1 1 2 2 0 1 2 0 1 0 0 2 1 3 0 
206 : 1 2 1 0 2 1 1 1 0 1 0 2 1 1 1 1 
207 : 2 1 2 0 0 1 1 2 2 2 1 1 1 0 0 0 
208 : 1 0 0 2 1 0 3 2 2 1 0 0 3 0 0 1 
209 : 2 0 0 2 0 1 1 1 3 1 2 2 0 1 0 0 
210 : 1 1 0 1 0 0 0 0 2 2 2 1 0 2 3 1 
211 : 0 2 0 2 1 0 1 1 1 1 0 0 1 2 2 2 
212 : 0 0 2 1 0 1 1 2 1 0 5 1 0 0 1 1 
213 : 0 2 2 1 0 2 1 1 0 2 1 2 0 0 2 0 
214 : 2 0 0 0 0 0 1 0 2 2 0 0 5 3 0 1 
215 : 1 2 0 1 0 2 0 1 1 1 0 2 2 1 0 2 
216 : 2 1 1 0 3 1 1 0 1 4 1 0 0 0 1 0 
217 : 1 0 0 1 0 3 1 1 2 2 0 0 1 3 1 0 
218 : 2 0 1 1 0 0 1 2 1 0 0 1 1 0 4 2 
219 : 0 1 1 1 0 0 0 0 1 0 1 5 1 1 2 2 
220 : 1 1 2 0 2 1 1 1 3 0 3 0 0 0 0 1 
221 : 0 1 1 0 2 2 1 0 1 0 1 4 1 1 1 0 
222 : 1 2 2 0 1 0 1 0 1 1 1 0 1 1 2 2 
223 : 0 0 1 2 0 0 0 0 0 2 2 1 2 4 1 1 
224 : 3 0 0 0 0 0 3 1 2 2 1 1 1 0 2 0 
225 : 0 2 1 0 1 1 1 1 1 1 2 2 1 1 1 0 
226 : 1 1 1 0 1 1 1 1 2 0 1 1 2 2 1 0 
227 : 3 3 0 1 2 1 1 2 0 0 0 0 1 0 1 1 
228 : 0 0 1 0 1 1 1 1 3 0 1 4 0 1 1 1 
229 : 1 2 0 2 2 0 1 1 0 2 3 1 1 0 0 0 
230 : 3 2 1 0 0 2 2 1 0 1 0 0 1 1 1 1 
231 : 0 1 2 1 1 2 0 2 0 1 0 0 1 2 2 1 
232 : 1 1 1 1 1 1 1 0 1 1 1 4 0 2 0 0 
233 : 0 2 0 0 1 1 2 1 0 4 3 0 0 0 0 2 
234 : 2 0 1 1 1 2 2 0 0 0 0 1 0 1 2 3 
235 : 1 2 1 2 2 0 0 3 0 0 1 2 1 0 0 1 
236 : 4 0 0 1 1 2 1 0 2 0 0 2 2 1 0 0 
237 : 0 1 0 0 3 0 0 1 1 2 1 2 2 1 1 1 
238 : 1 1 2 2 1 2 2 0 0 0 1 0 0 3 1 0 
239 : 2 2 1 0 1 1 2 0 0 0 2 0 2 2 0 1 
240 : 1 1 0 1 2 1 0 1 1 1 1 0 2 0 2 2 
241 : 1 2 1 0 0 2 3 0 2 0 0 2 0 2 0 1 
242 : 2 2 0 2 0 1 0 0 0 1 3 0 2 1 2 0 
243 : 1 1 1 1 2 0 0 1 3 1 0 2 0 1 0 2 
244 : 0 2 1 1 1 1 0 3 1 0 1 0 1 1 0 3 
245 : 1 0 0 1 2 1 1 1 0 3 2 1 0 0 3 0 
246 : 0 3 2 1 0 1 0 0 2 1 2 1 1 1 0 1 
247 : 4 0 1 0 1 0 1 0 1 2 1 1 1 0 1 2 
248 : 0 1 2 0 3 1 0 2 1 1 1 0 4 0 0 0 
249 : 2 1 0 1 0 1 1 1 1 2 0 1 1 3 0 1 
250 : 0 2 3 0 0 1 1 0 1 1 1 2 3 1 0 0 
251 : 2 1 2 2 0 0 0 0 0 1 1 1 2 3 0 1 
252 : 0 0 1 1 2 2 1 2 1 1 2 0 0 1 0 2 
253 : 1 1 1 0 0 0 3 1 0 0 0 3 1 2 3 0 
254 : 1 1 0 2 0 0 1 2 0 2 4 0 0 1 1 1 
255 : 2 0 2 1 1 0 0 1 3 1 0 3 0 0 1 1 

==============6D96ADFC3E6166B5DCF733A8==


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

From: Thomas Luzat <[EMAIL PROTECTED]>
Subject: Re: Quake Encryption
Date: Thu, 18 May 2000 04:01:01 +0200
Reply-To: [EMAIL PROTECTED]

On Tue, 16 May 2000 17:55:09 GMT, [EMAIL PROTECTED] (Donald R.
McGregor) wrote:

>A student is attempting to reverse-engineer the Quake III protocol.
>
>It seems that the data in UDP packets it sends out is encrypted.
>Anyone have any ideas about the scheme used? I figure it can't
>be that complex, since they can't spend a lot of CPU or time
>decoding the data, which is sent out at framerate.

As Quake III runs on a 8 kb/s connection one would have to
decode/encrypt at most 16384 bytes per second (up+down). I don't think
this would take too much time and OTOH is Q3A _not_ one of the most
efficient games ever programmed.


Thomas

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Interesting differentials in BREAKME
Date: Thu, 18 May 2000 02:03:36 GMT

In article <[EMAIL PROTECTED]>,
  Raphael Phan <[EMAIL PROTECTED]> wrote:
> This is a multi-part message in MIME format.
> --------------6D96ADFC3E6166B5DCF733A8
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Hi,
>
> Tom St Denis wrote:
>
> > He made it with sboxgen, but I doubt you can really make secure 8x4
> > sboxes anyways.  I think he told me the max differential was 32/256
> > which is 1/8, which is what you found in the round function right?
>
> I thought the probability of 1/8 was due to the fact that 0x65 -> 0x0
had an
> entry of 2
> in the difference distribution table corresponding to a probability
of 2/16
> = 1/8?

the probability of a differential is measured over the input size, like
in DES a diff of '14' corresponds to 14/64 not 14/16.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken" Cipher
Date: Thu, 18 May 2000 02:06:50 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>, Paul Koning
> <[EMAIL PROTECTED]> wrote:
>
> >
> > Indeed, one of the arguments against *all* 64-bit blocksize ciphers
> > is that you need to rekey within 2^32 blocks, and that's rather fast
> > for modern high speed traffic...
> >
> >         paul
>
> It would stand to reason that having to rekey so frequently is a
weakness
> in itself, but I'm sure some are interested in placing some types of
> cipher weaknesses out of bounds so that certain ciphers get a longer
> ride.  Surely, I can do the same.  All ciphers have some unqualfied
> weakness; it surely is snake oil to prance about like this is not
true.

That's the bloody point of this thread!!!

What exactly is a broken cipher.  Obviously we have went in circles
over what we already know, finite machines are finite in their
complexity.

Whoopy-doo.  The argument at hand is when does a cipher become invalid
in it's role to sufficiently randomize the input.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Encrypting random data
Date: Thu, 18 May 2000 02:06:41 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> Just a thought...
>
> Say one has a hardware RNG generating truely random numbers (as
opposed to
> PRNs). If this hardware is on one machine, and you want to use the
random
> numbers on a different machine, would it suffice to encrypt the random
pad
> with a stream cypher like (say) RC4, then send the numbers? Is there
any way
> to break such, assuming the RC4 key was distributed securely?
>
> If that pad is then decrypted and used as a OTP, is it noticably
harder to
> break the resulting encrypted message than to break the RC4
encryption?
>
> Just wondering. :-) TIA!

Breaking the RC4 would give Eve the
OTP immediately, if Eve could listen
in on the two computers talking to
each other. But random numbers are
not time critical. You could write
them to a storage medium and
transport the medium by secure
courrier. Then again, the random
numbers may not need to be kept
secure, depending on what protocols
you plan to use.

let
H=hardware random numnbers
R=RC4 stream
P=plaintext
+ indicates xor

say eve got ahold of H+R and she also
got ahold of H+P then she could find
R+P=(H+R) + (H+P)
Then the effort would be exactly the same
as breaking RC4.


--
Do as thou thinkest best.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Fixed the stream cipher "Slime"?
Date: Thu, 18 May 2000 02:08:01 GMT

In article <[EMAIL PROTECTED]>,
  Runu Knips <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > IOW, it's sucks, it's broken, shame on me, sorry guys, it's done.
>
> Hehe - funny definition of being broken: failed to implement
> on two different compilers !! *giggle* ;-)
>

Oh it works on the diff compilers, just the math behind the cipher is
flawed.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encrypting random data
Date: Thu, 18 May 2000 02:10:26 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> Just a thought...
>
> Say one has a hardware RNG generating truely random numbers (as
opposed to
> PRNs). If this hardware is on one machine, and you want to use the
random
> numbers on a different machine, would it suffice to encrypt the
random pad
> with a stream cypher like (say) RC4, then send the numbers? Is there
any way
> to break such, assuming the RC4 key was distributed securely?
>
> If that pad is then decrypted and used as a OTP, is it noticably
harder to
> break the resulting encrypted message than to break the RC4
encryption?
>
> Just wondering. :-) TIA!

You seem like a very confused individual.

If I send a OTP pad using RC4 to a friend, then technically we don't
have a otp anymore, we have RC4 (a variant there-of).  So no matter how
random your OTP is (or how close to unpredictable, etc...) it won't be
any stronger then RC4 (at best).

So you cannot share random bits over an insecure medium at all, unless
you are willing to sacrifice randomness at the hands of deterministic
finite algorithms.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto & UNICODE???
Date: Thu, 18 May 2000 02:24:06 GMT

On Wed, 17 May 2000 10:50:07 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
in part:

>Unicode is born out of a desire to be socially correct, but you can bloat
>anything to unreasonableness.  Stick with your convenience in representing
>characters, and make a few allowance for those with minor character
>differences.

Well, although political correctness is possible, it _is_ convenient
to have available a convenient way to use computers for advanced
typesetting. But that certainly does not mean that such a code ought
to be always used for everything.

>From a cryptographic point of view, of course, a 5-unit code (with
shifts, of course) is optimal if compression is not used.

John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Is H() a NP problem
Date: Thu, 18 May 2000 02:47:14 GMT

Typically to measure entropy we try a basic zero-order prediction (i.e
make a table freq[0..255] and count the frequency of the symbol) to
give a rough estimate.

Of course others will argue that there is other measurements of
entropy, and of course they are right, (i.e higher order models, string
models...)

Since we will assume afinite amount of bits (of info) present in a
string, and the string is finite in length, there a finite amount of
ways to look at the string to measure entropy (eventually two complex
models will give the same results no matter what inputs).

As the size of the string increases you can get new ways to measure the
entropy.... thus... a big problem...

Just some thoughts.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

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


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