Thanks for the explanation and help.. everything worked perfect. :) :)
Regards,
Azhar
On Mon, Mar 25, 2013 at 1:34 PM, Dave Thompson wrote:
> > From: owner-openssl-us...@openssl.org On Behalf Of Dave Thompson
> > Sent: Wednesday, 20 March, 2013 20:21
>
> > >From: owner-openssl-us...@openssl.or
> 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
> >this.secretKey is an object of javax.crypto.SecretKey which
> >I am using for
>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 wrote:
> On 20 March 2013 11:25, azhar jodatti wrote:
> > byte[] bobPubKeyEnc = bobKpair.getPublic().getEncoded();
On 20 March 2013 19:21, azhar jodatti 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 :
>SecretKeyFac
On Wed, Mar 20, 2013 at 5:12 PM, Matt Caswell wrote:
> On 20 March 2013 11:25, azhar jodatti 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:
On 20 March 2013 11:25, azhar jodatti 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 = (DHPublicKey)(bobKpair.getPublic());
Big
On Wed, Mar 20, 2013 at 3:44 PM, Matt Caswell wrote:
> On 20 March 2013 07:37, azhar jodatti wrote:
> >> Public key :
> >>
> 510930286596310951521275475612102569543976030982320596660271226159732273824290276894393668009018948652558944129592742623399736587550878753266525193164086412911472101163507
On 20 March 2013 07:37, azhar jodatti wrote:
>> Public key :
>> 510930286596310951521275475612102569543976030982320596660271226159732273824290276894393668009018948652558944129592742623399736587550878753266525193164086412911472101163507241794456000621904406552477307648348188701130736756595973501460
On Tue, Mar 19, 2013 at 8:13 PM, Matt Caswell wrote:
> On 19 March 2013 14:18, azhar jodatti wrote:
> > On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell wrote:
> >> On 19 March 2013 12:22, azhar jodatti wrote:
> >> >PEM_write_bio_DHparams(out, temp);//this prints public key in
> >> > base
On 19 March 2013 14:18, azhar jodatti wrote:
> On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell wrote:
>> On 19 March 2013 12:22, azhar jodatti wrote:
>> >PEM_write_bio_DHparams(out, temp);//this prints public key in
>> > base64
>> > (this is what i think :) )
>>
>> This is NOT a base64 rep
On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell wrote:
> On 19 March 2013 12:22, azhar jodatti 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 t
On 19 March 2013 12:22, azhar jodatti 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 public
key)
>
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
where
On 19 March 2013 10:37, azhar jodatti wrote:
>
>
> On Tue, Mar 19, 2013 at 2:58 PM, Matt Caswell wrote:
>>
>> On 19 March 2013 09:01, azhar jodatti wrote:
>>
>> > And possibly relevant here, the standard Suncle JCE provider actually
>> > uses DSA paramgen for DH and thus imposes the DSA size res
On Tue, Mar 19, 2013 at 2:58 PM, Matt Caswell wrote:
> On 19 March 2013 09:01, azhar jodatti 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 -- altho
On 19 March 2013 09:01, azhar jodatti 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 of. I don't re
<--
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 18 March 2013 21:44, Matt Caswell 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
On 18 March 2013 21:02, Dave Thompson 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 use q and standa
>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 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 progr
>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 X509Encodedkey
On 18 March 2013 15:05, azhar jodatti 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 JSON sample.
>
On 18 March 2013 12:15, azhar jodatti 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 both key values a
On 18 March 2013 12:15, azhar jodatti 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 both key values a
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 paramet
Thanks matt for looking at this. below are the details
json from C with openSSL
{
"prime":
"B01DBDE7823A696F13EEFDE810DF2A010ED8BA919186029BEECCF2F0454CE85CA3E3FFD0EB3A578F80C28930AD98559D57605E37BFE2B1BD3C6D6C7657384F4DDFF45D57C59EF2DEADAF7605A1EB36A5D5007162F026E5AE161F489C8C79A5AD10C40FC
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,
On 16 March 2013 18:00, azhar jodatti 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 JAVA. I
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 X509EncodedkeySp
>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.
On Tue, Apr 29, 2008 at 5:03 AM, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote:
> The call to EVP_EncryptInit_ex() uses the default key length for the cipher
> unless told otherwise. For Blowfish this is 128 bits but you have a 56 byte
> (?) key. You need to set the key length using
> EVP_CIPHER
On Mon, Apr 28, 2008, Vishal Rao wrote:
>
> C++ code using OpenSSL:
>
> unsigned char testplaintext[10] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
> unsigned char ciphertext[100] = {0};
> int outlen, tmplen;
>
> unsigned char key[56] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
> 14, 15, 16, 17, 18, 1
I have no idea if your C++ code is correct, but I wrote some java code
the correctly does that java side. Download "not-yet-commons-ssl.jar"
and try this utility class: org.apache.commons.ssl.OpenSSL
Here are the instructions to use it:
http://juliusdavies.ca/commons-ssl/pbe.html
In your case
Hello,
I'm trying to encrypt a few bytes (as a trial run) with the same key
and IV with Blowfish in CBC mode and "standard PKCS" padding using
OpenSSL in a C++ app and also using SUN's Java crypto libraries. The
output ciphertext is different in both places which means that I
cannot get them to in
Hi,
I have Openssl based TLS server where a java jsse (java secure socket
extention) client connects.
After a bit to exchange the server tries to renegotiate,
here's a sample code
ret = SSL_accept (ssl);
CHK_SSL_ERR(ret);
char buffer[256];
int count = 0;
static BIO
Liam,
All you will need to do is comvert the PEM format to DER.
If you "user" cert is called me.pem then:
openssl x509 -in me.pem -outform DER -out me.cer
I think that is all you will need to do. I don't have access to my
openssl right now, but I have done this before to get the certs into t
Then I tried importing a certificate signed by my CA. But now it's
complaining that "Input not an X.509 certificate". Is it because my
extension is ".pem"?
Yes! I found the answer by going through some old threads in the Sun
Microsystems website. I had to convert the PEM certificate to a DER fil
I'm having problems importing my OpennSSL certificates to my keystore. I
created my root certificate in cacert.pem and I'm trying to import this now
to my keystore.
okay. some progress. I was able to import my CA using keytool. Apparently,
you have to specify an alias for it.
keytool -keyst
Good day!
I'm having problems importing my OpennSSL certificates to my keystore. I
created my root certificate in cacert.pem and I'm trying to import this now
to my keystore.
keytool -import -trustcacerts -file cacert.pem -keystore myKeystore
I'm getting "keytool error: java.lang.Exception:
39 matches
Mail list logo
