pubkeys for p and g
martin f krafft
madduck at madduck.net
Thu Jun 26 18:29:47 EDT 2003
> I'm not certain I understand your questions, but here are some
> answers (I think).
To clear this up:
I am well aware how DH works, and what the mathematical properties
of p and g are and have to be.
My point was that some commercial vendors (Check Point and others)
claim, that if two partners want to perform a DH key exchange, they
may use their two public keys for g and p. This, in effect, would
mean that g and p were not globally known, but that the public keys
are used in their place.
I am well aware that p and g are globally known as defined in the
chosen DH Group. However, I am wondering how Check Point (and
others) can claim that public keys may well be used in place,
thereby invalidating the need for a globally constant p and g pair.
These public keys are independent of the public keys exchanged as
part of DH, which are simply calculated by the g^x mod p formula of
DH, from the private keys.
Thus every communication party would have a key pair, aA and bB,
where the capital letter is the public key. Then, the following
happens:
let g = A and p = B
let A' = g^a mod p and B' = g^b mod p
= A^a mod B = A^b mod B
and off you go, doing DH with g = A, p = B, and the keypairs aA' and
bB' on either side.
This would, in my opinion, only be possible if:
- there would be a rule to decide which public key is p and which
is g.
- all public keys (RSA in this case) are primes.
- all public keys are good generators mod p.
We are writing a book and simply want to have some backup. I am
almost sure that Check Point is bullshitting (wouldn't be the first
time), so unless anyone has actually heard of this possibility, I am
going to write this down and influence a thousand people, basically
claiming that Check Point is wrong.
Does it make sense now?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck
invalid PGP subkeys? use subkeys.pgp.net as keyserver!
experience is what causes a person
to make new mistakes
instead of old ones.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20030627/9444f98e/attachment.pgp>
More information about the cryptography
mailing list