Search Results

Search found 7 results on 1 pages for 'diffiehellman'.

Page 1/1 | 1 

• Diffie-Hellman in Silverlight

  - by cmaduro

  I am trying to devise a security scheme for encrypting the application level data between a silverlight client, and a php webservice that I created. Since I am dealing with a public website the information I am pulling from the service is public, but the information I'm submitting to the webservice is not public. There is also a back end to the website for administration, so naturally all application data being pushed and pulled from the webservice to the silverlight administration back end must also be encrypted. Silverlight does not support asymmetric encryption, which would work for the public website. Symmetric encryption would only work on the back end because users do not log in to the public website, so no password based keys could be derived. Still symmetric encryption would be great, but I cannot securely save the private key in the silverlight client. Because it would either have to be hardcoded or read from some kind of config file. None of that is considered secure. So... plan B. My final alternative would be then to implement the Diffie-Hellman algorithm, which supports symmetric encryption by means of key agreement. However Diffie-Hellman is vulnerable to man-in-the-middle attacks. In other words, there is no guarantee that either side is sure of each others identity, making it possible for communication to be intercepted and altered without the receiving party knowing about it. It is thus recommended to use a private shared key to encrypt the key agreement handshaking, so that the identity of either party is confirmed. This brings me back to my initial problem that resulted in me needing to use Diffie-Hellman, how can I use a private key in a silverlight client without hardcoding it either in the code or an xml file. I'm all out of love on this one... is there any answer to this?

  Read the article

• RSA encrypted Diffie-Hellman handshake

  - by cmaduro

  Would a RSA encrypted Diffie-Hellman handshake enable secure communication? I'm encrypting communication from a silverlight client to a php webservice. The silverlight client initiates they key agreement by sending the RSA public key encrypted DH parameters to the webservice. Only the webservice has the private key, so a MITM attack is not possible. The webservice sends plain text answer back to the client, and a key is agreed upon. This key is then used to encrypt communication between the webservice and silverlight client with AES, which is also encrypted with the RSA public key. Does anyone see a flaw?

  Read the article

• diffie-hellman ssh keyxchange

  - by Chuck

  Hi, I've set out to make a primitive SSH client in C#; you might remember me from posts such as http://stackoverflow.com/questions/2872279/c-primitive-ssh-connection-lowlevel hehe. Anyway, things are great up until the time when I initiate a DH key exchange. I've compared the traffic when I establish a ssh connection (from openssh client to openssh server), to the traffic when my client connects to the same openssh server. OpenSSH client - OpenSSH server (S for server, C for client): S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (saying hello) C: SSH-2.0-OpenSSH_5.2\r (introducing myself) C: Key Exchange Init (0x14 = 20) S: Key Exchange Init C: Diffie-Hellman GEX Request (0x22 = 34) (with DH GEX min, number of bits and max) S: Diffie-Hellman Key Exchange Reply (with P, G, etc.) C: Diffie-Hellman GEX Init S: Diffie-Hellman GEX Reply My client - OpenSSH server: S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (saying hello) C: SSH-2.0-Some_Name\r (introducing myself) C: Key Exchange Init (0x14 = 20) S: Key Exchange Init C: Diffie-Hellman GEX Request (0x22 = 34) (with DH GEX min, number of bits and max) and then a bogus TCP packet as reply (probably the server connection has been terminated after/upon GEX Request. I have yet to use AES128 (which I think is the encryption chosen, but I'm not sure how to verify this...), and I'm still sending in a non-compressed format, looking to get the P, G etc. values to make the DH calculations. So where I'm stranded is: RFC 4419 page 3 http://www.ietf.org/rfc/rfc4419.txt I've send SSH_MSG_KEY_DH_GEX_REQUEST, but the server does not respond SSH_MSG_KEX_DH_GEX_GROUP. Can anyone give me a little advice on what I'm not understanding here? Does the server not understand my GEX request (due to it expecting encryption, or?)? Any help is very much appreciated, thanks :)

  Read the article

• Selection of parameters in Diffie-Hellman

  - by allenzzzxd

  Hello, maybe it's not so proper to ask this question here... anyway, I'm trying to use the gmp library for the implementation of DH, but the problem here I got is: Once, when I was doing the tests to observe the output, although big values of prime and the private keys were selected: p was about more than 300 digits long in decimal a, b were about 100 digits long finally I got a shared secret key which was extremely small, perhaps smaller than 10^8 in decimal... This problem didn't show up many times, in fact, during all the observation, it appeared just once...but still, this was not so good at all. So I wonder if there are some methods which can avoid this... Thanx a lot

  Read the article

• Elliptic Curve Diffie-Hellman

  - by cmaduro

  Does the Elliptic curve diffie hellman calculation look any different from the standard one defined here: /* * The basic Diffie-Hellman Key Agreement Equation * * The client initiates * A = g^a mod p * * Sends (g p A) to the server * * The server calculates B * B = g^b mod p * * Sends B back to client * * The client calculates K * K = B^a mod p * * The server calucaltes K * K = A^b mod p * */ Or is it just a specific way of selecting g, a, p and b? How are g,a,p and b selected anyway?

  Read the article

• How To Generate Parameter Set for the Diffie-Hellman Key Agreement Algorithm in Android

  - by sebby_zml

  Hello everyone, I am working on mobile/server security related project. I am now stuck in generating a Diffie-Hellman key agreement part. It works fine in server side program but it is not working in mobile side. Thus, I assume that it is not compactible with Android. I used the following class to get the parameters. It returns a comma-separated string of 3 values. The first number is the prime modulus P. The second number is the base generator G. The third number is bit size of the random exponent L. My question is is there anything wrong with the code or it is not compactible for android?What kind of changes should I do? Your suggestion and guidance would be very much help for me. Thanks a lot in advance. public static String genDhParams() { try { // Create the parameter generator for a 1024-bit DH key pair AlgorithmParameterGenerator paramGen = AlgorithmParameterGenerator.getInstance("DH"); paramGen.init(1024); // Generate the parameters AlgorithmParameters params = paramGen.generateParameters(); DHParameterSpec dhSpec = (DHParameterSpec)params.getParameterSpec(DHParameterSpec.class); // Return the three values in a string return ""+dhSpec.getP()+","+dhSpec.getG()+","+dhSpec.getL(); } catch (NoSuchAlgorithmException e) { } catch (InvalidParameterSpecException e) { } return null; } Regards, Sebby

  Read the article

• Security review of an authenticated Diffie Hellman variant

  - by mtraut

  EDIT I'm still hoping for some advice on this, i tried to clarify my intentions... When i came upon device pairing in my mobile communication framework i studied a lot of papers on this topic and and also got some input from previous questions here. But, i didn't find a ready to implement protocol solution - so i invented a derivate and as i'm no crypto geek i'm not sure about the security caveats of the final solution: The main questions are Is SHA256 sufficient as a commit function? Is the addition of the shared secret as an authentication info in the commit string safe? What is the overall security of the 1024 bit group DH I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible? What may be the most promising attack (besides ripping the device out off my numb, cold hands) This is the algorithm sketch For first time pairing, a solution proposed in "Key agreement in peer-to-peer wireless networks" (DH-SC) is implemented. I based it on a commitment derived from: A fix "UUID" for the communicating entity/role (128 bit, sent at protocol start, before commitment) The public DH key (192 bit private key, based on the 1024 bit Oakley group) A 24 bit random challenge Commit is computed using SHA256 c = sha256( UUID || DH pub || Chall) Both parties exchange this commitment, open and transfer the plain content of the above values. The 24 bit random is displayed to the user for manual authentication DH session key (128 bytes, see above) is computed When the user opts for persistent pairing, the session key is stored with the remote UUID as a shared secret Next time devices connect, commit is computed by additionally hashing the previous DH session key before the random challenge. For sure it is not transfered when opening. c = sha256( UUID || DH pub || DH sess || Chall) Now the user is not bothered authenticating when the local party can derive the same commitment using his own, stored previous DH session key. After succesful connection the new DH session key becomes the new shared secret. As this does not exactly fit the protocols i found so far (and as such their security proofs), i'd be very interested to get an opinion from some more crypto enabled guys here. BTW. i did read about the "EKE" protocol, but i'm not sure what the extra security level is.

  Read the article

1