3 ms·

See 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

See 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 ago
This 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 ago
  Yes, 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 ago
    What 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 ago
      What 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 ago
  The 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.

See 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 ago

This 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 ago
Yes, 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 ago
  What 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 ago
    What 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 ago
The 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.