0

I am a newbie to the cryptographic world so bear with me.

Thinking of a strategy (for securing P2P data) in which server is generating a key which should be used for AES encryption between clients and sending that to multiple clients (Android, iOS, web). I was wondering should I be using encryption in sending this key over https network to clients or https can take care of this? I understand Diffie Hellman key exchange is made for the very same reason but is it an overkill?

  • Your question does not make much sense for me. If the "server is generating an AES encrypted key and sending that to multiple clients" then the key you send is already protected (as you said, it is AES encrypted) but of course the clients must have the secret to actually decrypt the key. Only, you are not asking for transferring this secret but about encrypting again the already encrypted key. It might be that your description is simple confusing since the same phrases 'key' and 'encryption' might be used for different things and actions. – Steffen Ullrich May 4 '18 at 6:36
  • 1
    @SteffenUllrich I think he meant "encryption key", not "encrypted key". – Peter Harmann May 4 '18 at 7:32
  • The suggestion of @PeterHarmann makes sense. I've edited the question to reflect what the OP probably meant. – Steffen Ullrich May 4 '18 at 8:15
1

HTTPS (or TLS in general) can be used to send the secret to the clients in a secure way, i.e. protected against sniffing and modification. But, it needs to have some form of authentication in order to protect against man in the middle attacks (which might sniff or modify the secret). Authentication is usually done with a certificate which the client must either know up-front or where the client can derive the trust because it was signed by a trusted issuer.

Diffie-Hellman alone is not enough to exchange the key since it is missing the authentication part. In fact, TLS commonly (but not always) uses Diffie-Hellman as key exchange itself but also does server authentication.

0

The initial exchange of public keys is over an insecure channel. Once both parties have the other party's public key, they can then use asymmetric crypto to agree on a symmetric key. After that, all communication is symmetrically encrypted. But notice that this depends on the initial exchange of public keys over an insecure connection. How do you know whether a third party hasn't intercepted the public key of one of the parties, substituted it's own, and subsequently forwarded messages back and forth between the two parties?

One solution is for the two legitimate parties to know each other's public keys (or the hash of each other's public keys) in advance. That's more secure, but unusual in 2018.

Another solution is for both parties to trust a third party entity, such as a certificate authority. Browsers and operating systems come prepackaged with a substantial quantity of trusted certificate authorities. A very substantial quantity. And those certificate authorities are usually businesses -- commercial enterprises with a physical presence and offices and bank accounts -- operating under the good graces of the governments that have pertinent jurisdiction over them. If such a government were to force a root certificate authority to issue a bogus intermediate certificate to the government, then that certificate would then be trusted by any Web browser that already trusted the root certificate authority. And as I pointed out, there are a LOT of trusted root certificate authorities in your browser and/or in your operating system. Each one of them is vulnerable to government-imposed coercion (or potentially even organized crime, depending on its relative impunity in that country). A compromise like this has actually happened, notably in 2011, to a cert authority named DigiNotar. This led to massive security breaches at the nation-state level.

Lastly, there is a solution of having a smaller version of the certificate authority system comprised of circles of trust, entities that are commonly recognized by communicating parties as trustworthy but deliberately selected in advance and not installed in the browser by default. Public keys could then be signed by a mutually trusted entity before they're exchanged via Diffie Hellman exchange.

The challenge is to exchange those public keys reliably before any subsequent encrypted communication occurs. Diffie Hellman is NOT a panacea.

-1

I guess, you need to use any key exchange algorithm, to make the key exchange, irrespective of the overkill(All major cryptographic algorithms have high time complexity). The HTTPS cannot help you in this context, because HTTPS will only verify the origin of the key(Your Server). It will not gurantee that the key has not been copied or stolen by anyone.

The Diffie-Hellman used in HTTPS for key exchange, is used to exchange the keys sent by the certification authority to client, which decrypts the payload receivedfrom server hence authenticates it.

Read this for more details.

  • 1
    First of all, not necessarily. More importantly, the fact that HTTPS uses DH does not automatically make it safe for key transport. For example, in this case, it may be necessary to use mutual authentication, which is not standard for HTTPS. – Peter Harmann May 4 '18 at 7:49
  • @PeterHarmann just edited it – Penguine May 4 '18 at 8:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.