5 ms·
Do you mean that you can prove to a third party that a TLS transcript is accurate? Then the answer is no. TLS authenticates application data with a symmetric al
by fweimer 2y ago
Do you mean that you can prove to a third party that a TLS transcript is accurate? Then the answer is no. TLS authenticates application data with a symmetric algorithm based on a negotiated secret. To verify authenticity, you need to disclose that secret, but you can also use the secret to authenticate a made-up application data stream. I think it's still possible to prove that a decryption is correct if everyone agrees that the ciphertext is genuine, but that's the extent of it.
- k__ 2y agoI feared so, thanks. I was hoping responses were signed.
- rocqua 2y agoIt is technically possible to verify the authenticity of a TLS transcript without disclosing the secret key. You would need a zero knowledge proof. Where you prove that you know a key that is consistent with the TLS handshake and that is consistent with the symmetric part of TLS. If the cipher suite used has authenticity in the symmetric part, that proof would be enough. There are no implementations of this to my knowledge, and all the general zero knowledge proof caveats of speed, proof-size, etc all still apply. It is definitely possible though. It would be cool to make. Why would anyone need this though?
- fweimer 2y agoThat's what I meant with a common understanding of what the ciphertext is. I don't think this is possible if all you have is your own recording of the ciphertext, with no proof that it was actually transferred over the wire. This is the typical situation with packet capturing at one endpoint only.
- k__ 2y agoA few days, I read that someone claims to do that. But there was no background info. Just "We use ZKP to prove we got the right data" So, it's technically possible?
- paulgrubbs 2y agoSee https://eprint.iacr.org/2023/1022 https://eprint.iacr.org/2023/1022. Not only is it implemented, it is reasonably efficient (e.g., on the order of a couple seconds)
- fweimer 2y agoThis seems to be the other direction. I assume the question was about extracting a cryptographic proof from a TLS session that (say) a bank statement downloaded over HTTPS (in HTML, no API) has not been tampered with. I really doubt this is possible, and quite a few TLS users would treat such an unexpected non-repudiation property as a vulnerability in TLS.
- k__ 2y agoYes, as far as I understood DH, the symmetrical keys don't have any mathematicial relation to the asymmetrical ones. I guess, the only reliable way is to sign the response, which requires changes to the server
- rocqua 2y agoWhat do you mean? The asymmetric ephemeral keys used in a TLS handhake with Diffie Helman result rather directly into the symmetric session key used by TLS. The signature of the handshake with the certificate links the ephemeral keys to the certificate, and hence the symmetric session key is linked mathematically to the certificate.
- k__ 2y agoWhat I wanted to say is, the session key isn't generated from the private keys of either party. If I sign any data, it's mathematically linked to the certificate, but that doesn't mean the cert was involved in creating the data.
- rocqua 2y agoThe TLS session, and the 'secret inputs' to the TLS handshake, will always give proof that the received message originated from a TLS session from someone who held the private key to the used certificate. Or from someone who received a session key from that private key holder. If you want to fix this, you need the authenticity of the ciphertext to be proven to the recipient without the recipient being able to transfer it. An interactive zero knowledge proof could maybe do that.