Diffie-Hellman (D-H) key Exchange problem

Hi,
I have generated a certificate for Tomcat 6.0.14 using command:
keytool -genkeypair -alias tomcat -keyalg RSA -keysize 2048 -sigalg SHA256withRSATomcat is using JDK 1.6.0_03 with unlimited strength java cryptography extension policy
and now when I try to connect to my site using Opera 9.24 I get warring �low encryption level�. The detected protocol by Opera is TLS v1.0 256 bit AES (768 bit DHE_RSA/SHA). The problem is 768 bit DHE (Diffie-Hellman key exchange) which is used for exchanging session key, opera issue a warring when key is sorter than 900 bits � more details on:
http://my.opera.com/yngve/blog/2007/10/22/new-w-not-in-kestrel-dhe or
http://my.opera.com/community/forums/topic.dml?id=207440I have two questions:
1) How to change size of DHE key?
2) If changing size of DHE key is not possible, than how to disable DHE to get pure RSA/SHA?

I add to tomcat java options -Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA and I still got TLS v1.0 256 bit AES (768 bit DHE_RSA/SHA), but it lead me to connector configuration � after adding in server.xml:
<Connector protocol="org.apache.coyote.http11.Http11Protocol"
ciphers="TLS_RSA_WITH_AES_256_CBC_SHA" />opera gave me TLS v1.0 256 bit AES (2048 bit RSA/SHA) :) . The doc says that without this attribute all ciphers are available, maybe it overrides https.cipherSuites � either way problem solve
Cheers

Similar Messages

Diffie-Hellman Key Exchange Problem

I am working on a program that will allow encrypted communication between two parties, and I am using the Diffie-Hellman key exchange to computer their secret keys, whenever I use this algorithm the key exchange goes fine but when I try to use KeyAgreement.doPhase() to perform the final phase I get an "InvalidKeyException: Incompatible Paramters" can anyone tell me what is going on, any help is greatly appreciated:
//Server
static void DHDoKeyExchange() {
          try {
               PublicKey theirPublicKey = null;
               System.out.println("Exchanging Keys...");
               System.out.println("\t-Generating KeyPair.");
               KeyPairGenerator kpg = KeyPairGenerator.getInstance("DH");
               kpg.initialize(dhparameters);
               KeyPair keyPair = kpg.genKeyPair();
               System.out.println("\t-Exchanging.");
               theirPublicKey = (PublicKey)ois.readObject();
               oos.writeObject(keyPair.getPublic());
               KeyAgreement ka = KeyAgreement.getInstance("DH");
               ka.init(keyPair.getPrivate());
               ka.doPhase(theirPublicKey, true);
               secret = ka.generateSecret();
               System.out.println("\t-Done!\n");
          } catch(Exception e) {
               e.printStackTrace();
//Client
static void DHDoKeyExchange() {
          try {
               PublicKey theirPublicKey = null;
               System.out.println("Exchanging Keys...");
               System.out.println("\t-Generating KeyPair.");
               KeyPairGenerator kpg = KeyPairGenerator.getInstance("DH");
               kpg.initialize(dhparameters);
               KeyPair keyPair = kpg.genKeyPair();
               System.out.println("\t-Exchanging.");
               oos.writeObject(keyPair.getPublic());
               theirPublicKey = (PublicKey)ois.readObject();
               KeyAgreement ka = KeyAgreement.getInstance("DH");
               ka.init(keyPair.getPrivate());
               ka.doPhase(theirPublicKey, true);
               secret = ka.generateSecret();
               System.out.println("\t-Done!\n");
          } catch(Exception e) {
               e.printStackTrace();
     }

Given that the error is "Invalid Parameters", you might want to show us how "dhparameters" is being set up on both sides...
Grant

Question on determining key strength (Diffie-Hellman Key Exchange)

Greetings everyone!
Im working on my thesis which implements the use of the Diffie-Hellman key exchange. One problem that I encounter was how to assess and evaluate its strength given N-size of the public keys used. Does anyone know what is the recommended key size to achieve security with the Diffie-Hellman key exchange? And in what way was it determined?
Sincerely,
Paolo Ferrer

Well, Diffie-Hellman is a key exchange protocol, not a cypher. If you mean RSA, then the recommended minimum is 2048 bits. This is determined by estimating the amount of time it would take to break a shorter key by brute force. 256 bits can be broken on a PC in hours. 512 can be broken on several hundred PCs over a couple of days (this is all very rough stuff). 1024 could theoretically be broken by a computer that might be built in the next decade or so in under a decade so - or something like that. So, 2048 is the rule of thumb - but it depends what you need it for. To send a secure message to your grandmother, it's unlikely the whole world will pool their resources to learn the text of your message in 10 years.
If, on the other hand, this is an email to your Justice department's Whitehouse liaison, you might want 4096 bits.
Look up "Diffie Hellman Key Exchange" and RSA on wikipedia.org for some good references.

Cisco SSH v2 support diffie-hellman-exchange-group-sha1 ?

one of my router are scanned by Foundstone and get an alert :
""The SSH2 protocol specification requires that a SSH2 server support the
diffie-hellman-group1-sha1 key exchange algorithm. This key exchange
algorithm is considered strong, but faces a potential weakness in that the
same prime number is used for all key exchanges."
SO wanna check if cisco SSH2 can support the diffie-hellman-exchange-group-sha1? If yes, which IOS version required? ( have relevent link is appreciate)
thx..
..peter cheung

read http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_secure_shell_v2.html#wp1082528

About Diffie-Hellman Key Exchange Algorihtm

Hi... experts. I've got a problem about Diffie-Hellman Key Exchange. Is that possible to actually exchange a secret session key via Diffie-Hellman Key Exchange? or the secret session key (g^xy) is actually generated after the exchange of g^x and g^y by the two parties? My project supervisor made me confused with it, he is sure that the first case can be done. Please give me some ideas... Thanks a lot!!!
Regards,
Yating

ejp, thanks for the reply!
What is exchanged is the
means by which it can be independently and
identically calculated by both parties.That's exactly what I learn from the Diffie-Hellman algorithm, but he kept saying that he wanted me to distribute a shared secret via the key exchange. I really have no idea about what he is talking about. Do you have any ideas?
Regards,
Yating

Need help with Diffie-Hellman key-exchange protocol

How can i show that the Diffie-Hellman key-exchange protocol is vulnerable to a man-in-themiddle
attack and Devise a protocol using digital signatures which overcomes this vulnerability

Given that the error is "Invalid Parameters", you might want to show us how "dhparameters" is being set up on both sides...
Grant

Diffie Hellman Public Key from openSSL is throwing InvalidKeySpecException

Ladies and Gents,
I am trying to write a client application in Java to replace an existing client app that is written in C++. The current client and server use openSSL for the crypto. The client and server perform a Diffie Hellman Key exchange and then encrypt the data streams. Communication is via net sockets and is pure TCP.
I can get a Java app to Java app DH key exchange to work as well as a C++/openSSL app to C++/openSSL app. A problem arises when I attempt to have a Java client perform a DH Key exchange with the C++/openSSL server.
I have narrowed down the error to this codeblock (I added the line numbers for clarity):
164       KeyFactory keyFac = KeyFactory.getInstance("DH");
165       X509EncodedKeySpec dhKeySpec = new X509EncodedKeySpec(peerPublicKeyBytes);
166       DHPublicKey peerPublicKey = (DHPublicKey) keyFac.generatePublic(dhKeySpec);Here is the error thrown:
java.security.spec.InvalidKeySpecException: Inappropriate key specification
     at com.sun.crypto.provider.DHKeyFactory.engineGeneratePublic(DashoA13*..)
     at java.security.KeyFactory.generatePublic(Unknown Source)
     at jClient.crypto.DHCipher.bytesToPublicKey(DHCipher.java:166)Now based on the error given, I can guess that the format of the Public Key I received is somehow incorrect. The server sends its generated public key in the following manner:
keyLen(4 bytes), keyBytes (keyLen bytes)
Which is simple enough, so I assumed that simply stripping off the first 4 bytes off the byte[] would yield a viable PublicKey, but I get the above error.
Additionally, I have tried to modify the code to use a DHPublicKeySpec instead of a X509EncodedKeySpec:
163       KeyFactory keyFac = KeyFactory.getInstance("DH");
164       BigInteger peerPubKeyBI = new BigInteger(peerPublicKeyBytes);
165       DHPublicKeySpec dhKeySpec = new DHPublicKeySpec(peerPubKeyBI, this.p, this.g);
166       DHPublicKey peerPublicKey = (DHPublicKey) keyFac.generatePublic(dhKeySpec);This seems to accept the openSSL generated public key, but ultimately results in non-matching client and server SecretKeys.
I normally don't post for help, choosing instead to just keep hammering away at a problem till I win, but this is going on 3 weeks and I have a deadline coming up. Any help would be appreciated. If anymore information is needed, just say so.
Thanks in advance,
Dave
Edited by: claymore1977 on May 26, 2009 4:47 PM

claymore1977 wrote:
Which is simple enough, so I assumed that simply stripping off the first 4 bytes off the byte[] would yield a viable PublicKey, but I get the above error.Too simple. If you look at the Javadocs for X509EncodedKeySpec, you can see that it is much more complicated beast that contains object IDs in addition to the DH public bytes. You could try to get openssl to build the more complicated X509EncodedKeySpec, but I see below that you have found a simpler solution.
>
>
Additionally, I have tried to modify the code to use a DHPublicKeySpec instead of a X509EncodedKeySpec:
163       KeyFactory keyFac = KeyFactory.getInstance("DH");
164       BigInteger peerPubKeyBI = new BigInteger(peerPublicKeyBytes);
165       DHPublicKeySpec dhKeySpec = new DHPublicKeySpec(peerPubKeyBI, this.p, this.g);
166       DHPublicKey peerPublicKey = (DHPublicKey) keyFac.generatePublic(dhKeySpec);
This looks reasonable, the only thing I can see wrong is the BigInteger constructor you are using. If the data sent is "negative", the resulting BigInteger will be negative and you'll get wrong answers. See if using the sign=magnitude constructor works better for you, i.e. BigInteger peerPubKeyBI = new BigInteger(1, peerPublicKeyBytes);

Diffie Hellman Key Exchangeover Network

Hi. I was reading through many examples on how to generate Difie Hellman keys but they many occurs within a single class or computer and not over a network as Diffie Hellman was created for. I was wondering if there are any available source codes that allows you to perform Diffie Hellman key exchange over the network ?

See javax.crypto.KeyAgreement

Diffie Hellman Key Agreement

Hi All,
Can some one help me with a example to encrypt a string using Diffie hellman key agreement protocol
Thanks &Regards
Murali

There are plenty of samples provided with the Javadoc.

Certificate for the Diffie-Hellman Public Key

Hi all
Hey guys I have run out of ideas.I 'm trying to generate a self signed certificate for the Diffie-Hellman public key.Can anyone tell me how to do this plz.
Thanks inadvance
LundiE

Does this even make sense? What would you sign it
with? The choices provided by Sun are RSA and DSA.So you trying to tell me that its not possible to generate a self-signed certificate for the Diffie-Hellman.Becoz the way I think a certificate incorporates a public key and the certificate is signed using another keys.
Thanx once for your input
Cracker

Diffie-hellman

hello,
I encrypted my data with symetric method (DES) and I would like to protect my key transfer by Diffie-hellman method.
Diffie-hellman use this calcul: g^x * mod(p)
on my card i have this code :
public void genereCleDH(){
           clePrive = new byte[14];
           clePublic = new byte[29];
          KeyPair keypair = new KeyPair(KeyPair.ALG_EC_FP, (short)112);
          keypair.genKeyPair();
         privateKey = (ECPrivateKey) keypair.getPrivate();
         publicKey = (ECPublicKey) keypair.getPublic();
          publicKey.getW(clePublic, (short)0);
          privateKey.getS(clePrive, (short)0);
     public void envoyerClePublicDC(APDU apdu){
          apdu.setOutgoing();
          apdu.setOutgoingLength((short)clePublic.length);
          apdu.sendBytesLong(clePublic,(short) 0, (short) clePublic.length);
     }for my client I have this code:
     public byte[] initDH(){
         X509EncodedKeySpec x509KeySpec = new X509EncodedKeySpec(apdu.dataOut);
         KeyFactory keyFact = KeyFactory.getInstance("DH");
         PublicKey clientpublicKey = keyFact.generatePublic(x509KeySpec);
     DHParameterSpec dhParamSpec = (DHParameterSpec)((DHPublicKey)clientpublicKey).getParams();
        KeyPairGenerator clientKpairGen = KeyPairGenerator.getInstance("DH");
        clientKpairGen.initialize(dhParamSpec);
        KeyPair bobKpair = clientKpairGen.generateKeyPair();
        KeyAgreement clientKeyAgree = KeyAgreement.getInstance("DH");
        clientKeyAgree.init(bobKpair.getPrivate());
        clientKeyAgree.doPhase((Key) clientpublicKey, true);
        byte[] clientPubKeyEnc = bobKpair.getPublic().getEncoded();
        clientKeyAgree.doPhase((Key) clientpublicKey, true);
        byte[] bobSharedSecret = clientKeyAgree.generateSecret();
          return clientPubKeyEnc;
          return null;
     }but I have a problem at this line:
PublicKey clientpublicKey = keyFact.generatePublic(x509KeySpec);and a try catch show this error : "Inappropriate key specification".
1) The problem come from of my card or my client?
2) I send the public key data, and I built a new publicKey with X509EncodedKeySpec, but isn't it easer to give "A", "g" and "p" parameters ("x" is my private data, "A" my result of "g^x * mod(p))?
3)
{code}publicKey = (ECPublicKey) keypair.getPublic();{code}
publicKey contains my public data "A","g" and "p": but which part of the array contains each data?
4) My client (using java) can call X509EncodedKeySpec, but how can i do with my applet (when my client will send this public data)?
5) When I will have the secret key with my applet and my client, how can I use it with my DES key?
thank for your help.
Alexis

Alexis wrote:
>
The SunJCE implementation is kind enough to swallow the exception thrown by the DHPubliKey class when it attempts to decode the X.509 key data you pass in
>
I don't understand what you mean. The code snippet I posted is from OpenJDK source code. It catches any exception that is thrown from the call to create a DH public key from the X509 encoded key spec. new DHPublicKey(((X509EncodedKeySpec)keySpec).getEncoded()) If your encoding is incorrect then you will not know why. X509 encoded keys have a specific ASN.1 structure.
>
Considering you have the public key on the card, you should try using the javax.crypto.spec.DHPublicKeySpec using the three key components from the card key.
>
for that I need to know which value of my byte[] area corresponding to "y","p" and "g". In addition I think on my card I have create an elliptic curve for diffie-hellman method (KeyPair.ALG_EC_FP) and on my client (java) I use "DH" method.
So I think the problem come from the differents method used ("ALG_EC_FP" and "DH"). But I don't find " ALG_EC_FP" on java.The problem is that you are getting one component of your key (getW). Can you post the hex dump of the key you are getting back?
You would need to get 3 components of your key to use the DHKeySpec (getField getG and getW maybe?). This will give you three byte arrays representing BigIntegers that you could use to initialise your key.
Cheers,
Shane

OAKLEY 5 group in Diffie-Hellman

Hi everyone!
I'm developing an SRTP implementation using the MIKEY key exchange protocol (for compatibility with a draft on SIP crypto info exchange) and, therefore, need an implementation of the oakley 5 group of Diffie- Hellman.
My question is as follows:
If I use the following code does the paramGen use the OAKLEY 5 scheme to generate the parameters? I've tried to look at the API for information on what actually happens when inputing 1536 bit prime size, but I find nothing.
AlgorithmParameterGenerator paramGen = AlgorithmParameterGenerator.getInstance("DH");
paramGen.init(1536);I'd be grateful for any information and/or suggestions.

If I use the following code does the paramGen use the
OAKLEY 5 scheme to generate the parameters? I've
tried to look at the API for information on what
actually happens when inputing 1536 bit prime size,
but I find nothing.
AlgorithmParameterGenerator paramGen =
AlgorithmParameterGenerator.getInstance("DH");
paramGen.init(1536);
paramGen.init(1536) does not work for the default JCE Provider (the max value allowed is 1024).
I guess that the OAKLEY scheme is not used because the implementation predates OAKLEY RFC (1998), but it's better to check the source code (that you can download from http://wwws.sun.com/software/communitysource/j2se/java2/download.html
You can check also Bouncycastle's implementation, (http://www.bouncycastle.org ) but it's meant to be compatible with JCE's, so it probably does not use the OAKLEY scheme as well.

Diffie Hellman use

Guys if i use Diffie Hellman to get a number
What is the best way to use that number to encrypt the plain Text
i was thinking if the number was S, and the plaintext we could get the encrypted text E
by raisining T to the power of S mod n.
Is there an algorithm to get back to the T if you knew E and S.
If you know a better use of the number than that would be appreciated.

Diffie-Hellman is an algorithm for sharing keys between two nodes over an insecure channel. DH is only an algorithm, not an application.
In your case, assuming you want to transfer a text message securely, you need an application, not an algorithm.
I suggest you use IPSec. IPSec supports Internet Key Exchange (IKE). IKE supports DH as the key establishment algorithm.
There are IPSec application that are ready-to-use :
www.freeswan.org or www.openswan.org (the two are more-or-less the same).
To get DH working under IPSec, you will need to do is abit more work (more tricky). If all you want is to transmit a message securly between two nodes, then the easiest way is to use a pre-shared secret, which is also supported by IPSec.

Diffie-Hellman groups - ASA firewalls

Hi all,
A couple of questions I'm hoping you can help me with.
Please can you tell me where I'd change the Diffie-Hellman group for phase 1 on an ASA firewall and can this be done on the ASDM?
Also, do you have to enable PFS have to DH on phase 2?
Many thanks
Alex

Hello Alex,
You can change the Diffie-Hellman group for phase 1 on ASA by configuring the following command:
crypto isakmp policy
group
To configure the same using ASDM, go to
Configuration>Site-to-Site VPN>Connection Profiles>Add/Edit
In IPsec Settings, you will find Encryption Algorithms .Click on "Manage" icon on the right of "IKE Policy".Click OK.
Click on Add/Edit and there will be an option to change the DH Group.
And lastly in regard to the PFS query , you can enable PFS in order to have DH in phase 2.Enabling PFS will force a new DH key exchange for phase 2.
Note:It is not mandatory , its optional .If its configured on one side , then it needs to be done on the remote side as well.
Regards,
Dinesh Moudgil

Diffie-Hellman Algorithm and Man-in-the-middle attack

From the RSA Security site, it says that Diffie-Hellman Algorithm
is susceptable to the Man-in-the-middle attack, because there
is not mechanism to prove the authenticity of the public keys
being exchanged.
Is it true then, the only way to protect against this,
is the use of a signed certificate?

or rather, the only way to protect against
the attack is to authenticate before generating the
DH secret key.
signed certificates are one way of authenticating,
userid/password, hardware token, biometrics are others.
i guess you could use any of these after looking at
trade-offs between security/useability.

Diffie-Hellman (D-H) key Exchange problem

Similar Messages

Maybe you are looking for