Re: [GNU Crypto] Diffie-Hellmann & ElGamal unimplementable?

[Raif S. Naffah]

hello David,

in case you missed the announcement, GNU Crypto is now merged with GNU 
Classpath.  see

* http://www.gnu.org/software/gnu-crypto/
* http://www.gnu.org/software/classpath/

all the GNU Crypto tests have all been incorporated into Mauve:

* http://sources.redhat.com/mauve/

under the gnu.testlet.gnu.java.security and gnu.testlet.gnu.javax.crypto 
heirarchies.


all future development and bug fixes continue on GNU Classpath so you 
are encouraged to follow and post on the GNU Classpath mailing lists.


On Saturday 01 July 2006 08:22, David Roth wrote:
> In TestOfDHKeyAgreements.java it says:
>
> private void setUp() {
>   IKeyPairGenerator kpg =
> KeyPairGeneratorFactory.getInstance(Registry.DH_KPG);
>   kpg.setup(new HashMap()); // use default values
>   kpA = kpg.generate();
>   kpB = kpg.generate();
> }
>
> With this setting the key agreement works, k1 is equal to k2. So far,
> no problem...
> But the Test is unrealistic, there are usually two completely
> independent classes - Server and
> Client...

they are indeed independent but the test is not unrealistic.


> - so tried to simulate it with this code: 
>
> private void setUp() {
>   IKeyPairGenerator kpg =
> KeyPairGeneratorFactory.getInstance(Registry.DH_KPG);
>   IKeyPairGenerator kpg2 =
> KeyPairGeneratorFactory.getInstance(Registry.DH_KPG);
>   kpg.setup(new HashMap()); // use default values
>   kpg2.setup(new HashMap()); // use default values
>   kpA = kpg.generate();
>   kpB = kpg2.generate();
> }
>
> BUT...
> after this, the keys k1 and k2 are NOT equal!
>
>
> What to do? Did I miss some kind of information?
> I've searched everywhere, I've tried everything - for hours and days
> - and I never got it to work...
> That's why I think it is a bug, it just can't be, that two different
> parties can have the same object!?
>
> Just let me know if You have any ideas!

you probably are missing the fact that, in the original test, although 
the key-pairs are different, they still share common parameters between 
them (i.e. p, q, and g) which makes sharing a secret possible.  by 
instantiating two different key-pair factories with different [p, q, g] 
parameters, no sharing of secrets is possible  --at least not with the 
DH agreement algorithm we have.

the test does not show how one party (A) communicates to the other party 
(B) its set of parameters, so as to allow B to generate a "compatible" 
factory.

the tests TestOfDHKeyAgreement and TestOfDHKeyAgreement2 in (Mauve) 
gnu.testlet.gnu.javax.crypto.jce simulate a more realistic scenario.


cheers;
rsn

pgpucafeQjlul.pgp
Description: PGP signature