From: owner-openssl-us...@openssl.org On Behalf Of Dave Thompson
Sent: Wednesday, 20 March, 2013 20:21
From: owner-openssl-us...@openssl.org On Behalf Of azhar jodatti
Sent: Wednesday, 20 March, 2013 15:21
snip
this.secretKey is an object of javax.crypto.SecretKey which
I am using for
Thanks for the explanation and help.. everything worked perfect. :) :)
Regards,
Azhar
On Mon, Mar 25, 2013 at 1:34 PM, Dave Thompson dthomp...@prinpay.comwrote:
From: owner-openssl-us...@openssl.org On Behalf Of Dave Thompson
Sent: Wednesday, 20 March, 2013 20:21
From:
On Tue, Mar 19, 2013 at 8:13 PM, Matt Caswell fr...@baggins.org wrote:
On 19 March 2013 14:18, azhar jodatti azhar...@gmail.com wrote:
On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell fr...@baggins.org wrote:
On 19 March 2013 12:22, azhar jodatti azhar...@gmail.com wrote:
On 20 March 2013 07:37, azhar jodatti azhar...@gmail.com wrote:
Public key :
On Wed, Mar 20, 2013 at 3:44 PM, Matt Caswell fr...@baggins.org wrote:
On 20 March 2013 07:37, azhar jodatti azhar...@gmail.com wrote:
Public key :
On 20 March 2013 11:25, azhar jodatti azhar...@gmail.com wrote:
byte[] bobPubKeyEnc = bobKpair.getPublic().getEncoded();
This is providing an encoded form of the public key, whereas your code
is expecting it as an integer. Use the following instead:
DHPublicKey dhpubkey =
On Wed, Mar 20, 2013 at 5:12 PM, Matt Caswell fr...@baggins.org wrote:
On 20 March 2013 11:25, azhar jodatti azhar...@gmail.com wrote:
byte[] bobPubKeyEnc = bobKpair.getPublic().getEncoded();
This is providing an encoded form of the public key, whereas your code
is expecting it as an
On 20 March 2013 19:21, azhar jodatti azhar...@gmail.com wrote:
One more query :).
After generating secret key :
byte[] bobSharedSecret = bobKeyAgree.generateSecret();//this generates
secret key. Note : this key matches with C client secret key :)
I am doing below stuff in JAVA :
From: owner-openssl-us...@openssl.org On Behalf Of azhar jodatti
Sent: Wednesday, 20 March, 2013 15:21
On Wed, Mar 20, 2013 at 5:12 PM, Matt Caswell fr...@baggins.org wrote:
On 20 March 2013 11:25, azhar jodatti azhar...@gmail.com wrote:
byte[] bobPubKeyEnc =
--
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)
On 19 March 2013 09:01, azhar jodatti azhar...@gmail.com wrote:
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
On Tue, Mar 19, 2013 at 2:58 PM, Matt Caswell fr...@baggins.org wrote:
On 19 March 2013 09:01, azhar jodatti azhar...@gmail.com wrote:
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
On 19 March 2013 10:37, azhar jodatti azhar...@gmail.com wrote:
On Tue, Mar 19, 2013 at 2:58 PM, Matt Caswell fr...@baggins.org wrote:
On 19 March 2013 09:01, azhar jodatti azhar...@gmail.com wrote:
And possibly relevant here, the standard Suncle JCE provider actually
uses DSA paramgen
Well, to roll out the possibility of network error's, JSON values not
being passed properly and blah blah blah I just dropped that approach.
instead of that I am running C program which prints the prime,generator and
public key. I have another program on same machine which is written in java
On 19 March 2013 12:22, azhar jodatti azhar...@gmail.com wrote:
PEM_write_bio_DHparams(out, temp);//this prints public key in base64
(this is what i think :) )
This is NOT a base64 representation of the public key. This is
printing out the parameters only (which does not include the
On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell fr...@baggins.org wrote:
On 19 March 2013 12:22, azhar jodatti azhar...@gmail.com wrote:
PEM_write_bio_DHparams(out, temp);//this prints public key in
base64
(this is what i think :) )
This is NOT a base64 representation of the public
On 19 March 2013 14:18, azhar jodatti azhar...@gmail.com wrote:
On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell fr...@baggins.org wrote:
On 19 March 2013 12:22, azhar jodatti azhar...@gmail.com wrote:
PEM_write_bio_DHparams(out, temp);//this prints public key in
base64
(this is what i
Thanks matt for looking at this. below are the details
json from C with openSSL
{
prime:
1) The C version is in hex while the java version is in decimal. Is this
intentional? When you are reading in the values are reading them correctly
(i.e. as hex or as decimal as required)
Yes. it was intentional. I am taking care of this.
2) Is this sample from the *same* key exchange? The
On 18 March 2013 12:15, azhar jodatti azhar...@gmail.com wrote:
2) Is this sample from the *same* key exchange? The parameters are
different which are obviously going to cause it to fail.
When I run both programs it calculates the params (p,g,pk) every time on
execution . that's the reason
On 18 March 2013 15:05, azhar jodatti azhar...@gmail.com wrote:
I also just noticed that in your JSON sample there is only one prime
number provided. There are in fact two required: p and q.
well, I think other prime number is g and not q. other prime number is
base generator i.e g in above
From: owner-openssl-us...@openssl.org On Behalf Of azhar jodatti
Sent: Saturday, 16 March, 2013 14:00
I am working on application which has android and iPhone client.
Both the client talk to my server which is written in JAVA. I am
using JCE implementation of DH algorithm and X509EncodedkeySpec
From: owner-openssl-us...@openssl.org On Behalf Of Matt Caswell
Sent: Monday, 18 March, 2013 09:17
On 18 March 2013 12:15, azhar jodatti azhar...@gmail.com wrote:
2) Is this sample from the *same* key exchange? The parameters are
different which are obviously going to cause it to fail.
When I
On 18 March 2013 21:02, Dave Thompson dthomp...@prinpay.com wrote:
I also just noticed that in your JSON sample there is only one
prime number provided. There are in fact two required: p and q.
No. *DSA* uses p,q,g. DH requires p,g which effectively determines
q, but DH computation doesn't
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
Thompson,
Really thanks for the reply. appreciate your time.
Yes it was JCE and not JCF. it was typo :)
I am working on application which has android and iPhone client. Both the
client talk to my server which is written in JAVA. I am using JCE
implementation of DH algorithm and
On 16 March 2013 18:00, azhar jodatti azhar...@gmail.com wrote:
Thompson,
Really thanks for the reply. appreciate your time.
Yes it was JCE and not JCF. it was typo :)
I am working on application which has android and iPhone client. Both the
client talk to my server which is written in
Matt,
No reason as such for using low level interface.I just want to get it
done. Do you see any issues with low level interface? or any issues with my
code?
In addition, the server and client works over REST API's, hence I am using
JSON format to pass the parameter over the wire.
Regards,
From: owner-openssl-us...@openssl.org On Behalf Of azhar jodatti
Sent: Wednesday, 13 March, 2013 13:44
I was trying to implement the diffie Hellman algorithm in Java
which makes use of JCF and as well as in c with openssl...
I assume you mean JCE, or maybe JCA. JCF is completely unrelated.
I
29 matches
Mail list logo
