Cryptography-Digest Digest #687, Volume #12 Fri, 15 Sep 00 14:13:01 EDT
Contents:
Re: For the Gurus ("root@localhost " <[EMAIL PROTECTED]>)
Re: sac fullfilling decorelated functions (Serge Vaudenay)
Re: 20 suggestions for cryptographic algorithm designers (SCOTT19U.ZIP_GUY)
CDMA tracking (was Re: GSM tracking) (Darren New)
Re: 20 suggestions for cryptographic algorithm designers (Runu Knips)
Re: 20 suggestions for cryptographic algorithm designers (Roger Schlafly)
Re: 20 suggestions for cryptographic algorithm designers (Roger Schlafly)
Re: For the Gurus (Jim Gillogly)
Re: Diffie-Hellman Questions ("Michael Scott")
----------------------------------------------------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Fri, 15 Sep 2000 12:11:37 -0400
> Jim Gillogly wrote:
This one is getting a bit long. But read with patience, your questions
are answered.
>
> /dev/null wrote:
> > This example is trivialized by not
> > using a randomized key alphabet.
> >
> > Plain | ROW KEYS
> > -------|
> > ETRLC0 | ABCDE
> > NOSFW2 | FGHI
> > IADPB4 | JKL
> > HMUJK6 | MN
> > GYVQXZ | OP
> > 135789 | QR
> > ----------------
> > STUVWX COL KEYS
> > YZ0123
> > 456
> > 78
> > 9
> >
> > P(E) = c(AS, AY, A4, A7, A9, ..., 9E)
> > P(9) = c(QX, Q3, XQ, XR)
>
> OK, this is a Checkerboard cipher with known row and column
> keys (Kerckhoffs' Law, the opponent knows everything except
> the day's key).
We must assume the opponent knows everything except the key sets. In
this case there is no day's key. There may be a single key for a
message or the keys may be aperiodically changing. In a message of 200
characters there may be a dozen keys or there may be one. That is what
I am trying to figure out. How often must the key be changed?
The opponents monitor this news group, thus we are building the system
under the opponents noses. We are in the operational environment at
this time.
>
> > The key alphabet consists of A-Z
> > and 0-9. Alphabets are generated
> > by machine using the high order bits
> > of the Unix rand() function and the
> > following fragment of code.
> >
> > x = (rand() >> (rand()%23));
>
> I had assumed the method was supposed to be memorized, perhaps
> so that no incriminating evidence would be found on the user.
That is not a problem. In the real world when things get physical, the
user trades information for time. Once a message is sent the key sheets
it used are destroyed immediatly.
The system will not be used to encrypt evidentiary or other material
which may not be legally transmitted via such a system. The user will
not be subject to 'capture' or arrest or ever be in physical danger.
The key streams will be generated on a stand alone machine which has
never been connected to the net. When machine assist is available it
will be used OFF LINE. It will not always be available. Remember, "You
can not trust software unless you can trust the hardware upon which it
is running."
> However, if the user will have a Unix box available at encryption
> time, why not run a good encryption system on it then?
The user will not always have access to a specific means of
communication. It is reasonable to assume that the user of the system
may have to use carrier pigeon, morse, telephony, push to talk, email,
whatever means is available. The user may be stuck with a fax machine.
The user consults, he communicates via whatever means is available at
the customer site.
> If they
> will be carrying incriminating material, why not a Palm Pilot?
The users are a company which provides electronic warfare training and
network security services to approved customers. The users will not be
carrying incriminating material. The users may need to discuss time
sensitive material in an emergency with a high level of security.
> I still haven't seen the operating conditions and threat environment
> specified.
This is to be a backup system. It's purpose is to remain stashed on the
user's person for emergency usage. The threat environment resembles the
environment that a HUMINT operative functions within, with the exception
that the user will be overtly representing himself to be what he is.
The operating environment will not be physically hostile BUT significant
resources may be expended in an attempt to discover the activities of
the consultant by parties who do not have a right to know. The users
must assume the all communications are monitored.
>
> > If a method to ensure the user never
> > used a cipher/plain pair twice were
>
> So in this particular case no message can use more than four 9's?
> Hurm... that can limit the kinds of messages you will send.
>
I am still trying to locate a frequency table for the entire set of A-Z
and 0-9. The cell assignments may change somewhat. I noticed that as
well and mentioned it in a round about way above.
> > established, what key change criteria
> > would improve the security of this
> > system? Can this system ever be
> > secure against a dedicated professional
> > with unlimited resources?
>
> No. Unix rand() typically uses 32 bit seeds, which is within the
> range of brute force attack, so even short messages will be toast.
No problem I will use white noise generated on a number of different
frequencies from the audio output of a radio receiver. I will write the
code to interleave the input channels and then XOR thru the generated
stream to increase entropy. Randomness is easy to get. It is not the
issue here. I can manage to get a key set to the users via courier or
other secure means.
>
> Assuming a 64-bit Unix were in use, it will still be crackable
> using a known plaintext attack: once a bunch of letters in the
> matrix are filled in, the known rows and columns give away enough
> of the alternate digraphs that the whole thing will fall apart.
Which brings me back to my question? What key change criteria would
make this system more secure?
Jim, I am not a cryptanalyst anymore. I have forgotten most of what I
was taught. Neither am I a statistician, thus I am at a loss in this
forum.
I have not forgotten what it is to use these systems in the field. I
have not forgotten how easy systems are to break and I have not
forgotten that the single most influential factor in cracking a system
is the amount of encrypted material avaliable in a specific key.
I have seen world class cryptanalysts throw up their hands saying,
"There is not enough traffic to break this, when there actually was." I
have seen ignorant specialists beat their heads against the same system
and solve it. There are some things I have not forgotten. Evidence the
fact that I stated it would take machine assist to break that little
mono-alphabetic system. Sure you got it, I did not say you couldn't, I
said it would not be easy without a machine's help.
I am trying to design a manual system which will resist machine solution
while still being easy enough to use that IT WILL BE USED. It is one
thing to be able to design an unbreakable system, it is quite another to
have to use the damned thing in the field.
In the push-to-talk era the problem was not in generating a secure
manual cipher system. It was that the platoon leader or platoon sgt
would grab the radio man's mike and say, *uck that damned KAL, I want
some support... He would then spill his guts in the clear. It still
happens. When you are operational and you have to pass traffic, you
pass traffic. If the traffic is secure, good. If not, well, you pray
nobody was listening. Now I, myself, pray but I do not like to leave to
God the things I should be doing for myself.
With all that said, I appreciate the time you have deovted to this
idea. I will gratefully accept more.
Three or four of these matricies would fit on a single 9x11. Keys would
change with the matrix. Associated with each matrix would be some
number of spaces which when filled (or some other criteria met) would
require the user to switch matricies. Repeats would be disallowed.
The question I am asking is, how many letters can be encrypted in this
system before a fellow with your skill could crack it? It's like "Name
that Tune", ok? Can you compute the probability of solution given N
characters of cipher text? I will take that number and divide it by
two. I will allow that many and NO MORE than that many characters to be
encrypted per matrix. You must break free of the mind set that the
system is going to be used to move thousands or even many hundreds of
bytes before a key change. This is a pencil and paper system. It must
be used in the field via the communications medium least likely to be
monitored.
On the other hand you may tell me that there is no way to make it work.
If you do, so be it. I will continue to review my lessons and come up
with something else.
Are you interested in the challenge?
Thanks
-m-
------------------------------
Date: Fri, 15 Sep 2000 18:18:39 +0200
From: Serge Vaudenay <[EMAIL PROTECTED]>
Subject: Re: sac fullfilling decorelated functions
Tom St Denis wrote:
>
> Well in the function f(x) = a.x + b, there are differential
> characteristics that hold with p=1, however they are random chars which
> makes the attack hard.
>
> Normally there are known chars with a very small 'p' (probability).
>
> Or am I just out to lunch?
Ok.
However in all formal security proofs we have against differential
cryptanalysis,
we have
(for all char) (average over key) p < epsilon
despite we would prefer
(for all key) (for all char) p < epsilon
which is quite stronger.
For f(x) = a.x + b, for all chars, there are N keys for which p=1 and
N^2-N
keys for which p=0, so the average is 1/N which is low.
> Basically it's a 64-bit 6-round Homgenous Balanced Feistel Network
> with "a.x + b" in GF(2)^32 as the round function and addition modulo
> 2^32 as the feedback function.
>
> There is obviously an impossible differential attack but it requires
> much too much work to be practical I would think since the round keys
> are 64 bits.
>
> Other then that I am rather sure it's secure against diff/linear
> attacks of order 2.
It benefits from the very same security result against differential and
linear cryptanalysis. However I suspect we can still attack it due to
high linearity. This is why we added more additions and XORs with
contants
and nonlinear table look ups in DFC.
Serge
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: 15 Sep 2000 16:36:59 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 14 Sep 2000 20:59:15 GMT, [EMAIL PROTECTED] (D. J. Bernstein) wrote, in
>part:
>>David Hopwood <[EMAIL PROTECTED]> wrote:
>>> If there is a completely arbitrary choice of byte order, use
>>> big-endian.
>
>>No. Little-endian is much more widely supported than big-endian, and is
>>universally supported by new processors.
>
>I don't want to start a religious war here, but if yoou use
>big-endian, the description of your algorithm will be easier to
>understand, and less likely to be ambiguous by accident.
>
>
There should be NO RULES. What counts is how good the encryption
is. I still think of chess moves as P-K4 not the nre way. WHat ever
is easiest fot the guy designing the code. If he is use to a PC
he may think one way. If one is use to something else he may think
another way. The critical thing is writting something that compiles
that others can test. My stuff scott19u is written for a PC. If others
what to try a different indian that is there business.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: CDMA tracking (was Re: GSM tracking)
Date: Fri, 15 Sep 2000 16:59:44 GMT
Jerry Coffin wrote:
> I haven't looked very closely at GSM phones as such recently, but
> quite a few (especially CDMA phones) continue tracking base stations
> even when you turn them off as thoroughly as you can. =
Er, not CDMA, no. While it's true that it may take a few seconds to find
what frequencies the nearby basestations are using (or a couple of minute=
s
if you're really unlucky), and it is true that the phone remembers in FLA=
SH
what frequencies etc it was using when last you turned it off, there's no=
power running when you turn off the phone. Neither the receiver nor
transmitter is powered up for 99% of the time the phone is on, let alone
when off. Every 2.5 seconds or so the phone turns on the receiver for abo=
ut
100 msecs to catch whether it has a call coming in. The transmitter stays=
off until it moves to a different "zone" (where "zone" =3D=3D "set of cel=
ls that
all ring the same phone numbers at the same time" approximately), after
which it sends an 80 msec packet saying where it went. Your phone can eas=
ily
roam between cells without notifying any base stations of that, as long a=
s
you're not in the middle of a call.
The base stations assume you're in the same zone where it last heard from=
you for about half an hour. The phone remembers what frequencies etc it w=
as
last on. Neither of these requires the phone using any power.
Once you actually find and synchronize to the basic signal (as shown by t=
he
fact that your phone suddenly knows what time it is), it's far less than =
a
second to get the list of base stations and such. The instant your phone
knows the time, it can receive calls without ever sending anything to the=
base station, technically speaking. Of course, the base station won't ask=
the phone to ring unless it knows the phone is there, but there's no
transmission needed from the phone before it can do everything it's suppo=
sed
to. So, basically, the base station has no idea whether you turned off yo=
ur
phone or not.
It's also true that CDMA phones do things like turning off the power to t=
he
receiver in the middle of a packet if they're sure they don't need to hea=
r
the end of it, and things like powering up only part of the RAM until the=
y
need what's in the other part, so it's a pretty sure bet they're not
powering up the transmitter if they don't need to. Which they don't, as
anyone looking at the international standard can tell. (I.e., don't take
*my* word for it. :-)
> > Also, has the tracking capability been already requested by law=
> > enforcement bodies (e.g. FBI), or is it the next gift they=B4ll ask f=
rom Santa?
> =
> I don't think they need to ask for much: though base stations don't
> normally export the data anywhere, it's pretty easily available for
> the taking
Er, again, CDMA makes this far harder. CDMA cells are not uncommonly mile=
s
across (up to 20 miles, but of course smaller in cities where you use the=
cells for congestion), so it's not unusual for only one cell to be able t=
o
hear a given phone, which makes triangulation difficult. Also, CDMA contr=
ols
the power of the phone's signal quite strictly. If all the phones don't
sound the same power to the base station, the system doesn't work; hence,=
even guessing how far the phone is from the tower is virtually impossible=
=2E =
(Both are much easier with analog phones, of course. I don't know anythin=
g
about GSM in this respect.)
-- it's already been used to do things like find people in
> emergencies, so the only hurdles to using it for other purposes are
> legal, not technical. =
This is incorrect. Otherwise, folks wouldn't be working to build CDMA chi=
ps
with GPS tracking in them.
-- =
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"No wonder it tastes funny. =
I forgot to put the mint sauce on the tentacles."
------------------------------
Date: Fri, 15 Sep 2000 19:03:14 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: 20 suggestions for cryptographic algorithm designers
John Savard wrote:
> However, he is correct that little-endian is more widely used. Its
> popularity derives from that of the PDP-11, which was the machine that
> the early versions of UNIX ran on. So, in the 8-bit generation, the
> 8080 and the 6502 were both little-endian, and only the 6800 was
> big-endian.
The PDP was s neither big nor little endian, but a mixture of both.
Look at the <endian.h> of any linux or other unix ;-)
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 10:08:53 -0700
Paul Schlyter wrote:
> One way to avoid this issue completely is to return to word addressing
> in computers - then this issue would become moot. You *never* hear
> any discussion about the optimum "bit order within a byte": should the
> byte start with the least or the most significant bit?
You do occasionally see documentation numbering the bits within
a byte or words. Usually the numbering starts at the LS bit,
but sometimes the MS bit.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: Fri, 15 Sep 2000 10:13:50 -0700
John Savard wrote:
> I don't want to start a religious war here, but if you use
> big-endian, the description of your algorithm will be easier to
> understand, and less likely to be ambiguous by accident.
Like what kinds of algorithms? Big-endian might be easier in
a debugger, but I've never seen an algorithm description that
was easier to understand in big-endian (unless the algorithm
itself has some big-endian bias built in).
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Fri, 15 Sep 2000 17:21:11 +0000
"root@localhost " wrote:
>
> > Jim Gillogly wrote:
> > /dev/null wrote:
> > > This example is trivialized by not
> > > using a randomized key alphabet.
> > >
> > > Plain | ROW KEYS
> > > -------|
> > > ETRLC0 | ABCDE
> > > NOSFW2 | FGHI
> > > IADPB4 | JKL
> > > HMUJK6 | MN
> > > GYVQXZ | OP
> > > 135789 | QR
> > > ----------------
> > > STUVWX COL KEYS
> > > YZ0123
> > > 456
> > > 78
> > > 9
> > >
> > > P(E) = c(AS, AY, A4, A7, A9, ..., 9E)
> We must assume the opponent knows everything except the key sets. In
> this case there is no day's key. There may be a single key for a
> message or the keys may be aperiodically changing. In a message of 200
> characters there may be a dozen keys or there may be one. That is what
> I am trying to figure out. How often must the key be changed?
...
> The key streams will be generated on a stand alone machine which has
> never been connected to the net. When machine assist is available it
> will be used OFF LINE.
...
> > If they
> > will be carrying incriminating material, why not a Palm Pilot?
>
> The users are a company which provides electronic warfare training and
> network security services to approved customers. The users will not be
> carrying incriminating material. The users may need to discuss time
> sensitive material in an emergency with a high level of security.
You said they'll have these key streams on their persons. Mightn't they
just as well have a Palm Pilot on their persons?
> I am still trying to locate a frequency table for the entire set of A-Z
> and 0-9. The cell assignments may change somewhat. I noticed that as
> well and mentioned it in a round about way above.
If you use the frequency table to inform your key, e.g. to make
sure ETAOINSHRDLU isn't among the 9 characters that only get to
be used four times each, then you give the cryptanalyst more
help in figuring out the key square.
> No problem I will use white noise generated on a number of different
> frequencies from the audio output of a radio receiver. I will write the
> code to interleave the input channels and then XOR thru the generated
> stream to increase entropy. Randomness is easy to get. It is not the
> issue here. I can manage to get a key set to the users via courier or
> other secure means.
If you're willing to use lots of randomness and to give these
people as much key material as necessary, it seems to me you're
in the ideal spot for a OTP. Why not do like Che Guevara: use
a monome-dinome to turn your plaintext into digits, and then add
the OTP to it. This is <not> a brain-surgery type operation, and
shouldn't put undue mental strain on your victims.
> Which brings me back to my question? What key change criteria would
> make this system more secure?
Probably with a random square a competent cryppie who knows your
row and column assignments (which we assumed above are known)
could break a 50-character message with a dozen or fewer letters
of known plaintext. Wild guess. That's probably not much more
text than the table itself, assuming you want to print the rows
and columns on it for ease of use. The point is that it really
doesn't matter that you have lots of variants for the rows and
columns and thus can avoid duplicating them: since they're known
to the opponent, the table might just as well be:
> > > Plain | ROW KEYS
> > > -------|
> > > ETRLC0 | A
> > > NOSFW2 | F
> > > IADPB4 | J
> > > HMUJK6 | M
> > > GYVQXZ | O
> > > 135789 | Q
> > > ----------------
> > > STUVWX COL KEYS
That is, it's no more secure than simple substitution.
> In the push-to-talk era the problem was not in generating a secure
> manual cipher system. It was that the platoon leader or platoon sgt
> would grab the radio man's mike and say, *uck that damned KAL, I want
> some support... He would then spill his guts in the clear. It still
That's exactly what a Marine at the National Cryptologic Museum
said as I was admiring the M-94 (Jefferson disc cipher machine)
there -- he said it's hell to use in the field for tactical
communications, with all the damned discs falling all over
the ground as you try to get them on in the correct order.
And now they're worth $7250, or $5800, depending on which recent
eBay auction you're looking at! (I've been watching in amazement as
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=429603424
keeps going up. If anybody else has been waiting for a good
time to unload theirs, this looks like it!)
> The question I am asking is, how many letters can be encrypted in this
> system before a fellow with your skill could crack it? It's like "Name
Aren't you really more interested in how much it would take for
a committed attacker with heavy resources and lots of money to
buy lots of good cryppies? You really don't want to base your
security on what a few busy people in sci.crypt can't break with
one computer tied behind their backs.
If your data is valuable, you'll need to spend some effort to
protect it -- sorry, but that's reality, at least as far as I'm
aware. I don't claim to be an expert code-maker. You can certainly
design a paper and pencil + printed key system that will resist
serious attackers, but don't expect it to be much easier to use
than the Che Guevara cipher I mentioned above.
And I still think a Palm Pilot would be more to the point,
even after your description of the operating environment.
--
Jim Gillogly
Sterday, 24 Halimath S.R. 2000, 16:53
12.19.7.9.18, 7 Edznab 1 Chen, Ninth Lord of Night
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Diffie-Hellman Questions
Date: Fri, 15 Sep 2000 18:42:17 +0100
Nice example, but not good practise. You are using a primitive root for g,
whereas a generator of the prime order sub-group is better. Picking g=2 is
good, as 2^11 ==1 mod 23
Mike Scott
"Doug Stell" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Fri, 15 Sep 2000 10:22:56 -0400, Future Beacon <[EMAIL PROTECTED]>
> wrote:
>
> >I have searched the Internet for explanations of the
> >Diffie-Hellman algorithm and the description below
> >is my distillation of what little I have found. Can
> >anybody recommend a really complete on-line source
> >for the algorithm? Is there any particular way that
> >the base and the modulus must be chosen? I assume that
> >they must be different primes. I would appreciate the
> >correction of any misconceptions revealed by the description.
>
> The following is a handout that I use in teaching crypto, as part of
> my introduction to public key techniques. It should answer your
> questions and provide a worked example.
>
> The modulus should be a large prime and p-1 should have a large prime
> factor. The base should be a primative element or generator in the
> field. Alternatively, it must be of sufficiently large order.
>
> doug
>
> Example of Diffie-Hellman, on a 4-function Calculator
> =====================================================
>
> Universal derivation
>
> Goals: 1. Have a prime (p-1) with one large factor.
> 2. Know the prime factorization of (p-1).
> 3. Find a generator in P, knowing factorization.
>
> Pick primes 2 and 11 as prime factorization.
> p - 1 = 2 * 11 = 22, p = 23.
> Generators: 5, 7, 10, 11, 14, 15, 17, 19, 20, 21
> g^2 <> 1 mod 23 and g^11 <> 1 mod 23
> Pick 5 as the universal generator.
> ---------------------------------------------------------
>
> Alice Bob
> -------------- -------------
> 23, 5 Universal prime & generator 23, 5
>
> [ 21 dec, 10101 bin ] Alice's secret
>
> 14 = 5^21 mod 23 ----------> Sends to Bob 14
>
> Bob's secret [ 10 dec, 1010 bin ]
>
> 9 Sends to Alice <---------- 9 = 5^10 mod 23
>
> Alice's result Squaring of 5 Bob's result
> ---------------- --------------- ---------------
> 1 1
> 1 * 5 = 5 <- 1 5 0 -> 1
> 5 <- 0 5^2 = 2 mod 23 1 -> 1 * 2 = 2
> 5 * 4 = 20 <- 1 5^4 = 4 0 -> 2
> 20 <- 0 5^8 = 16 1 -> 2 * 16 = 9
> 20 * 3 = 14 <- 1 5^16 = 3 mod 23
>
> 18 = 9^21 mod 23 (Shared secret) 18 = 14^10 mod 23
>
> Squaring of 9 Alice's result
> ------------- ---------------
> 1
> 9^1 = 9 1 -> 1 * 9 = 9
> 9^2 = 12 0 -> 9
> 9^4 = 6 1 -> 9 * 6 = 8
> 9^8 = 13 0 -> 8
> 9^16 = 8 1 -> 8 * 8 = 18
>
> Squaring of 14 Bob's Result
> -------------- -----------------
> 1
> 14^1 = 14 0 -> 1
> 14^2 = 12 1 -> 1 * 12 = 12
> 14^4 = 6 0 -> 12
> 14^8 = 13 1 -> 12 * 13 = 18
>
> The previous page performs exponentiation by operating on the
> exponent from right-to-left. Exponentiation can also be performed
> by operating on the exponent from left-to-right. This may be more
> efficient for small base values, as the multiplications, as
> opposed to squarings, are performed only with the base values,
> which may be small values. This is illustrated below.
>
> [ 21 dec, 10101 bin ] Alice's secret
>
> 14 = 5^21 mod 23 ----------> Sends to Bob 14
>
> Bob's secret [ 10 dec, 1010 bin ]
>
> 9 Sends to Alice <---------- 9 = 5^10 mod 23
>
> Alice's public key Bob's public key
> ------------------------- -------------------------
> init: 5 <- 1 init: 5 <- 1
> square: 5 * 5 = 2 square: 5 * 5 = 2
> square: 2 * 2 = 4 <- 0 square: 2 * 2 = 4 <- 0
> mult: 4 * 5 = 20 <- 1 mult: 4 * 5 = 20 <- 1
> square: 20 * 20 = 9 square: 20 * 20 = 9 <- 0
> square: 9 * 9 = 12 <- 0
> mult: 12 * 5 = 14 <- 1
>
>
> 18 = 9^21 mod 23 (Shared secret) 18 = 14^10 mod 23
>
> Alice's shared secret Bob's shared secret
> ------------------------- -------------------------
> init: 9 <- 1 init: 14 <- 1
> square: 9 * 9 = 12 square: 14 * 14 = 12
> square: 12 * 12 = 6 <- 0 square: 12 * 12 = 6 <- 0
> mult: 6 * 9 = 8 <- 1 mult: 6 * 14 = 15 <- 1
> square: 8 * 8 = 18 square: 15 * 15 = 18 <- 0
> square: 18 * 18 = 2 <- 0
> mult: 2 * 9 = 18 <- 1
>
>
>
------------------------------
** 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
******************************
