I'd scrawled..
> Other than for b perhaps wanting to verify the correctness of { p, q, g, 
> j } ("group parameter validation"), is there any reason to send q ? 

> I would actually recommend sending all the public data. This does not take
> significant additional space and allows more verification to be performed.

That's what I thought. 

BTW, I'm not myself working on something employing a DH exchange -- I'm 
analyzing/reviewing something that does.

> I would also suggest looking at what exactly the goal is. As written this
> provides no authentication just privacy, 

Indeed, b could be any entity because it isn't proving possession of any 
known-only-to-it information.

> and if b uses the same private key
> to generate multiple yb the value of b['s private key?] will slowly leak.

Yep, I suspected that too. Thanks.

So, another question or two: 

If a purportedly "secure" protocol employing a nominal DH exchange in order to 
establish a shared secret key between a requester and responder, employs 
widely known published (on the web) fixed values for g ("2") and p (a 
purportedly prime 1040 bit number) for many of it's implementations and 
runtime invocations, what are the risks its designers are assuming with 
respect to the resultant properties of ZZ?

I suspect that many implementations will simply use the equivalent of whatever 
rand() function is available to get the bits for their private keys directly, 
and will likely not reallocate private keys unless the implementation or 
machine are restarted. So if the random number generator has known flaws, then 
there may be some predictability in both the public keys and in ZZ, yes? 
Additionally there's the previously noted issue with the values of static 
private keys slowly leaking.

thanks again,


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to