156

Diffie-Hellman is a key exchange protocol but does nothing about authentication. There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, ...


58

Tom has provided a good explanation as to why Diffie-Hellman cannot be safe against man-in-the-middling. Now this answers the OP's original question but probably leaves some readers with the (reasonable) follow-up question: Why don't we just use public-key (asymmetric) cryptography to ensure the confidentiality of our messages, and drop D-H altogether? There ...


26

First, let's go over how cipher suite negotiation works, very briefly. For example, we can use the TLS 1.2 document RFC 5246 starting at section 7.4.1.2 to see, in the short short form: ClientHello: The client tells the server which cipher suites the client supports Now the server picks one I'll discuss how to control which one it picks next! ServerHello:...


19

What you describe is not forward secrecy. Forward secrecy relates to the following property: a secured communication took place between entities A and B at some time T; the attacker recorded all the messages; at some later time T' the attacker obtains a copy of all the secret keys known to A and B; and yet, the attacker cannot recover the contents of the ...


11

Not really. PFS means that if an attacker obtains your private key in the future, they cannot use it to decrypt recorded communications in the past. They can still use it to impersonate you ("you" being your server) if they have a MitM position. This allows them to record and/or modify all the plaintext. Without the legitimate server's private key (or a ...


7

Mozilla has an online tool that will help you choose the correct cipher suite. https://mozilla.github.io/server-side-tls/ssl-config-generator/ It will let you input your server version, software version, etc. and then choose between a balance of security and legacy support.


7

Is there anything like this? There is actually a draft specifically on doing this, titled Forward Secrecy Extensions for OpenPGP. The gist of the draft is that temporary keys must be created for each message and securely deleted after they are used. This runs into a few problems. Most importantly, an OpenPGP extension will not be able to guarantee that data ...


6

PFS does, in fact, prevent reading the log files after-the-fact. The only use for a captured private key in a PFS arrangement is impersonation. You can't use it for passive snooping in any context, either after-the-fact or indeed live. This is because in a PFS configuration, the ephermal session key is generated using Diffie-Hellman between the two parties ...


5

I'm seeking to understand how Perfect Forward Secrecy (PFS) works for non SSL applications. Well, let's reiterate shortly what PFS is about: You want to prevent anyone getting your master key to be able to decrypt messages he has captured beforehand. For example, let's assume the case of SSL/TLS where the private key of the server certificate gets ...


5

Since almost all key exchange methods offered by SSH today use forward secrecy it is not enough to get the private key of the server in order to get to the session secrets and decrypt the traffic. While RSA authentication was used with SSH-1 and is also a proposed standard for SSH-2 it is usually not implemented or enabled (see ssh -Qkex for key exchange ...


4

Actually most Web sites do implement forward secrecy, i.e. at least one of the "DHE" (or "ECDHE") cipher suites. Most SSL implementations support them out of the box, and most SSL server certificates are adequate (with a DHE cipher suite, the server's key is used for a signature; but almost everybody uses RSA and almost all RSA certificates allow the key ...


4

Banks are usually not known to work in an agile way and quickly follow the latest developments. Like with lots of other large companies there is lots of paper work involved if somebody tries to change something, which costs efforts, man power, time and thus money. I don't think that a system administrator just can decide to change the ciphers. Instead it ...


4

I guess the most concise answer to this question is: They are insured. Currently industry standards don't require PFS and therefore insurances pay even if the bank had no PFS. There was a similar question on 30c3, about why the banks are using Windows XP as their operating system. Those standards can also be a reason why banks can't implement new methods ...


4

If you connect to this site with your Web browser, it will show you what protocol versions and cipher suites are supported by that browser. Notably, Firefox does not seem to support (yet) TLS 1.1 and 1.2, so this prevents it from using any cipher suite ending in "_SHA256" because these are for TLS-1.2 only. If your server is accessible from the Internet, ...


3

After a DH key exchange, both parties know what key they've computed. If no man-in-the-middle has infiltrated the connection, both parties will have the same key. If the connection has been breached, they will have different keys. If there is a means by which one party can ask the other what key it is using, the man in the middle will only be able to ...


3

PFS usually involves ephemeral keys, i.e. keys that exist for the duration of the conversation but are thrown away later. One way to do this is to create an ephemeral RSA keypair for the duration of the conversation: Alice and Bob both have long-term RSA keys, and both know each others' public keys. Alice generates a 768-bit RSA keypair. This is her ...


3

In Google Chrome: click on the padlock icon: click on "Details": click on reload: In the Security Panel, click on the URL under "Main Origin": look at value of "Key Exchange" under the "Connection" section: If the key exchange begins with "ECDHE" or "CECPQ1"1 then you have PFS. In Mozilla Firefox: click on the padlock icon: click on the expander ...


3

It's possible to enforce Forward Secrecy by listing all cipher suites that the Qualys SSLtest calls "weak" at jdk.tls.disabledAlgorithms in java.security. See Bart Mortelmans' answer at https://stackoverflow.com/questions/41237075/disabling-specific-weak-ciphers-and-enforcing-perfect-forward-secrecy-using-jvm. I ended up with this: [root@dolphin12 ~]# grep ...


2

OpenSSL naturally will prefer newer MACs for otherwise-equivalent cipher suites. For example, the lengthy openssl ciphers -v output for your cipher string starts with: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-...


2

Ok, I'm no expert in this. Maybe others can add in. But from your description, this is what I can come up with. client logs in. server issues a key, K. client keeps K in memory to encrypt log on disk as well as decrypt any log read back in memory for viewing. upon client attempt to log out, or disconnection, key K is wipe from memory. That way, the client ...


2

I have to make more precise one point in Tom Leek's answer: "In SSH, a Diffie-Hellman key exchange is used, but the server's public part (its gb mod p) is signed by the server." Actually, the whole DH key exchange is signed. Signing only gb mod p is not sufficient: one could spoof SSH server by just connecting to it and replaying [SSH-TRANS] packet later. ...


2

DH is not generally resistant to Man in the Middle attacks. If Alice and Bob (A<->B) can set up a shared secret. Then Frank can setup a shared secret with Alice (A<->F) At the same time Frank can set up a second (different) shared secret with Bob (F<->B). Frank can then decrypt A-> F messages and re-encrypt and send to bob F-> B & vice versa. ...


2

for best compatibility the cloudflare-cipher-suite is not the best; i found the following better: # suggestion from sslabs / including PFS, good compatibility #ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!...


2

I have the following in my nginx /etc/nginx/perfect-forward-secrecy.conf, which gives me an A grade on SSL labs. Your certificate should be SHA256 though. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+...


2

Solution 1. don't keep logs. this is the only 100% secure option. Problems with this approach 1. there are no logs Solution 2. Encrypt the data with the user's password as he logs in to the application, it decrypts the chat logs and on logout it encrypts and stores the logs again this requires nothing to be passed to the server. Problems with ...


2

Forward secrecy occurs when you delete all copies of a key that exist anywhere in the world, thereby converting all past communications encrypted with that key into opaque garbage (until such a time when algorithms/computers are able to crack the key). Forward secrecy requires you to set up temporary keys that are impossible for anyone (including yourself) ...


2

There is no need to use a PKI with TLS. The only thing a PKI does is to make the authentication part of TLS scale. When using self-signed certificates, PSK or similar all trust information (like certificates or pre-shared keys) need to be distributed to every communication peer in a secure way. These information need also be be kept up-to-date, i.e. when new ...


2

It depends on the capabilities of the attacker. If an attacker can compromise your device, then yes, storing the full message history obviously means they'll be able to see everything. But what if the attacker can only see communication between the users? In this case forward secrecy is still useful, as it means breaking a user's long-term key at some point ...


1

Most browsers (all the major ones) allow you to change the set of cipher suites in use. Some may require obscure ways to do this (I'm looking at you chrome) and others may depend upon the cryptography packages provided by the operating systems. Chrome, Opera and Firefox support FS pretty well out of the box. IE and Safari will require some tweaking. Check ...


Only top voted, non community-wiki answers of a minimum length are eligible