I am using AES for encryption on a java system and decrypting it back on a javascript platform. What is the best way for a secure key exchange over such system ?
As #owlstead said, there is no such thing as "best way": analyze your security and performance requirements and choose a well-tried protocol as SSL/TLS.
Note: AES is indeed a symmetric crypto-system, for key exchange we usually start with an asymmetric protocol to agree on a symmetric key. Then this key is used to protect the following communication with a symmetric protocol.
Related
I understand how a TLS connection can be secure once the shared secret can be used to encrypt the request/response, but how does TLS create the initial secure shared secret without being susceptible to man-in-the-middle attacks?
The basic idea is that there is some authentication to make sure that one is talking to the right party (typically done with certificates) and once one can be sure that it is the right peer the key exchange is done (typically Diffie Hellman). This whole handshake process is also protected against manipulation.
For the finer details please see How does SSL/TLS work?.
I have a basic understanding that HTTPS creates a secure connection between a user and a server using some sort of unique identifying code. However, if the server sends this code (or whatever it is) to the user, can't that code be intercepted and that renders the entire HTTPS just as vulnerable as HTTP?
I'm a total newbie to this area, and am interested in how it works. The current answers on Stack Overflow don't give me the full answer.
I'm not sure it's fair to say there isn't any answer on Stack Overflow to the question of how SSL works:
https://stackoverflow.com/search?q=how+does+ssl+work
Cookies work the same way over HTTPS that they do over HTTP. HTTPS is just HTTP, but with the server and client using a "shared secret" symmetric encryption key to encrypt and decrypt the data they exchange so that a third party can't intercept and read the communication.
So having said that, and largely agreeing with the advice to start reading at Wikipedia, why don't I take a quick stab at doing this a modest disservice by explaining it as briefly as I know how.
First, "SSL" is now officially obsolete since the POODLE exploit in SSLv3 will never be fixed. SSL (Secure Sockets Layer) has been succeeded by TLS (Transport Layer Security) and has really become a generic although somewhat inaccurate term referring to secure HTTP (HTTPS).
Still, SSL and TLS both use the same underlying technologies and general ideas.
There are several technologies involved, all of them complicated, and the interplay between them is complicated.
But here are the high points, jammed into a little nutshell.
SSL/TLS fundamentally relies on public/private key asymmetric encryption, in order to securely exchange a shared secret--an ephemeral (disposable, short-lived) symmetric encryption key known only to the server and the client, which the client and server then use to encrypt the messages they exchange from that point forward.
Asymmetric encryption is a big, quite sciencey topic all by itself.
a·sym·me·try
āˈsimətrē/
noun: lack of equality or equivalence between parts or aspects of something; lack of symmetry.
Assymetric encryption utilizes paired private and public keys which are derived mathematically from very large, mathematically related prime numbers.
The encryption is asymmetric because if a message is encrypted with the "private" key, it can only be decrypted by the "public" key, and vice-versa.
It is therefore absolutely critical to keep the private key private. The public key can be (indeed is) published to the world
TLS uses asymmetric encryption and a handshake protocol to create and exchange a symmetric session encryption key that is known only to the server and the client.
Asymmetric encryption is an order of magnitude slower than symmetric encryption, making it unsuitable for encrypting data for real-time communication. The other thing making it unsuitable for encrypting data for two-way communication is that anything encrypted with the server's private key can be decrypted by anybody who has possession of the public key. By definition, that's everybody.
So, committing an atrocious act of willful oversimplification; the handshake protocol basically allows the client to send an encrypted challenge that only the server can decrypt, the server can then sign that challenge with its private key and return it. The client knows both which challenge it sent, and how to verify the server's signature using the server's public key. Once the client and the server are satisfied that their communication has not been tampered with, they can securely exchange an ephemeral symmetric encryption key. Some steps may be combined to reduce the number of round trips, and different versions of the protocol, you know, differ somewhat in the details... (willfully oversimplified, remember).
There are a number of encryption protocols and key lengths that can be used, and these specifics are negotiated during the key exchange. Let's just say the client and server agree to AES encryption with a 256 bit key.
So, once the client and server have securely exchanged that 256 bit key (the size of which they negotiated), they can encrypt and exchange data securely at will using that key with the AES algorithm that they also negotiated. No other party has that ephemeral encryption key, thus no other party can decrypt the data they exchange.
Symmetric encryption is much, much faster than asymmetric encryption. As such, the performance impact of encrypting/decrypting large data transfers is virtually irrelevant.
The expensive part of HTTPS is in the initial protocol handshake and key exchange since it requires multiple round trips and a couple of rounds of super expensive asymmetric encryption. Because of this, HTTPS communication benefits enormously when the client and server reuse the same connection for multiple requests. For information on that, look into the SPDY protocol.
Finally, you should research forward secrecy and/or perfect forward secrecy. What forward secrecy does is to exchange an ephemeral public/private keypair during the handshake, then use that ephemeral public/private key pair to handshake and exchange a private symmetric key and quickly discard the ephemeral private/public keypair. What this accomplishes is protection against replay and decryption of a captured HTTPS session in the future if the web server's private key is compromised.
There are protocols that allow two parties to arrive at a shared encryption key, even though all communication between them is in the clear.
Check out the Wikipedia article on how this happens during the SSL handshake.
After they have this session key, this is used to encrypt the payload messages.
I want to decrypt https stream in my https server. I have succeeded in decrypting it which used RSA secret exchange when i have private key. But I dont know how to descryt it when it uses DHE for secret exchange because I dont have any parameters.how to get Diffie–Hellman key exchange parameters?
This should not be possible. The whole idea behind forward secrecy is that you use Diffie-Hellman key exchange because this way a captured session cannot be decrypted later, even if an attacker gets access to the private key of the certificate.
The "E" in DHE is for ephemeral. It means transient, fleeting, or temporary. The key material that you need to decrypt the conversation is not permanently stored anywhere. It's generated for a single TLS session and then discarded, ensuring that no one, even the original parties, can retroactively decrypt the conversation.
Let's say we have a Server with a private and public key, the latter available to all Clients and we have a Client who doesn't have any asymmetrical keys of his own. We want to establish secure communication between the Server and the Client and the Client has to ensure Server's authenticity. This is a pretty common situation.
Now, it is my understanding that private/public key pair is usually used in such situations only to ensure authenticity (our Client can use the Server's public key to verify the Server's authenticity). To ensure two-sided communication between the Server and the Client Diffie–Hellman key exchange is used and the communication is then based on a shared secret key.
I can't stop by wonder why Diffie-Hellman is used at all in such situations. From what I understand Public-Key Cryptography could be used to both ensure authenticity AND to share a secret key between the Client and the Server. Server can send to Client a message encoded with its private key and Client can decode it using Server's public key to confirm its identity. Furthermore Client could use the Server's public key to send a new random secret key to the Server. Only Server would know this secret key as only Server knows his private key. I know some people advice not to use a public key to both encode and decode but nobody says why.
Obviously if both Client and Server had their own public/private keys they wouldn't even need to share any secret keys, but that's not a typical situation.
So... to sum it up. Why is Diffie-Hellman used instead of Secret Key Distribution with a Public-Key Cryptography? Any advantages?
I can't stop by wonder why Diffie-Hellman is used at all in such
situations. From what I understand Public-Key Cryptography could be
used to both ensure authenticity AND to share a secret key between the
Client and the Server.
Both Diffie-Hellman and RSA key exchange (where RSA is used for encryption) can be used with SSL/TLS. This depends on the cipher suite.
Server can send to Client a message encoded with its private key and
Client can decode it using Server's public key to confirm its
identity.
This is indeed what happens with DH key exchange with RSA or DSS authentication: the server signs its DH parameters using its private key, and the client can verify the signature.
Furthermore Client could use the Server's public key to send a new
random secret key to the Server. Only Server would know this secret
key as only Server knows his private key.
This is more or less what happens with RSA key exchange: the client encrypts the pre-master secret, which only the server can decipher.
You can read about all this in the Authentication and Key Exchange section of the TLS specification (leaving aside the anonymous key exchange). The choice of cipher suites (See Appendix A.5 and C), which depends on how the client and the server have been configured, will determine the key exchange mechanism used.
Fixed DH exchange is rather rare as far as I know. Ephemeral DH (DHE cipher suites) is more common. It can provider "Perfect Forward Secrecy": even if attackers get hold of the private key, they can't decipher existing traffic, since they would also need to have the DH parameters, which are not the same for all connections. However, this has a cost in terms of performance. You can find more on this topic in this article.
. Why is Diffie-Hellman used instead of Secret Key Distribution with a Public-Key Cryptography? Any advantages?
Ans: let's assume a hacker has been tracking the all messages exchanged between client and server and saving messages , but he can not decrypt those messages because he does not know the shared symmetric key. If private key of server is revealed then in case of diffie-hellman hacker still can not decrypt the messages because diffie Hellman algorithm never send the secret key on wire instead client and server agrees on same key without sharing, it's kind of key agreement algorithm not sharing. To attack diffie Hellman man in the middle should be live and should know server private key which was used for authentication. But in our case hacker has past diffie Hellman messages, so he can not use man in the middle attack. Meanwhile server changes it's private key so there is no damage. But if we use RSA keys to share secret key then on the disclosure of server's private key hacker can get all session symmetric secret keys and can decrypt all the past messages.
If SSL is not acceptable for my app to communicate with the client, how should I encrypt the traffic? I need something fast (so public key algorithms are out of question).
I was thinking about One Time Password, but the problem is that I can not store a very long key on the mobile app because of app size restrictions. What would you recommend?
How do you know that SSL isn't acceptably fast? Have you benchmarked it? As David said, SSL only uses public-key cryptography for the setup and to establish a shared secret, which is then used as the key to quick symmetric algorithms. So before you reject SSL, you should actually test it first.