<--
And possibly relevant here, the standard Suncle JCE provider actually
uses DSA paramgen for DH and thus imposes the DSA size restrictions
on DH -- 512 to 1024 in steps of 64 -- although they aren't required
by any standard I know of. I don't recall if JCE also restricts
*existing* (received) params; I'll test when I have some time.
I do recall you can get around this by using BouncyCastle instead.
But just using 1024 is easy and fine.
-->
sometime I get below error "Prime size must be multiple of 64, and can only
range from 512 to 1024 (inclusive)"
when i use small prime numbers.It means JCE uses DSA paramateres for DH
algorithm. what is openSSL equalent to this?
KeyPairGenerator kpg = KeyPairGenerator.getInstance("DH");
kpg.initialize(1024);
keyPair = kpg.generateKeyPair();
DHParameterSpec dhSpec = ((DHPublicKey)
keyPair.getPublic()).getParams();
baseGenerator = dhSpec.getG();
prime = dhSpec.getP();
sizeInBits = dhSpec.getL();
is this java code equalent to below c code?
DH_generate_parameters_ex(client,1024,DH_GENERATOR_5,NULL);
see, with openSSL I have to pass DH_GENERATOR which only allowes (2 and 5)
but that is not required in JAVA version.It generates it own base
generator.
<--
you don't need to *generate* new parameters every time. If you do,
you must send them. Sending in standard X509-ki format is often
the easiest way (and JCE does by default) but not the only way.
-->
Do I need to do this conversion explicitly? if yes then can you please tell
me how to do that. when I generate keys using DH_generate_key() function,
what is the format of the keys? If it generates according to X509 spec then
X509EncodedKeySpec should work in JAVA. but that is not the case. Do you
see anything regarding format here which makes this all stuff crapy and
non-working?
<--
if you reuse parameters, you don't *need* to send them, but it
can be useful if you do because both parties can check they agree
and something hasn't gotten misconfigured or out of sync.
-->
Even I tried by hardcoding the C generated parameter with JAVA. still faces
the same issue. :(
Regards,
Azhar
On Tue, Mar 19, 2013 at 3:28 AM, Matt Caswell <fr...@baggins.org> wrote:
> On 18 March 2013 21:44, Matt Caswell <fr...@baggins.org> wrote:
>
>> However, you are correct that the DH computation does not use q, although
>> I do not
>>
>> know whether JCE requires it to be specified (not having used JCE).
>>
>> One other point on this - X9.42 describes an optional validation
> procedure which does use q. From RFC2631 (based on X9.42):
>
> The following algorithm MAY be used to validate a received public key
> y.
>
> 1. Verify that y lies within the interval [2,p-1]. If it does not,
> the key is invalid.
> 2. Compute y^q mod p. If the result == 1, the key is valid.
> Otherwise the key is invalid.
>
> The primary purpose of public key validation is to prevent a small
> subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static
> mode is used, this check may not be necessary. See also [P1363] for
> more information on Public Key validation.
>
> Matt
>
