subject:"OpenSSL for Java\?\?\?\?\?\?"

Hi Vicktor - I put a '\n' at end of java snippet

Both are now equal

Thank you for your help.

On Wed, Aug 1, 2018 at 5:47 PM timmy pony  wrote:

> Hi Vicktor,  Speed read the previous mail.
>
>
>
> On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni 
> wrote:
>
>> On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote:
>>
>> > I have tried this
>> >
>> > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256
>> codeTosign.txt
>>
>> This produces raw binary output, no base64 encoding.  What is the
>> content of the file "codeToSign.txt"?  Post the output of:
>>
>> od -tx1 < /tmp/codeToSign.txt
>>
>
>  od -tx1 < codeToSign.txt
>
> 00073  61  6d  70  6c  65  20  69  6e  70  75  74  0a
>
> 015
>
>
>>
>> > public class SHA256RSA {
>> >
>> > public static void main(String[] args) throws Exception {
>> > String input = "sample input";
>>
>> This input has no newline ending, perhaps the disk file does.
>>
>> > // Not a real private key! Replace with your private key!
>> > String strPk = "-BEGIN PRIVATE
>> KEY-\nMIIEvwIBADANBgkqhkiG9"
>> > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG"
>> > +
>> ""
>> > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n"
>> > + "-END PRIVATE KEY-\n";
>>
>> I sure hope your production code will *NOT* have the private key
>> embedded in the executable.
>>
>> > String base64Signature = signSHA256RSA(input,strPk);
>> > System.out.println("Signature="+base64Signature);
>>
>> This outputs a signature encoded in base64.
>>
>> --
>> Viktor.
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ?

Hi Vicktor,  Speed read the previous mail.



On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni 
wrote:

> On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote:
>
> > I have tried this
> >
> > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256
> codeTosign.txt
>
> This produces raw binary output, no base64 encoding.  What is the
> content of the file "codeToSign.txt"?  Post the output of:
>
> od -tx1 < /tmp/codeToSign.txt
>

 od -tx1 < codeToSign.txt

00073  61  6d  70  6c  65  20  69  6e  70  75  74  0a

015


>
> > public class SHA256RSA {
> >
> > public static void main(String[] args) throws Exception {
> > String input = "sample input";
>
> This input has no newline ending, perhaps the disk file does.
>
> > // Not a real private key! Replace with your private key!
> > String strPk = "-BEGIN PRIVATE
> KEY-\nMIIEvwIBADANBgkqhkiG9"
> > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG"
> > +
> ""
> > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n"
> > + "-END PRIVATE KEY-\n";
>
> I sure hope your production code will *NOT* have the private key
> embedded in the executable.
>
> > String base64Signature = signSHA256RSA(input,strPk);
> > System.out.println("Signature="+base64Signature);
>
> This outputs a signature encoded in base64.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ?

2018-08-01 Thread Viktor Dukhovni




> On Aug 1, 2018, at 12:14 PM, timmy pony  wrote:
> 
> Thanks Viktor, 
> for assistance .
> The embedded private key "skeleton" is only for visualisation purposes; No it 
> will not.
> 
> 
> the openssl command returns binary. 
> so i can do .But they are still coming out different.
> 
> openssl base64 -in /tmp/sign.sha256 -out 

Please re-read my previous post and respond to *all* the points.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ?

Thanks Viktor,
for assistance .
The embedded private key "skeleton" is only for visualisation purposes; No
it will not.


the openssl command returns binary.
so i can do .But they are still coming out different.

openssl base64 -in /tmp/sign.sha256 -out 

On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni 
wrote:

> On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote:
>
> > I have tried this
> >
> > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256
> codeTosign.txt
>
> This produces raw binary output, no base64 encoding.  What is the
> content of the file "codeToSign.txt"?  Post the output of:
>
> od -tx1 < /tmp/codeToSign.txt
>
> > public class SHA256RSA {
> >
> > public static void main(String[] args) throws Exception {
> > String input = "sample input";
>
> This input has no newline ending, perhaps the disk file does.
>
> > // Not a real private key! Replace with your private key!
> > String strPk = "-BEGIN PRIVATE
> KEY-\nMIIEvwIBADANBgkqhkiG9"
> > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG"
> > +
> ""
> > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n"
> > + "-END PRIVATE KEY-\n";
>
> I sure hope your production code will *NOT* have the private key
> embedded in the executable.
>
> > String base64Signature = signSHA256RSA(input,strPk);
> > System.out.println("Signature="+base64Signature);
>
> This outputs a signature encoded in base64.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ?

2018-08-01 Thread Viktor Dukhovni

On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote:

> I have tried this
>
> openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 codeTosign.txt

This produces raw binary output, no base64 encoding.  What is the
content of the file "codeToSign.txt"?  Post the output of:

od -tx1 < /tmp/codeToSign.txt

> public class SHA256RSA {
> 
> public static void main(String[] args) throws Exception {
> String input = "sample input";

This input has no newline ending, perhaps the disk file does.

> // Not a real private key! Replace with your private key!
> String strPk = "-BEGIN PRIVATE KEY-\nMIIEvwIBADANBgkqhkiG9"
> + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG"
> + ""
> + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n"
> + "-END PRIVATE KEY-\n";

I sure hope your production code will *NOT* have the private key
embedded in the executable.

> String base64Signature = signSHA256RSA(input,strPk);
> System.out.println("Signature="+base64Signature);

This outputs a signature encoded in base64.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Java Snippet output is not equal to command line openssl command output , Why ?

Hi,

Could some openssl expert please advise  ?

Trying to get the equivalent Openssl command-line version of the following
java snippet.

I have tried this  openssl dgst -sha256 -sign my_private.key -out
/tmp/sign.sha256 codeTosign.txt

But the  the results do not match ?

```
From: "tim.fortinbras" 
To: openssl-users@openssl.org
Cc:
Bcc:
Date: Tue, 31 Jul 2018 06:48:59 -0700 (MST)
Subject: Looking for exact openssl commands to do the following from
command line ?
import java.security.KeyFactory;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;

public class SHA256RSA {

public static void main(String[] args) throws Exception {
String input = "sample input";

// Not a real private key! Replace with your private key!
String strPk = "-BEGIN PRIVATE KEY-\nMIIEvwIBADANBgkqhkiG9"
+ "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG"
+ ""
+ "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n"
+ "-END PRIVATE KEY-\n";

String base64Signature = signSHA256RSA(input,strPk);
System.out.println("Signature="+base64Signature);
}

// Create base64 encoded signature using SHA256/RSA.
private static String signSHA256RSA(String input, String strPk) throws
Exception {
// Remove markers and new line characters in private key
String realPK = strPk.replaceAll("-END PRIVATE KEY-", "")
 .replaceAll("-BEGIN PRIVATE KEY-", "")
 .replaceAll("\n", "");

byte[] b1 = Base64.getDecoder().decode(realPK);
PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(b1);
KeyFactory kf = KeyFactory.getInstance("RSA");

Signature privateSignature = Signature.getInstance("SHA256withRSA");
privateSignature.initSign(kf.generatePrivate(spec));
privateSignature.update(input.getBytes("UTF-8"));
byte[] s = privateSignature.sign();
return Base64.getEncoder().encodeToString(s);
}
}
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

RE: Diffie algorithm in openssl: and Java

2013-03-25 Thread Dave Thompson

 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 symmetric encryption like this 
 byte[] utf8 = plaintext.getBytes(UTF8); 
 Cipher c = Cipher.getInstance(DES);
 c.init(Cipher.ENCRYPT_MODE, this.secretKey);
 byte[] encryptedText =  c.doFinal(utf8);
 return new sun.misc.BASE64Encoder().encode(encryptedText);

 With the usual providers DES is really DES/CBC/PKCS5Padding,
 and it would be clearer to be explicit. I thought that CBC with 
 no IV specified uses a random IV, which you would need to transmit,
 but on testing apparently it uses zeros, which in general is bad 
 but if you are using nonce DEKs it is tolerable.

Correction: on more careful checking, it's DES/*ECB*/PKCS5Padding, 
which for one block I looked at is the same as CBC IV=zeros (duh).
Sorry for the mislead.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-25 Thread azhar jodatti

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: 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 symmetric encryption like this
  byte[] utf8 = plaintext.getBytes(UTF8);
  Cipher c = Cipher.getInstance(DES);
  c.init(Cipher.ENCRYPT_MODE, this.secretKey);
  byte[] encryptedText =  c.doFinal(utf8);
  return new sun.misc.BASE64Encoder().encode(encryptedText);
 
  With the usual providers DES is really DES/CBC/PKCS5Padding,
  and it would be clearer to be explicit. I thought that CBC with
  no IV specified uses a random IV, which you would need to transmit,
  but on testing apparently it uses zeros, which in general is bad
  but if you are using nonce DEKs it is tolerable.
 
 Correction: on more careful checking, it's DES/*ECB*/PKCS5Padding,
 which for one block I looked at is the same as CBC IV=zeros (duh).
 Sorry for the mislead.


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-20 Thread azhar jodatti

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:
  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)
 
 
 X509EncodedKeySpec x509KeySpec = new
   X509EncodedKeySpec(clientPubKeyEnc);
 PublicKey alicePubKey =
 bobKeyFac.generatePublic(x509KeySpec);
   //
   this throws invalidKeySpecException : invalid key specification
  
 
  What is the reason behind this? Why it won't work with
 X509EncodedKeySpec?
 
 Because, as noted above the data you are trying to use is not what you
 think it is. X509EncodedKeySpec expects an ASN.1 type of
 SubjectPublicKeyInfo, whereas you are providing an ASN.1 type of
 DHparams.

 
  Instead of above, try something like this:
 
  BigInteger y = new
 
 
 BigInteger(4373485839237796166699589228729451887524557806298817546317652313209684941935291316056752499275686842785989445002203537603465313281932431907074220666705812428468899520395399424699433568818334649395647035588736697462362131440308900155995886437558059484184376957451229991382889256903754886307405909744230582829);
  BigInteger p = new
 
 
 BigInteger(106824077746282794452228647025839229808074839339760371103063155402464842614962676228255294325459053774613506891207056818441720848774298482866918174271328357364028843638451324415691330056638482781344307395975948664971732094293996189467599104442989563027727348339786810653279203313302815966250977426622843204103);
  BigInteger g = new BigInteger(5);
  DHPublicKeySpec dhKeySpec = new DHPublicKeySpec(y, p, g);
  PublicKey alicPubKey = bobKeyFac.generatePublic(dhKeySpec);
 
  Yes, I tried this as well. It won't throw any exception. It silently
  generate the public and secret key at server. but when I use server's
 public
  key at client to generate clients secret key, it ends up with having
  different secret key at both the end. The client secret key won't match
 with
  server's secret key.
 
 It's not throwing an exception because it is a correctly formatted
 public key as opposed to an incorrectly formatted one!

 If you're not getting the same shared secret then we have to keep
 looking for the next problem! Please can you show me the public key
 that is generated from the Java, and how you are getting that into the
 C.
 




 Public key :
 5109302865963109515212754756121025695439760309823205966602712261597322738242902768943936680090189486525589441295927426233997365875508787532665251931640864129114721011635072417944560006219044065524773076483481887011307367565959735014609601352035977981372113016128912962383614943266088691125247905870630009660962744048976306621670105745197696645428683028944617742336403041732835283570637507292137401782359467132995640884184026642300272716643279774248342543531816026535360692942687407883845458106878990927218108399715490559887862345042269910918508836619472642535350414785745034292564778165044378612630468960194913792482268072428278422412284738960598286710094132345557605518602478981231098046892613531283123151

    Secret key : 

12127704546237718092438896066413655388776362910549172519740393110168347001533576823026774727367573930957394257354070595978655048643912250308681026844585744709027576900402249670187203160151084771397152790055765927595015924125212527820968758168922306979142896670732847778567823870168933256602812482617195330

These are the public and secret key generated at JAVA server.  I am passing
public key to C.
below is the C code snippet which takes this key and generates secret key.

printf(Enter server public key \n);
unsigned char serverpublickey[1024];
scanf(%s,serverpublickey);// reads the server public key
BIGNUM *spubkey=BN_new();
BIGNUM **ppubkey =spubkey;
BN_dec2bn(ppubkey,serverpublickey);//convert decimal key to BIGNUM
printf(\nserver public key= \n);
BN_print(out,*ppubkey);
clientout=DH_compute_key(clientbuf,*ppubkey,client);


above DH_compute_key function returns -1 values and the error message it
prints is error:05066066:Diffie-Hellman routines:COMPUTE_KEY:invalid
public key

I am using below code to get this error
unsigned long errorcode = ERR_get_error();
ERR_error_string_n(errorcode, errbuf,sizeof errbuf);





Matt

Re: Diffie algorithm in openssl: and Java

2013-03-20 Thread Matt Caswell

On 20 March 2013 07:37, azhar jodatti azhar...@gmail.com wrote:
 Public key :
 5109302865963109515212754756121025695439760309823205966602712261597322738242902768943936680090189486525589441295927426233997365875508787532665251931640864129114721011635072417944560006219044065524773076483481887011307367565959735014609601352035977981372113016128912962383614943266088691125247905870630009660962744048976306621670105745197696645428683028944617742336403041732835283570637507292137401782359467132995640884184026642300272716643279774248342543531816026535360692942687407883845458106878990927218108399715490559887862345042269910918508836619472642535350414785745034292564778165044378612630468960194913792482268072428278422412284738960598286710094132345557605518602478981231098046892613531283123151


This public key is too big. It is far larger than the value of p. How
are you extracting and printing it?

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-20 Thread azhar jodatti

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 :
 
 5109302865963109515212754756121025695439760309823205966602712261597322738242902768943936680090189486525589441295927426233997365875508787532665251931640864129114721011635072417944560006219044065524773076483481887011307367565959735014609601352035977981372113016128912962383614943266088691125247905870630009660962744048976306621670105745197696645428683028944617742336403041732835283570637507292137401782359467132995640884184026642300272716643279774248342543531816026535360692942687407883845458106878990927218108399715490559887862345042269910918508836619472642535350414785745034292564778165044378612630468960194913792482268072428278422412284738960598286710094132345557605518602478981231098046892613531283123151
 

 This public key is too big. It is far larger than the value of p. How
 are you extracting and printing it?


Java JCE generating this key. :( :(  Below is the code I am using to print
this.



   
byte[] bobPubKeyEnc = bobKpair.getPublic().getEncoded();
// this generated server's public key

   
 System.out.println(public key : + new BigInteger(bobPubKeyEnc));
//prints public key in BigInteger (decimal)


Even you can see the same steps in my previous mail threads where I pasted
my complete JAVA and C code. Do you see any issue with this? or anything
else 







Matt
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-20 Thread Matt Caswell

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 = (DHPublicKey)(bobKpair.getPublic());
BigInteger bobPubKeyInt = dhpubkey.getY();

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-20 Thread azhar jodatti

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 integer. Use the following instead:

 DHPublicKey dhpubkey = (DHPublicKey)(bobKpair.getPublic());
 BigInteger bobPubKeyInt = dhpubkey.getY();


Yes, Matt. This worked and it also generates same secret key at both the
end :) :) :)
Thanks a lot. You been a great help to me.
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 :
   SecretKeyFactory skf = SecretKeyFactory.getInstance(DES);
DESKeySpec desSpec = new DESKeySpec(bobSharedSecret);
this.secretKey = skf.generateSecret(desSpec);

What is the equivalent of this in C?

this.secretKey is an object of javax.crypto.SecretKey which I am using for
symmetric encryption like this
byte[] utf8 = plaintext.getBytes(UTF8);
Cipher c = Cipher.getInstance(DES);
c.init(Cipher.ENCRYPT_MODE, this.secretKey);
byte[] encryptedText =  c.doFinal(utf8);
return new sun.misc.BASE64Encoder().encode(encryptedText);

and decryption like this
   Cipher c = Cipher.getInstance(DES);
byte[] decryptBase64= new
sun.misc.BASE64Decoder().decodeBuffer(incryptedData);
c.init(Cipher.DECRYPT_MODE, this.secretKey);
byte plaintext[] = c.doFinal(decryptBase64);
return new String(plaintext,UTF-8);













 Matt
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-20 Thread Matt Caswell

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 :
SecretKeyFactory skf = SecretKeyFactory.getInstance(DES);
 DESKeySpec desSpec = new DESKeySpec(bobSharedSecret);
 this.secretKey = skf.generateSecret(desSpec);

 What is the equivalent of this in C?

Well looking at the docs the DESKeySpec constructor just takes the
first 8 bytes of the byte array to form the key. The equivalent is to
just pass an unsigned char * pointing at the shared secret in the key
parameter in the call to EVP_EncryptInit_ex.

BUT - you should NOT use the shared secret directly like this. This
goes back to my point about implementing your own protocol - it is
easy to make a mistake like this. Protocols will typically pass the
shared secret through some message digest function (such as SHA2), and
use the output from that as the key. See section 2.1.2 of RFC2631 for
an example of this in practice. The problem is that the set of
possible DH shared secrets is not necessarily evenly distributed
within the keyspace. By using the shared secret directly you could
introduce biases into your encryption, which could in turn lead to a
security flaw.  (As an aside another potential security problem with
DH is that it is susceptible to MITM attacks without some
authentication layer - another thing that protocols will typically
add)

For information on encryption with openssl see:
http://wiki.opensslfoundation.com/index.php/EVP
and in particular these pages linked from there:
http://wiki.opensslfoundation.com/index.php/EVP_Symmetric_Encryption_and_Decryption
http://wiki.opensslfoundation.com/index.php/EVP_Authenticated_Encryption_and_Decryption

Also see the manual pages:
http://www.openssl.org/docs/crypto/EVP_EncryptInit.html#

Message Digests are covered here:
http://wiki.opensslfoundation.com/index.php/EVP_Message_Digests
http://www.openssl.org/docs/crypto/EVP_DigestInit.html#

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Diffie algorithm in openssl: and Java

2013-03-20 Thread Dave Thompson

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 = 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());
   BigInteger bobPubKeyInt = dhpubkey.getY();

To be exact, PublicKey.getEncoded() is returning the X509 encoding 
of the parameters AND public value (y), which is why it looks huge.
Matt's correction correctly get y separately, as a number.

One more query :). 

After generating secret key : 
byte[] bobSharedSecret = bobKeyAgree.generateSecret();
//this generates secret key. Note : this key matches with C client secret
key :) 

Actually that's the shared secret, as your name says.
Using the shared secret directly as a secret key is the naive 
1970's version often shown in textbooks, but (most?) real 
protocols and standards interpose a key derivation step.

Also this is good place to note that unauthenticated DH keyagreement 
is insecure against an active attacker. Look for Ross Anderson's 
paper Mind your p's and q's. 

I am doing below stuff in JAVA : 
SecretKeyFactory skf = SecretKeyFactory.getInstance(DES);
DESKeySpec desSpec = new DESKeySpec(bobSharedSecret);
this.secretKey = skf.generateSecret(desSpec);

If you don't care about DES specifics (see below) you can use 
SecretKeySpec with algorithm=DES and it implements interface Key 
so you can pass it to Cipher.init without going through a factory.

What is the equivalent of this in C?

*openssl* doesn't require magic data types like Java does,
but does require that a DES key be scheduled or expanded 
before actual encrypt/decrypt. You can do this with the 
encrypt/decrypt call, or (once) in advance like:

DES_key_schedule des_k;
DES_set_key[_checked/_unchecked] ((void*)secretkeyvalue, des_k);

See man -3ssl des

(For other crypto libraries in C, answer is different.)

But note classic single DES is fallen for about 10 years.
Are you using a textbook from 1990 or something?

this.secretKey is an object of javax.crypto.SecretKey which 
I am using for symmetric encryption like this 
byte[] utf8 = plaintext.getBytes(UTF8); 
Cipher c = Cipher.getInstance(DES);
c.init(Cipher.ENCRYPT_MODE, this.secretKey);
byte[] encryptedText =  c.doFinal(utf8);
return new sun.misc.BASE64Encoder().encode(encryptedText);

With the usual providers DES is really DES/CBC/PKCS5Padding,
and it would be clearer to be explicit. I thought that CBC with 
no IV specified uses a random IV, which you would need to transmit,
but on testing apparently it uses zeros, which in general is bad 
but if you are using nonce DEKs it is tolerable.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

--

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

Re: Diffie algorithm in openssl: and Java

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 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.

It appears to be equivalent, although I am not familiar with the JCE
API. What I do not understand though is why you have code to generate
parameters on *both* sides of your communication. If you are going to
generate params every time (which both Dave and myself have advised
against - it is an expensive operation), you still only need to do it
on one side of the communication. So, after a  bit of googling, I
would expect to see something like this on the Java side (if the C
side generates the params):

KeyPairGenerator kpg = KeyPairGenerator.getInstance(DH);
kpg.initialize(new DHParameterSpec(/* p value passed from C */, /* g
value passed from C */));
keyPair = kpg.generateKeyPair();

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

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 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.

 It appears to be equivalent, although I am not familiar with the JCE
 API. What I do not understand though is why you have code to generate
 parameters on *both* sides of your communication. If you are going to
 generate params every time (which both Dave and myself have advised
 against - it is an expensive operation), you still only need to do it
 on one side of the communication. So, after a  bit of googling, I
 would expect to see something like this on the Java side (if the C
 side generates the params):


Well, above both the code snaps are at client side, not at server. I
understand I don't have to generate keys at both the end. I just wanted to
give you an idea how I am doing it in JAVA and C to generate the keys. As
you said both code appears to be equivalent but practically it won't seems
like . at-least in my scenario. because parameters generated with above
java code works with my server but that's not the case with parameters
generated with above C code. 



 KeyPairGenerator kpg = KeyPairGenerator.getInstance(DH);
 kpg.initialize(new DHParameterSpec(/* p value passed from C */, /* g
 value passed from C */));
 keyPair = kpg.generateKeyPair();

 yes, I m doing this at server. after generating keyPair I am generating
keyAgreent as well
. below is the code for this

KeyAgreement keyAgree = KeyAgreement.getInstance(DH);
keyAgree.init(keyPair.getPrivate());
//this generates public key at server
byte[] serverPubKeyEnc = keyPair.getPublic().getEncoded();
   //I really don't know how exactly it does this. but its mandatory
keyAgree.doPhase(clientPubllicKey, true);
   //this generates secret key at server
   byte[] sharedSecret = keyAgree.generateSecret();



 Matt

Re: Diffie algorithm in openssl: and Java

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 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.

 It appears to be equivalent, although I am not familiar with the JCE
 API. What I do not understand though is why you have code to generate
 parameters on *both* sides of your communication. If you are going to
 generate params every time (which both Dave and myself have advised
 against - it is an expensive operation), you still only need to do it
 on one side of the communication. So, after a  bit of googling, I
 would expect to see something like this on the Java side (if the C
 side generates the params):


 Well, above both the code snaps are at client side, not at server. I
 understand I don't have to generate keys at both the end. I just wanted to
 give you an idea how I am doing it in JAVA and C to generate the keys. As
 you said both code appears to be equivalent but practically it won't seems
 like . at-least in my scenario. because parameters generated with above java
 code works with my server but that's not the case with parameters generated
 with above C code.



 KeyPairGenerator kpg = KeyPairGenerator.getInstance(DH);
 kpg.initialize(new DHParameterSpec(/* p value passed from C */, /* g
 value passed from C */));
 keyPair = kpg.generateKeyPair();

 yes, I m doing this at server. after generating keyPair I am generating
 keyAgreent as well
 . below is the code for this

 KeyAgreement keyAgree = KeyAgreement.getInstance(DH);
 keyAgree.init(keyPair.getPrivate());
 //this generates public key at server
 byte[] serverPubKeyEnc = keyPair.getPublic().getEncoded();
//I really don't know how exactly it does this. but its mandatory
 keyAgree.doPhase(clientPubllicKey, true);
//this generates secret key at server
byte[] sharedSecret = keyAgree.generateSecret();

Can you share the code where you load the parameters from the C into
JCE? Also how you set up clientPublicKey. Finally would be useful if
you can dump out the parameters after they have been read, and compare
to the JSON sent.

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

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 I am hard coding these C generated values and trying to get the
public and secret key. ofcourse it is also giving me the same exception.

below is the complete C code written to generate DH params. most of the
part  is taken from openSSL library source code.

#include stdio.h
#include stdlib.h
#include string.h
#include openssl/crypto.h
#include openssl/dh.h
#include err.h

static const char rnd_seed[] = string to make the random number generator
think it has the entropy;

int main(){

BN_GENCB _cb;
DH *client= NULL;
char buf[12];
unsigned char *clientbuf=NULL;
int i,clientlen,clientout,ret=1;
BIO *out;

CRYPTO_malloc_debug_init();
CRYPTO_dbg_set_options(V_CRYPTO_MDEBUG_ALL);
CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
ERR_load_crypto_strings();
#ifdef OPENSSL_SYS_WIN32
CRYPTO_malloc_init();
#endif

RAND_seed(rnd_seed, sizeof rnd_seed);

out=BIO_new(BIO_s_file());
if (out == NULL) {
printf(BIO is null. exiting from program);
goto err;
}
BIO_set_fp(out,stdout,BIO_NOCLOSE);

//BN_GENCB_set(_cb,cb, out);//is this really required. my gcc not
recognizing cb instance so   just commenting
client = DH_new();
if(client == NULL){
printf(Client DH is null);
goto err;
}

DH_generate_parameters_ex(client,1024,DH_GENERATOR_5,NULL);

if (!DH_check(client, i)) {
goto err;
}

if (i  DH_CHECK_P_NOT_PRIME)
BIO_puts(out, p value is not prime\n);
if (i  DH_CHECK_P_NOT_SAFE_PRIME)
BIO_puts(out, p value is not a safe prime\n);
if (i  DH_UNABLE_TO_CHECK_GENERATOR)
BIO_puts(out, unable to check the generator value\n);
if (i  DH_NOT_SUITABLE_GENERATOR)
BIO_puts(out, the g value is not a generator\n);

BIO_puts(out,\np=);//this prints the P in hex
printf(%s,BN_bn2dec(client-p));//this prints the P in decimal
BIO_puts(out,\ng=);
BN_print(out,client-g);//prints generator which is 5 in this case
BIO_puts(out,\n);

if (!DH_generate_key(client)) {
printf(unable to generate client keys);
goto err;
}
BIO_puts(out,pri 1=);
BN_print(out,client-priv_key);//prints private key
BIO_puts(out,\npub 1=);
printf(%s,BN_bn2dec(client-pub_key));//prints public key in
decimal format
DH *temp = DHparams_dup(client);
   BIO_puts(out,\n\n\n PEM = );
   PEM_write_bio_DHparams(out, temp);//this prints public key in base64
(this is what i think :) )

BIO_puts(out,\n\n);

err:
if (clientbuf != NULL) OPENSSL_free(clientbuf);
if (serverbuf != NULL) OPENSSL_free(serverbuf);
if(server != NULL) DH_free(server);
if(client != NULL) DH_free(client);
BIO_free(out);
return 1;

}

This is what it prints when I ran this program.

p=106824077746282794452228647025839229808074839339760371103063155402464842614962676228255294325459053774613506891207056818441720848774298482866918174271328357364028843638451324415691330056638482781344307395975948664971732094293996189467599104442989563027727348339786810653279203313302815966250977426622843204103
g=5
pri1=622BBB2CA70FC8665F9EC3A95CF7B5C46D2F77AB10AA7D3FF485ADA9C6E005C7CF35AC0DBBFC256D2EB3AC702899140369433E1546B9DC915ACA5883D91F8FACB731F745B23C3A399FAFBDC6355E3D4203462432E950670297F6930B98C261A215053164893C2FAB55A1170699C3EDE919E59F895455B995A19C37670A6FA358
pub1=4373485839237796166699589228729451887524557806298817546317652313209684941935291316056752499275686842785989445002203537603465313281932431907074220666705812428468899520395399424699433568818334649395647035588736697462362131440308900155995886437558059484184376957451229991382889256903754886307405909744230582829
PEM = -BEGIN DH PARAMETERS-
MIGHAoGBAJgfXoi5POaY+aWtOFfykV7i9JNaX1ecr1W/PeqNwpcdTg1y75FaJwrO
LZSKds6dr6HtTEs5Jltda1GY2HklY8f3mja5EhNeLGLRfchQ8+Bn2FPGU1mMFpbF
07/tRJe6SOLfbQzIcTLn+TXbkS5fKWqerRnww4NZI0B+FBC+/DIHAgEF
-END DH PARAMETERS-

Here is my java code .

import java.io.*;
import java.math.BigInteger;
import java.security.*;
import java.security.spec.*;
import java.security.interfaces.*;
import javax.crypto.*;
import javax.crypto.spec.*;
import javax.crypto.interfaces.*;
import com.sun.crypto.provider.SunJCE;

public class DiffieHellmanServer {

private DiffieHellmanServer() {
};

public static void main(String argv[]) {
try {
DiffieHellmanServer keyAgree = new DiffieHellmanServer();
keyAgree.run1();
}
catch (Exception e) {
System.err.println(Error:  + e);
System.exit(1);
}

Re: Diffie algorithm in openssl: and 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 public
key)


   X509EncodedKeySpec x509KeySpec = new
 X509EncodedKeySpec(clientPubKeyEnc);
   PublicKey alicePubKey = bobKeyFac.generatePublic(x509KeySpec); //
 this throws invalidKeySpecException : invalid key specification


Instead of above, try something like this:

BigInteger y = new
BigInteger(4373485839237796166699589228729451887524557806298817546317652313209684941935291316056752499275686842785989445002203537603465313281932431907074220666705812428468899520395399424699433568818334649395647035588736697462362131440308900155995886437558059484184376957451229991382889256903754886307405909744230582829);
BigInteger p = new
BigInteger(106824077746282794452228647025839229808074839339760371103063155402464842614962676228255294325459053774613506891207056818441720848774298482866918174271328357364028843638451324415691330056638482781344307395975948664971732094293996189467599104442989563027727348339786810653279203313302815966250977426622843204103);
BigInteger g = new BigInteger(5);
DHPublicKeySpec dhKeySpec = new DHPublicKeySpec(y, p, g);
PublicKey alicPubKey = bobKeyFac.generatePublic(dhKeySpec);


Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

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 key. This is
 printing out the parameters only (which does not include the public
 key)


X509EncodedKeySpec x509KeySpec = new
  X509EncodedKeySpec(clientPubKeyEnc);
PublicKey alicePubKey = bobKeyFac.generatePublic(x509KeySpec);
 //
  this throws invalidKeySpecException : invalid key specification
 

 What is the reason behind this? Why it won't work with X509EncodedKeySpec?



 Instead of above, try something like this:

 BigInteger y = new

 BigInteger(4373485839237796166699589228729451887524557806298817546317652313209684941935291316056752499275686842785989445002203537603465313281932431907074220666705812428468899520395399424699433568818334649395647035588736697462362131440308900155995886437558059484184376957451229991382889256903754886307405909744230582829);
 BigInteger p = new

 BigInteger(106824077746282794452228647025839229808074839339760371103063155402464842614962676228255294325459053774613506891207056818441720848774298482866918174271328357364028843638451324415691330056638482781344307395975948664971732094293996189467599104442989563027727348339786810653279203313302815966250977426622843204103);
 BigInteger g = new BigInteger(5);
 DHPublicKeySpec dhKeySpec = new DHPublicKeySpec(y, p, g);
 PublicKey alicPubKey = bobKeyFac.generatePublic(dhKeySpec);

 Yes, I tried this as well. It won't throw any exception. It silently
 generate the public and secret key at server. but when I use server's
 public key at client to generate clients secret key, it ends up with having
 different secret key at both the end. The client secret key won't match
 with server's secret key.




 

 Matt

Re: Diffie algorithm in openssl: and Java

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 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)


X509EncodedKeySpec x509KeySpec = new
  X509EncodedKeySpec(clientPubKeyEnc);
PublicKey alicePubKey = bobKeyFac.generatePublic(x509KeySpec);
  //
  this throws invalidKeySpecException : invalid key specification
 

 What is the reason behind this? Why it won't work with X509EncodedKeySpec?

Because, as noted above the data you are trying to use is not what you
think it is. X509EncodedKeySpec expects an ASN.1 type of
SubjectPublicKeyInfo, whereas you are providing an ASN.1 type of
DHparams.


 Instead of above, try something like this:

 BigInteger y = new

 BigInteger(4373485839237796166699589228729451887524557806298817546317652313209684941935291316056752499275686842785989445002203537603465313281932431907074220666705812428468899520395399424699433568818334649395647035588736697462362131440308900155995886437558059484184376957451229991382889256903754886307405909744230582829);
 BigInteger p = new

 BigInteger(106824077746282794452228647025839229808074839339760371103063155402464842614962676228255294325459053774613506891207056818441720848774298482866918174271328357364028843638451324415691330056638482781344307395975948664971732094293996189467599104442989563027727348339786810653279203313302815966250977426622843204103);
 BigInteger g = new BigInteger(5);
 DHPublicKeySpec dhKeySpec = new DHPublicKeySpec(y, p, g);
 PublicKey alicPubKey = bobKeyFac.generatePublic(dhKeySpec);

 Yes, I tried this as well. It won't throw any exception. It silently
 generate the public and secret key at server. but when I use server's public
 key at client to generate clients secret key, it ends up with having
 different secret key at both the end. The client secret key won't match with
 server's secret key.

It's not throwing an exception because it is a correctly formatted
public key as opposed to an incorrectly formatted one!

If you're not getting the same shared secret then we have to keep
looking for the next problem! Please can you show me the public key
that is generated from the Java, and how you are getting that into the
C.

Matt
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

2013-03-18 Thread azhar jodatti

Thanks matt for looking at this. below are the details

json  from C with openSSL

{
prime:
B01DBDE7823A696F13EEFDE810DF2A010ED8BA919186029BEECCF2F0454CE85CA3E3FFD0EB3A578F80C28930AD98559D57605E37BFE2B1BD3C6D6C7657384F4DDFF45D57C59EF2DEADAF7605A1EB36A5D5007162F026E5AE161F489C8C79A5AD10C40FC7B914CDD85EE8A493307EE183194655D5190A3B7D8B45036E56E0C653,
basegenerator: 2,
size: 1024,
publickey:
829DE389D7731F6CB1C92B92965E119FFCBAE433C5B19B5C262623FD5EA6F2D53EFAD3195372B7C746DB376C3739CBC03BE7614183F658E059F02FF8C463051E3684424BE8F3F96353275201D8B8154DED3A5152DD04EBD55C0EC20544F975EEEB703B3085C174C761712AC83EACF8507895571E1F076876F26162504D75EF11
}

JSON with JAVA

{
prime:
178011905478542266528237562450159990145232156369120674273274450314442865788737020770612695252123463079567156784778466449970650770920727857050009668388144034129745221171818506047231150039301079959358067395348717066319802262019714966524135060945913707594956514672855690606794135837542707371727429551343320695239,
basegenerator:
1740682075324020951858119801235234365386044907945613509784958310405999534884558231478515974089409507253077970949157594923683005742524387610370844734671801488761181030830437549851909834726015504946913294880833954923138536164648264460849230407872181895056496097769368017749273708962006689187956744210730,
size: 1024,
publickey:
154098060632197825972569070553594673213907981120204558893455132154488920498286340180930009617674527453058248409146259055129616519883338912429359077804301589391083095780370584174889589223725092053310001148182587778315708960959816212553890780658697750126252666385136330617189340099488509957293788029153796583284280546893194823052732368554200517384648060949814219845513312636361799960550824305241776726569729968117653644039260346804354135691237238964153781814300021332541328282477027772784043832083697573459487287571520026609334964134811373470209956613009283464376018849091639198208244682804180475479662224652170610412421382256896232908714139611606796633319949985382724877107919957408909942743414340389890006834786464852247662337830546584844189278383274479199021252090407963572739286575933788241737975537671923484277171204499262529715278092506505239752566691287452373502190399117732855968397767896906732126573639005461407592315315318920060328019073971670048355762952267750188451524151795498747866082848788789357672209810743252483
}

Kindly let me know if you need anything else. even I can share my
implementation (both Java and C)




Regards,
Azhar


On Sun, Mar 17, 2013 at 1:10 PM, Matt Caswell fr...@baggins.org wrote:



 On 16 March 2013 22:29, azhar jodatti azhar...@gmail.com wrote:


 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.

 The low-level interface will *work*, its just *better* to use the high
 level interface. The high level interface is less tightly coupled to the
 specifics of any one particular algorithm (you would be able to reuse much
 of your code if you needed to use ECDH instead of DH at some point in the
 future). In general the high level interface also hides much of the
 complexity of working with specific algorithms.

 Can you supply a sample of the JSON format that you are using to pass
 parameters and public keys?

 Matt

Re: Diffie algorithm in openssl: and Java

2013-03-18 Thread azhar jodatti

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 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 are different. That won't
make any such difference :) right?

3) Its not actually necessary to pass the full parameters every time you
exchange keys. This can be agreed up front, e.g. RF5114 defines a set of
standard well known parameters which can be used off the shelf. OpenSSL
has built-in support for these.
I need to look into this. Do you mean the hard coded prime and base
generator numbers at client and server? how about public key?

Regards,
Azhar

On Mon, Mar 18, 2013 at 3:22 PM, Matt Caswell fr...@baggins.org wrote:

On 18 March 2013 06:26, azhar jodatti azhar...@gmail.com wrote:

Thanks matt for looking at this. below are the details

json from C with openSSL

{
prime:
B01DBDE7823A696F13EEFDE810DF2A010ED8BA919186029BEECCF2F0454CE85CA3E3FFD0EB3A578F80C28930AD98559D57605E37BFE2B1BD3C6D6C7657384F4DDFF45D57C59EF2DEADAF7605A1EB36A5D5007162F026E5AE161F489C8C79A5AD10C40FC7B914CDD85EE8A493307EE183194655D5190A3B7D8B45036E56E0C653,
basegenerator: 2,
size: 1024,
publickey:
829DE389D7731F6CB1C92B92965E119FFCBAE433C5B19B5C262623FD5EA6F2D53EFAD3195372B7C746DB376C3739CBC03BE7614183F658E059F02FF8C463051E3684424BE8F3F96353275201D8B8154DED3A5152DD04EBD55C0EC20544F975EEEB703B3085C174C761712AC83EACF8507895571E1F076876F26162504D75EF11
}

JSON with JAVA

{
prime:
178011905478542266528237562450159990145232156369120674273274450314442865788737020770612695252123463079567156784778466449970650770920727857050009668388144034129745221171818506047231150039301079959358067395348717066319802262019714966524135060945913707594956514672855690606794135837542707371727429551343320695239,
basegenerator:
1740682075324020951858119801235234365386044907945613509784958310405999534884558231478515974089409507253077970949157594923683005742524387610370844734671801488761181030830437549851909834726015504946913294880833954923138536164648264460849230407872181895056496097769368017749273708962006689187956744210730,
size: 1024,
publickey:
154098060632197825972569070553594673213907981120204558893455132154488920498286340180930009617674527453058248409146259055129616519883338912429359077804301589391083095780370584174889589223725092053310001148182587778315708960959816212553890780658697750126252666385136330617189340099488509957293788029153796583284280546893194823052732368554200517384648060949814219845513312636361799960550824305241776726569729968117653644039260346804354135691237238964153781814300021332541328282477027772784043832083697573459487287571520026609334964134811373470209956613009283464376018849091639198208244682804180475479662224652170610412421382256896232908714139611606796633319949985382724877107919957408909942743414340389890006834786464852247662337830546584844189278383274479199021252090407963572739286575933788241737975537671923484277171204499262529715278092506505239752566691287452373502190399117732855968397767896906732126573639005461407592315315318920060328019073971670048355762952267750188451524151795498747866082848788789357672209810743252483
}

Kindly let me know if you need anything else. even I can share my
implementation (both Java and C)

So a few things strike me about this:

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)

2) Is this sample from the *same* key exchange? The parameters are
different which are obviously going to cause it to fail.

Matt

Re: Diffie algorithm in openssl: and Java

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 both key values are different. That won't
 make any such difference :) right?


The parameters p, q and g need to be the same on both sides of the
exchange. The values for this can be agreed in advance. You do not need to
calculate them every time. If the two parties in the exchange are using
different parameters then it will not work. Each side will have different
private keys, and hence different public keys. You *can* generate the
parameters every time - it will work as long as both sides are using the
same p, q and g values - but there is no reason to do so.

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.



 3) Its not actually necessary to pass the full parameters every time you
 exchange keys. This can be agreed up front, e.g. RF5114 defines a set of
 standard well known parameters which can be used off the shelf. OpenSSL
 has built-in support for these.
 I need to look into this. Do you mean the hard coded prime and base
 generator numbers at client and server? how about public key?


The values p, q and g can be hard coded at client and server. The
private/public keys can also be static on both sides of the exchange - but
if you do so then bear in mind that the agreed on secret will be the same
every time. More likely you will want to use ephemeral mode - one side
(usually the server) can have a static private/public key, whilst the
client will use a new one every time. This will ensure that a new secret is
agreed each time.

One other point to make here is that it looks very much like you are
designing your own protocol rather than implementing a well defined one.
This is fraught with security risksit is very easy to make a mistake -
and is generally a bad idea. Use standardised approaches where ever
possible. In particular note that the diffie-hellman implementation in use
here provides a raw shared secret at the end. Standardised protocols
normally define a process for turning that shared secret into something
which can be used as a key (typically by passing the secret, along with
other data through some message digest). E.g. see RFC 2631

Matt

Fwd: Diffie algorithm in openssl: and Java

2013-03-18 Thread azhar jodatti

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 both key values are different. That won't
 make any such difference :) right?


The parameters p, q and g need to be the same on both sides of the
exchange. The values for this can be agreed in advance. You do not need to
calculate them every time. If the two parties in the exchange are using
different parameters then it will not work. Each side will have different
private keys, and hence different public keys. .
p,q and g are same at both the end. let me tell how i am doing. I am
generating p,g and q at client. then I am generating private and public key
with these params. I am sending these p,g,q and public key to server and
hence server using same p,g and q to generate its private and public key.
server generates secret key with client public key and returns its public
key. client in turn use the server public key to generated its secret key.
I am generating parameter when user logs in and stays till user logout.
next time when he logs in the same procedure will happen.
You *can* generate the parameters every time - it will work as long as both
sides are using the same p, q and g values - but there is no reason to do so
I don't think i understood you completely here. but I am ok by generating
parameters every time as long as it works :) 


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.




 3) Its not actually necessary to pass the full parameters every time you
 exchange keys. This can be agreed up front, e.g. RF5114 defines a set of
 standard well known parameters which can be used off the shelf. OpenSSL
 has built-in support for these.
 I need to look into this. Do you mean the hard coded prime and base
 generator numbers at client and server? how about public key?


The values p, q and g can be hard coded at client and server. The
private/public keys can also be static on both sides of the exchange - but
if you do so then bear in mind that the agreed on secret will be the same
every time. More likely you will want to use ephemeral mode - one side
(usually the server) can have a static private/public key, whilst the
client will use a new one every time. This will ensure that a new secret is
agreed each time.
Yes, I would love to see at least this working. I will try this today,
however I still prefer dynamic values over static. :) ;)  


One other point to make here is that it looks very much like you are
designing your own protocol rather than implementing a well defined one.
This is fraught with security risksit is very easy to make a mistake -
and is generally a bad idea. Use standardised approaches where ever
possible. In particular note that the diffie-hellman implementation in use
here provides a raw shared secret at the end. Standardised protocols
normally define a process for turning that shared secret into something
which can be used as a key (typically by passing the secret, along with
other data through some message digest). E.g. see RFC 2631

I don't feel i am trying to design my own protocol. at least it won't look
so for me :) I want to use symmetric key encryption and for that I need a
same secret key at both the ends at run time. Who else does this better
than Diffie Hellman? :) :)  


Matt

Re: Diffie algorithm in openssl: and Java

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 JSON sample.

No, g is the generator and I don't believe there is a requirement for it
to be prime. In fact your Java version of your JSON has a generator which
is clearly NOT prime - it is an even number. You are missing a parameter
from your JSON.

One other point to make here is that it looks very much like you are
designing your own protocol rather than implementing a well defined one.
This is fraught with security risksit is very easy to make a mistake -
and is generally a bad idea. Use standardised approaches where ever
possible. In particular note that the diffie-hellman implementation in use
here provides a raw shared secret at the end. Standardised protocols
normally define a process for turning that shared secret into something
which can be used as a key (typically by passing the secret, along with
other data through some message digest). E.g. see RFC 2631

I don't feel i am trying to design my own protocol. at least it won't look
so for me :) I want to use symmetric key encryption and for that I need a
same secret key at both the ends at run time. Who else does this better
than Diffie Hellman? :) :)

Diffie Hellman is the algorithm, the protocol is about how you implement
and use that algorithm, e.g. taking a ridiculous example you can use the
diffie-hellman algorithm and then make it insecure by transmitting the
private key in the clear in the protocol!!

See the top answer here:
http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology

Also:
http://www.cse.chalmers.se/edu/year/2012/course/TDA601/Project/Presentations06/9.pdf

And:
Cryptographic protocols and algorithms are difficult to get right, so do
not create your own
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/crypto.html

Matt

RE: Diffie algorithm in openssl: and Java

2013-03-18 Thread Dave Thompson

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  
for generating public and private key. code below 

X509EncodedKeySpec x509Spec = new
X509EncodedKeySpec(this.clientPublicKey);
PublicKey pk = kf.generatePublic(x509Spec);

(I assume this is on the server, kf is a KeyFactory.getInstance(DH) 
and this.clientPublicKey contains client DH public key in X509-ki form.)

In spite of the name, that doesn't generate a key, it only converts it 
from an external form (X509) to an internal form JCE can use directly.

DH key(pair) generation is done with a KeyPairGenerator.getInstance(DH).
It can use parameters from several sources; which are you using?

for iPhone client I wrote a C programme which makes use of openSSl 
implementation of  DH algorithm. The problem I am facing is when 
I generate DH params (prime,generator,pulickey) at client and pass 
them to server to calculate server's public and secret key, my server 
(JAVA) throws invalidKeySpecification exception. below are steps. 

 //client is DH *client. 

 //also tried with 1024 bits and DH_GENERATOR_5

 DH_generate_parameters_ex(client,512,DH_GENERATOR_2,NULL);

You don't need to generate new parameters each time, as I said before.
And for secure sizes it's usually rather costly/slow to do so.
If you do generate new parameters, the server side Java *must* use 
parameters sent by the client as input to server KeyPairGenerator.

OTOH DH-512 is almost certainly not secure. I don't understand all 
the math, but the authorities I trust say that discrete-log (DH) is 
only a few bits better than factoring (RSA), and RSA-512 is fallen.

   2. then generating DH public and private key 
DH_generate_key(client)

That is actual key generation, like KeyPairGenerator.generate.

when I pass these (prime,generator,publickey ) generated keys to 
server which is written in JAVA , It won't work. server (JAVA) 
throws invalidKeySpecification exception.

Then you're not doing what I described. See next.

One more point I would like to mention here is, When I use 
DHPublicKeySpec instead of X509EncodedKeySpec at server (JAVA) 
it won't throw invalidKeySpecification exception. snip rest

Those are different data formats. X509EncodedKeySpec is correct 
if you have a DH public key (or other public key) *in X.509 
SubjectPublicKeyInfo format* which Openssl calls PUBKEY and 
can do with no additional code. In another email you show 
that you are using a JSON format with separate fields (which 
you didn't mention before), which contains the same data as 
X.509-keyinfo but is not even remotely the same format, 
so for your format yes DHPublicKeySpec is correct.

See other response for more about parameters and key values.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Diffie algorithm in openssl: and Java

2013-03-18 Thread Dave Thompson

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 run both programs it calculates the params (p,g,pk) every time 
on execution . that's the reason both key values are different. 
That won't make any such difference :) right? 

The parameters p, q and g need to be the same on both sides of 
the exchange. The values for this can be agreed in advance. You 
do not need to calculate them every time. 

And I would advise against doing so, because generating parameters 
is costly. But see below about q.

If the two parties in the exchange are using different parameters 
then it will not work. Each side will have different private keys, 
and hence different public keys. You *can* generate the parameters 
every time - it will work as long as both sides are using the same 
p, q and g values - but there is no reason to do so.

This isn't clear. Each side chooses keys (x,y) using the parameters, 
which as you say must be the same. With parameters the same, the 
*key* values if chosen properly (randomly) will be different.
If the parameters are (wrongly) different, the key values will 
overwhelmingly be chosen different also, but even if they are 
accidentally the same or x is forced the same, exchange doesn't 
work. And see next about q.

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 standard formats don't have 
it. DH can use l which is the *size* of q thus the (max) entropy 
of the agreement. It is sometimes convenient to use DSA parameters 
as DH parameters by ignoring q except optionally its size. 

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.

3) Its not actually necessary to pass the full parameters every time 
you exchange keys. This can be agreed up front, e.g. RF5114 defines 
a set of standard well known parameters which can be used off the shelf. 
OpenSSL has built-in support for these.

Or 2412 (Oakley) or others. There are actually two issues here:

- 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.

- 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.

I need to look into this. Do you mean the hard coded prime and 
base generator numbers at client and server? how about public key?  

The values p, q and g can be hard coded at client and server. 
The private/public keys can also be static on both sides of 
the exchange - but if you do so then bear in mind that the 
agreed on secret will be the same every time. More likely 
you will want to use ephemeral mode snip

I would suggest configured rather than hard-coded -- but the 
important point is fixed/static/long-term versus new each time.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Diffie algorithm in openssl: and Java

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 use q and standard formats don't have
 it. DH can use l which is the *size* of q thus the (max) entropy
 of the agreement. It is sometimes convenient to use DSA parameters
 as DH parameters by ignoring q except optionally its size.


Not entirely correct. I've just been digging into this when I saw your
email. PKCS 3 does not use q for DH:

DHParameter ::= SEQUENCE {
  prime INTEGER, -- p
  base INTEGER, -- g
  privateValueLength INTEGER OPTIONAL }

However, the newer X9.42 DOES require q to be present:
DomainParameters ::= Sequence {
 p INTEGER, -- odd prime, p = jq+1
 g INTEGER, -- generator, g^q = 1 mod p
 q INTEGER, -- prime factor of p-1
 j INTEGER OPTIONAL, -- cofactor, j=2
 validationParms  ValidationParms OPTIONAL
}

ValidationalParms ::= Sequence {
 seed BITSTRING, -- seed for prime generation
 pGenCounter INTEGER, -- parameter verification
}

However, it seems that OpenSSL does not support the X9.42 version.
From the notes on the dhparam man page:
OpenSSL currently only supports the older PKCS#3 DH, not the newer X9.42
DH.

All the OpenSSL built-in RFC5114 domain parameters are also defined in terms of
p, q and g.

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).

Matt

Re: Diffie algorithm in openssl: and Java