> Getting rid of forward secrecy doesn't fix the problem of server trust. A compromised server could always use a different private key.
Yes, but what it solves is that when it does so, you know it has been compromised.
> The only way to truly not trust the server is to verify that you can decrypt in real time.
No. That is the way to know that you can not trust the server in real time. That isn't the objective. The objective is to be able to, after the fact, prove that you could trust it at that point in time.
When a server doesn't use forward secrecy, it looks like this:
While it's working correctly (which involves you knowing the private key), you know everything it sends. If it gets compromised, it might keep using the same key and you know what it sent, or it might start using a different key and you'll never figure out what it sent while compromised.
When a server does use forward secrecy, it looks like this:
While it's working correctly (which includes logging session keys), you know everything it sends. If it gets compromised, it might keep logging session keys and you know what it sent, or it might start logging fake keys and you'll never figure out what it sent while compromised.
What meaningful difference is there?
You don't trust the server to tell you what it sent. You record what it sent, and at some point you can check if it decrypts or not. This acts the same whether or not you have FS enabled.
> The objective is to be able to, after the fact, prove that you could trust it at that point in time.
You can verify what it sent, but that doesn't prove it wasn't compromised.
There would not be a meaningful difference in terms of being able to tell if it was compromised. There would be a meaningful difference that you would now have an operational exposure of the session keys, that fundamentally undermines not just PFS but potentially the encryption protecting the session in general.
> You can verify what it sent, but that doesn't prove it wasn't compromised.
You're right. The semantics of what you are trying to prove isn't so much that it wasn't compromised, but rather to verify that there wasn't some kind of leakage of data from the system, which is a subtly different thing.
> There would be a meaningful difference that you would now have an operational exposure of the session keys, that fundamentally undermines not just PFS but potentially the encryption protecting the session in general.
That's no worse than before, where you could use the private key to undermine the encryption.
You could also end up with a much better system if you encrypted the session keys so that only the auditing device can decrypt them.
> That's no worse than before, where you could use the private key to undermine the encryption.
>
> You could also end up with a much better system if you encrypted the session keys so that only the auditing device can decrypt them.
We're speculating about the trust model and the constraints it must operate within. The private key isn't getting transmitted continuously over the network, so perhaps with some trust models transmitting session keys is equivalent, better, or worse.
Given that the people actually working in the space have clearly put a lot of thought into how to best fit their needs, I wouldn't presume that they got it wrong.
Yes, but what it solves is that when it does so, you know it has been compromised.
> The only way to truly not trust the server is to verify that you can decrypt in real time.
No. That is the way to know that you can not trust the server in real time. That isn't the objective. The objective is to be able to, after the fact, prove that you could trust it at that point in time.