Cryptography-Digest Digest #355, Volume #14 Mon, 14 May 01 19:13:00 EDT
Contents:
Re: OAP-L3: "The absurd weakness." (James Felling)
Hughes DH variant (Randy Langer)
Re: Hughes DH variant ("Tom St Denis")
Re: best algo ("Henrick Hellstr�m")
Re: best algo ("Tom St Denis")
Re: Hughes DH variant (Randy Langer)
Re: Hughes DH variant ("Tom St Denis")
Re: Comparison of Diff. Cryptanalysis countermeasures ("Simon Johnson")
Re: Comparison of Diff. Cryptanalysis countermeasures (Mok-Kong Shen)
Re: Comparison of Diff. Cryptanalysis countermeasures ("Tom St Denis")
Re: Comparison of Diff. Cryptanalysis countermeasures ("Tom St Denis")
Re: Hughes DH variant (Randy Langer)
Re: Hughes DH variant ("Tom St Denis")
Re: Hughes DH variant (Paul Rubin)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Mon, 14 May 2001 15:49:36 -0500
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > Tom St Denis wrote:
> >
> > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Tom St Denis wrote:
> > > > >
> > > > > "Antho
> >
> ><snip>
> >
> >
> >ver again you can and will eventually get good data, it
> > requires more work to get to that point than it would with a conventional
> > stream cypher.
>
> OK. You have made a few points from within a cage behind bars. Now
> if we take you out of the cage and out from behind the bars, can you
> make good on your assertions?
>
> "aplying that method N times will give exactly the same level of
> security as applying it once."
Mixamixfile is a subgroup of the generic permutation of 105 elements holding
first element fixed.
Scramble is a group
Redistribute just chops a bigger file into pieces -- so it adds no secutity
The bulk of your security lies in the various shuffles you have setup. they
indeed are portions of groups, but they are parts of groups of very large
order.
>
>
> Tell us the method and give us an example. This is true for one
> process using a single permutation file and it is noted in the
> instructions that you should only use this method once for this
> very reason. If you shuffle this single permutation file with
> another one or more permutation files then you can use the process
> once again since you no longer have the same original single
> permutation file.
I should know -- I was one of the people who pointed that out to you on this
very forum some months ago. I am glad to see that correction made it into your
help files at long last.
>
>
> "some of the methods will comute." Which ones and give us an example.
Scramble and any other method.Scramble should be done once first or last, and
not be relied upon to act as a breaker up of group ops.
>
>
> "Some of the methods have fixed points. Data that that method cannot
> and will not alter." Which ones and give us an example.
Mixamixfile has a true fixed point at 1+105*n sets of digits.( see my other
posting in re that)
Shuffle has an unfortunate property (fixed point like) in that in any of the
shuffled tfiles, if set m of a tfile came from a given sourcefile, so did set
m+105*n. 1<=m<=105 for all n
The "variable" processes will mix well, but the odds of set(x) and set(x+1)
being from the same original file in it are better than 99% so they are kind of
poor mixers.
>
> "I do accept that using your medhods over and over again you can and
> will eventually get good data, it requires more work to get to that
> point than it would with a conventional stream cypher."
>
> What is "good data?"
Good data is data that is acceptable for OTP use. I.e. no obvious
distinguishers, nor any glaring statistical properties, nor bad autocorrelative
porperties.
>
>
> One security advantage IS that it takes a bit more work to arrive at
> what I call the key space or point at which OTP files can be
> generated with the desired user security level. But once you get
> there, you only need to run a very few additional processes to move
> further out into the key space to generate subsequent random numbers
> with even greater security.
>
> For instance, let's say you run 100 processes at random with random
> user input to arrive at three permutation files from which you will
> generate random number files which in turn will be processed further
> to generate the OTP files.
Doing so will entail typing equivalent to 3-5 pages of singlespaced typewritten
numbers -- but what the heck its your time huh?
>
>
> To generate subsequent permutation files you do not need to start
> from scratch and run another 100 processes at random with random user
> input to generate different random number files that will be
> processed further to generate another set of OTP files.
>
> You need only run a few more random processes on each permutation
> file to enter even further into the key space where you can generate
> even more secure random number files from which you can generate
> even more secure OTP files. So this extra work is most significant
> the first time out and need not be nearly as difficult subsequently.
True to a point. False thereafter. If you are changing keys for reasons of
policy true. If you are changing keys due to the fact that your previous key
has fallen into the wrong hands, you are sadly wrong. Your security is
dependent upon how many "methods" lie between you and the last key in the hand
of your adversary.
>
>
>
> If a user wanted, they would not even have to generate new random
> number files. They could simply reprocess the original random number
> files using all the available methods offered with OAP-L3 but using
> different random user input then generate completely different OTP
> files from these original reshuffled random number files.
Only if they did not care as to forward security
>
>
> The idea is that once a user has achieved their desired security level
> by running enough processes at random using random user input, they
> will be far enough out into the key space where using any of the
> above suggestions will continue to result in practicably unbreakable
> encryption or the generation of crack-proof OTP files.
>
> Also, because it does take extra work, because the nature of the
> OAP-L3 OTP generation methods require that all the random methods be
> processed with generally the exact random user input before the
> process of even checking if the guess is correct, cracking OAP-L3
> very quickly becomes practicably impossible.
You are sadly deluded sir. This presumes that the attacker cannot program and
is indeed forced to use your program. If he is trying to break your code he
will be attempting to notice data iregularities and or analyzing your data
stream.
>
>
>
> For instance, with other encryption software, guessing a key and
> plugging it in will tell you in the span of milliseconds whether or
> not you have the right key. But with OAP-L3, any single guess will
> require the cracker to run the processes described by the guess
> completely to test the guess. And the guess must be tested further
> to see if the guess was right but only the offset within the guessed
> OTP files was correct. So this process could take seconds, minutes,
> hours, days, etc.
Lets say I use RC4 properly implemented. I know that the "methods" used there
are good, no fixed points, and no ugly group trouble, so I enter my key( easily
rememberd, so I don't have to worry that my key disk or key file is stolen),
and generate huge quantities of data before your method is even setup to go.
>
>
> Let's use a worst case scenario and say that each guess will only
> take one second to verify. If there are 1E50 possible outcomes and
> you only have to guess half of these before you discover the key
> then it will take you 1E50 / 2 = 5E49 seconds to arrive at the
> correct key which is about 1.5E42 years to get the right answer.
> (assuming about 1E8 seconds / 3-years)
Gee I can do that with a good streamcypher too.
>
>
> On top of all this a cracker has no idea when the OAP-L3 user decided to
> stop or decided that a particular security level was sufficient.
> Generally, all of this forces a cracker to try every single possible key
> with each guess as each step is taken further out into the
> possible ever expanding key space.
Yes, properly used, you can get very good results from your program. Results
equivalent to spending 5-10 minutes with a nicely written RC4 front end. My
prefrence is to spend my time doing useful work instead of spending literally
hours setting up my key. OAP-L3's problem is not that it is guaranteably
insecure, it is that to get to the point where it is useful, you have to work
alot.
>
>
> Lastly (for now,) other encryption software uses one or more
> mathematical equations to generate their encryption output. OAP-L3
> does not although the methods can be expressed mathematically. Just
> like there were once mathematical expressions that were thought to be
> insolvable but later made trivial, so might these other encryption
> software methods' equations be made trivial to crack if they are not
> already.
OAP-L3 can be expressed in mathematical terms, therefore OAP-L3 is attacakble
in the same way as any other "math based" method. What you are saying is
roughly equivalent to
"Lastly (for now,) other encryption software uses
english to describe how they generate their encryption output. OAP-L3
does not, although the methods can be expressed in english. Just
like there were once methods described in english that were thought to be
insolvable but later made trivial, so might these other encryption
software methods' equations be made trivial to crack if they are not
already."
The method by which something is described is unimportant, what is important is
what it does. Having an understanding of the underlying structures is vital.
Your vouching for your method is like, having someone say I have a plan for a
building, I am no architect, and I am not an engineer, but I think it will
stand up. You may be right, you may be wrong.
>
>
> Such an eventuality is not possible with OAP-L3 since it does not use
> any such susceptible mathematical equations in the generation process
> of the OTP files.
You shuffle and permute your data. Those processes have been extensivly studied
by mathematicians, and you assume that just because you dont CALL it math that
you are somehow exempt from them understanding that?
>
>
> You only have to ask yourself, "How much time, energy, and resources
> do I have to spare in order to crack OAP-L3?"
Yes, the fact that your method is almost totally unused does save you from
extensive analisys. If a government really wanted to beat your method, it would
NOT take long.( I'd attack the stored key files -- large unweildy and
vulnerable they are.
>
>
> Yes? "What is 'good data?'"
>
> I'd say OAP-L3 generates good data: very good data.
Yep, and complethely negates the other two sides of the triangle. Ease of use,
and practicality.
>
>
> I agree with you on this point.
>
> It certainly can provide absolute privacy, even against quantum
> computers.
And if you believe that there is this bridge in NY you really need to buy.
------------------------------
From: Randy Langer <[EMAIL PROTECTED]>
Subject: Hughes DH variant
Date: Mon, 14 May 2001 21:12:57 GMT
Can anyone point me to example C/C++ source and/or a complete
description for Eric Hughes' variant on the Diffie-Hellman key exchange
algorithm? The info I have at hand appears to be incomplete, and I'd
like to get it right the first time. A Google search for this turned up
zilch.
Thanks in advance.
Randy Langer
[EMAIL PROTECTED]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Mon, 14 May 2001 21:17:08 GMT
"Randy Langer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Can anyone point me to example C/C++ source and/or a complete
> description for Eric Hughes' variant on the Diffie-Hellman key exchange
> algorithm? The info I have at hand appears to be incomplete, and I'd
> like to get it right the first time. A Google search for this turned up
> zilch.
Good reason to invest in AC2..
Page 515...
======
(1) Alice choose a random integer x and generates
k = g^x mod p
(2) Bob chooses a random large integer y and sends Alice
Y = g^y mod p
(3) Alice Sends bob
X = Y^x mod p = g^yx mod p
(4) Bob computes
z = y^-1
k' = X^z mod p
If everything goes correctly k' = k. The advantage of this protocol over DH
is that k can be computed before any interaction, and Alice can encrypt a
message using k prior to contacting Bob. She can send it to a variety of
people and interact with them to exchange the key individually later.
======
>
> Thanks in advance.
>
> Randy Langer
> [EMAIL PROTECTED]
>
>
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 23:40:58 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:WxXL6.93720$[EMAIL PROTECTED]...
>
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> > There is a trivial solution. Take the train, meet Steve and give him
your
> > key.
>
> How do you know you met Steve and not an impostor.
>
> Believe me, there is NO solution to the "name = person" problem.
Well, I actually studied this philosophical problem at the university. I am
quite familiar with the theory of names, from Bertrand Russells theory of
definite description, Saul A. Kripkes theory of Rigid Designators, and
several later works in the field.
>From a pragmatic point of view, the problem need not be that large. You
might not know that the person you meet "really is Steve", but on the other
hand that knowledge might not be pragmatically relevant. I can think of
several situations when the person you want to communicate with by necessity
is identical to the person you actually meet, might that person really be
Steve or not Steve. A typical example is business transactions. All you
really care about, for the sake of your reputation as a reliable retailer,
is that the person who pays for the goods is identical to the person who
gets the goods.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 21:48:18 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9dpjfn$svo$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:WxXL6.93720$[EMAIL PROTECTED]...
> >
> > "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> > > There is a trivial solution. Take the train, meet Steve and give him
> your
> > > key.
> >
> > How do you know you met Steve and not an impostor.
> >
> > Believe me, there is NO solution to the "name = person" problem.
>
>
> Well, I actually studied this philosophical problem at the university. I
am
> quite familiar with the theory of names, from Bertrand Russells theory of
> definite description, Saul A. Kripkes theory of Rigid Designators, and
> several later works in the field.
>
> From a pragmatic point of view, the problem need not be that large. You
> might not know that the person you meet "really is Steve", but on the
other
> hand that knowledge might not be pragmatically relevant. I can think of
> several situations when the person you want to communicate with by
necessity
> is identical to the person you actually meet, might that person really be
> Steve or not Steve. A typical example is business transactions. All you
> really care about, for the sake of your reputation as a reliable retailer,
> is that the person who pays for the goods is identical to the person who
> gets the goods.
Ahh insightful. This is very true and is similar to my arguement for PGP
signatures on postings...
Tom
------------------------------
From: Randy Langer <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Mon, 14 May 2001 21:57:31 GMT
Tom St Denis wrote:
> "Randy Langer" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Can anyone point me to example C/C++ source and/or a complete
> > description for Eric Hughes' variant on the Diffie-Hellman key exchange
> > algorithm? The info I have at hand appears to be incomplete, and I'd
> > like to get it right the first time. A Google search for this turned up
> > zilch.
>
> Good reason to invest in AC2..
>
> Page 515...
> ------
> (1) Alice choose a random integer x and generates
> k = g^x mod p
> (2) Bob chooses a random large integer y and sends Alice
> Y = g^y mod p
> (3) Alice Sends bob
> X = Y^x mod p = g^yx mod p
> (4) Bob computes
> z = y^-1
> k' = X^z mod p
>
"z = y^-1". A true (floating point) inversion, or mod something??? As I say, it
looks a little incomplete. I assume it's suppose to be (mod p), but I always
like confirmations...
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Mon, 14 May 2001 22:03:51 GMT
"Randy Langer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
>
> > "Randy Langer" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Can anyone point me to example C/C++ source and/or a complete
> > > description for Eric Hughes' variant on the Diffie-Hellman key
exchange
> > > algorithm? The info I have at hand appears to be incomplete, and I'd
> > > like to get it right the first time. A Google search for this turned
up
> > > zilch.
> >
> > Good reason to invest in AC2..
> >
> > Page 515...
> > ------
> > (1) Alice choose a random integer x and generates
> > k = g^x mod p
> > (2) Bob chooses a random large integer y and sends Alice
> > Y = g^y mod p
> > (3) Alice Sends bob
> > X = Y^x mod p = g^yx mod p
> > (4) Bob computes
> > z = y^-1
> > k' = X^z mod p
> >
>
> "z = y^-1". A true (floating point) inversion, or mod something??? As I
say, it
> looks a little incomplete. I assume it's suppose to be (mod p), but I
always
> like confirmations...
I think it's obious that you need y^-1 mod p-1. Since bob knows y (and no
one else) by calcing this and doing k' = (g^yx)^(1/y) mod p he gets g^x mod
p which is k.
Tom
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Mon, 14 May 2001 23:20:09 +0100
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
>
> I've been through a couple of papers on diff. cryptanalysis and secure
> S-box
> generation. I've also looked at a decorrelation paper that Tom St. Denis
> mentioned (although at this point I really don't understand it, but I'm
> working on it).
>
> There appear to be two commonly used methods for diff. cryptanal.
> hardening
> for block ciphers:
>
> 1. Carefully design the S-boxes. This seems to come down
> to trying to obtain the flattest difference distribution
> possible while minimizing the non-zero entries in the
> first column of the diff. distribution table. I haven't
> fully figured out how this is done but I understand
> why this is done.
S-boxes (static or dynamic) are a powerful tools to use to resist
diferential cryptanalysis however, s-boxes by themselves offer little
security. What makes or breaks a cipher's security is knowing how the
s-boxes interact with each other and other operations. Throwing a low dp max
s-box is not good enough, in general.
> 2. Use decorrelation which can offer "provable resistance"
> to diff. attacks.
This is a clever techique, a.x + b in GF(2^w) works because we only get one
output from the f-function and we need two to solve the linear equation. So
what we get is a series of diffs with probability one. The problem then is
not which finding a difference that holds with high probability across the
cipher but to extract a difference from random. Again, like above, one has
to be careful to look at exactly how the decorrelation module interacts with
other operations in your cipher.
> Another paper which I ran across decribed using a PRNG
> to generate S-boxes (something like 8 x 8 boxes) by seeding from key
> bits. Supposedly, the probability
> of getting a bad S-box for m=8 is low and since diff. cryptanal. assumes
> that
> the S-box contents are known, it should be very difficult to use diff.
> cryptanal.
There is a lot of black magic here, as Mr. Wagner has pointed out in his
posts in this thread. It all depends on how exactly the PRNG works, if that
is suseptible to attack then this can be used to extract information about
the s-box. Plus, boxes generated with different keys will have different
Dp.Max's and characterstics. Though, as again Mr. Wagner, points out no
attack has been found against a cipher exploiting this. So here are my two
intution based ideas on key dependant s-boxes:
1. Boxes should be generated using a PRNG that is itself secure against
attack.
2. Boxes should be large (16x16 is a good size), so that the chance of a box
with bad properties is low.
> My guess is that for method 1, some kind of design tradeoff is going to
> take
> place and the S-box design will be optimized EITHER for this or that,
> but not
> both. The attacker, knowing the S-box contents, would choose the most
> appropriate
> attack. I can't venture a guess on method 2 since I don't understand it
> yet. My
> worry about method 3 would be getting bad S-boxes from certain keys, but
> I guess the PRNG seed could be constrained. Another problem with method
> 3
> is that the S-boxes won't be optimized against diff. cryptanal. but I
> don't
> see how that matters if the analyst has to know the S-box contents in
> order
> to apply diff. cryptanal.
Well, not really.. if i get an s-box generated at random of all 1's... then
your security is screwed. And thats the thing with key dependant s-boxes..
unless you do something clever you can't be assured all your keys are
equally as strong.
Simon.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Tue, 15 May 2001 00:28:36 +0200
Simon Johnson wrote:
>
[snip]
> 2. Boxes should be large (16x16 is a good size), so that the chance of a box
> with bad properties is low.
[snip]
I suppose I am not alone in considering the storage for
a 16*16 box to be excessive. Perhaps you want further
to have quite a number of these boxes, don't you?
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Mon, 14 May 2001 22:31:52 GMT
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:9dplbv$7mr$[EMAIL PROTECTED]...
>
> <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> >
> >
> > I've been through a couple of papers on diff. cryptanalysis and secure
> > S-box
> > generation. I've also looked at a decorrelation paper that Tom St. Denis
> > mentioned (although at this point I really don't understand it, but I'm
> > working on it).
> >
> > There appear to be two commonly used methods for diff. cryptanal.
> > hardening
> > for block ciphers:
> >
> > 1. Carefully design the S-boxes. This seems to come down
> > to trying to obtain the flattest difference distribution
> > possible while minimizing the non-zero entries in the
> > first column of the diff. distribution table. I haven't
> > fully figured out how this is done but I understand
> > why this is done.
>
> S-boxes (static or dynamic) are a powerful tools to use to resist
> diferential cryptanalysis however, s-boxes by themselves offer little
> security. What makes or breaks a cipher's security is knowing how the
> s-boxes interact with each other and other operations. Throwing a low dp
max
> s-box is not good enough, in general.
Well said. Things to look for,
1) High rate of active sboxes
2) Low prob truncated differentials (see the MDFC paper for example of a
good cipher broken easily by truncated attacks).
3) A homogenous design to avoid boomerang attacks.
>
> > 2. Use decorrelation which can offer "provable resistance"
> > to diff. attacks.
>
> This is a clever techique, a.x + b in GF(2^w) works because we only get
one
> output from the f-function and we need two to solve the linear equation.
So
> what we get is a series of diffs with probability one. The problem then is
> not which finding a difference that holds with high probability across the
> cipher but to extract a difference from random. Again, like above, one has
> to be careful to look at exactly how the decorrelation module interacts
with
> other operations in your cipher.
Ala MDFC.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Mon, 14 May 2001 22:36:44 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Simon Johnson wrote:
> >
> [snip]
> > 2. Boxes should be large (16x16 is a good size), so that the chance of a
box
> > with bad properties is low.
> [snip]
>
> I suppose I am not alone in considering the storage for
> a 16*16 box to be excessive. Perhaps you want further
> to have quite a number of these boxes, don't you?
Algebraic sboxes.
Tom
------------------------------
From: Randy Langer <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Mon, 14 May 2001 22:55:50 GMT
Tom St Denis wrote:
> "Randy Langer" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > Tom St Denis wrote:
> >
> > > "Randy Langer" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Can anyone point me to example C/C++ source and/or a complete
> > > > description for Eric Hughes' variant on the Diffie-Hellman key
> exchange
> > > > algorithm? The info I have at hand appears to be incomplete, and I'd
> > > > like to get it right the first time. A Google search for this turned
> up
> > > > zilch.
> > >
> > > Good reason to invest in AC2..
> > >
> > > Page 515...
> > > ------
> > > (1) Alice choose a random integer x and generates
> > > k = g^x mod p
> > > (2) Bob chooses a random large integer y and sends Alice
> > > Y = g^y mod p
> > > (3) Alice Sends bob
> > > X = Y^x mod p = g^yx mod p
> > > (4) Bob computes
> > > z = y^-1
> > > k' = X^z mod p
> > >
> >
> > "z = y^-1". A true (floating point) inversion, or mod something??? As I
> say, it
> > looks a little incomplete. I assume it's suppose to be (mod p), but I
> always
> > like confirmations...
>
> I think it's obious that you need y^-1 mod p-1. Since bob knows y (and no
> one else) by calcing this and doing k' = (g^yx)^(1/y) mod p he gets g^x mod
> p which is k.
>
> Tom
Yep. Just don't like unexpected surprises. The fact that it wasn't stated
explicitly made me wonder why, that's all.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Mon, 14 May 2001 23:00:35 GMT
"Randy Langer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
>
> > "Randy Langer" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > >
> > >
> > > Tom St Denis wrote:
> > >
> > > > "Randy Langer" <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]...
> > > > > Can anyone point me to example C/C++ source and/or a complete
> > > > > description for Eric Hughes' variant on the Diffie-Hellman key
> > exchange
> > > > > algorithm? The info I have at hand appears to be incomplete, and
I'd
> > > > > like to get it right the first time. A Google search for this
turned
> > up
> > > > > zilch.
> > > >
> > > > Good reason to invest in AC2..
> > > >
> > > > Page 515...
> > > > ------
> > > > (1) Alice choose a random integer x and generates
> > > > k = g^x mod p
> > > > (2) Bob chooses a random large integer y and sends Alice
> > > > Y = g^y mod p
> > > > (3) Alice Sends bob
> > > > X = Y^x mod p = g^yx mod p
> > > > (4) Bob computes
> > > > z = y^-1
> > > > k' = X^z mod p
> > > >
> > >
> > > "z = y^-1". A true (floating point) inversion, or mod something??? As
I
> > say, it
> > > looks a little incomplete. I assume it's suppose to be (mod p), but I
> > always
> > > like confirmations...
> >
> > I think it's obious that you need y^-1 mod p-1. Since bob knows y (and
no
> > one else) by calcing this and doing k' = (g^yx)^(1/y) mod p he gets g^x
mod
> > p which is k.
> >
> > Tom
>
> Yep. Just don't like unexpected surprises. The fact that it wasn't stated
> explicitly made me wonder why, that's all.
Righto. There are better ways todo this type of thing.
I.e find someones public key y such that y = g^x mod p, then make up a
random k and send them g^k mod p, you can now both use g^xk mod p as a
private key. Simple effective and to the point. You can calc g^xk mod p
before talking to Bob as long as you know his public key .
Tom
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: 14 May 2001 16:05:45 -0700
Randy Langer <[EMAIL PROTECTED]> writes:
> "z = y^-1". A true (floating point) inversion, or mod something??? As I say, it
> looks a little incomplete. I assume it's suppose to be (mod p), but I always
> like confirmations...
Yes, mod p. If you have to ask questions like that, better study some
math before beginning implementation.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
