2026-08-03
Ethereum smart contracts cannot trustlessly verify authenticity of web data (by verifying TLS and CA chain-of-trust) or emails (by verifying DKIM headers)
Disclaimer
Main
- My motivation for looking into this was to solve the oracle problem for a specific use case. My specific use case involves using an ethereum smart contract to trustlessly verify whether certain information has been leaked from an organisation (by a whistleblower, hacker, OSINT researcher or similar), who the leaker is, and then pay the leaker for doing this leak.
- I looked into various ways of doing this verification trustlessly.
- If the leaker leaks emails from domain openbrain.com, then these emails will have DKIM headers signed by openbrain.com.
- If the leak has been covered by a popular news website like reuters, then their posts will be signed with TLS signatures from reuters.com, which are part of the CA chain-of-trust.
- I was hoping that an ethereum smart contract would be able to verify these signatures directly, hence trustlessly identify that leak happened and what the ethereum address of the leaker is.
- I think the first post by Hendrik Eeckhaut explains very well why this is going to fail, in the case of verifying TLS and CA chain-of-trust on the blockchain:
- Main issue: Authenticity of SSL connections cannot be proved after the fact. They can only be proved to a third-party who is sitting inside the connection while it is happening in real time. This third-party can be a single person or ideally a group of people. This group of people can then attest to this to the blockchain, but you are now trusting this group of people to honestly report what happened during the SSL connection. You are again back to N/2-of-N trust assumption among this group.
- Another minor issue: In theory, it is possible for Alice and Bob to both visit
reuters.com/lorem/ipsum/index.html and for Reuters to respond to both of them with two different posts, both signed via SSL. Alice and Bob will both end up with different results to report to the ethereum smart contract.
- I think the link by Vitalik Buterin explains why even ZKemail has limits to how trustworthy it is.
- Emails have signatures in their DKIM headers.
- It is recommended practise for email providers to rotate their signing keys for the DKIM headers every few months, as pointed out by the post from Vitalik linked above. You can use an SSL connection to verify what the signing keys are, but this again devolves into the problem listed above.
P.S.
My current understanding (could be incorrect) of the steps in a modern TLS 1.3 connection
- Client generates an ECDHE (elliptic curve diffie helman) privkey and pubkey
- Client sends the ECDHE pubkey in plaintext to server over unencrypted connection (they already know the server's IP because of DNS, that part is not covered here)
- Server generates an ECDHE privkey and pubkey
- Server signs this ECDHE pubkey using their ECDSA private key. ECDSA pubkey is already public and verifiably belongs to openbrain.com via chain-of-trust all the way to root CA.
- Server sends this signed ECDHE pubkey to client.
- Client verifies the server's ECDA signature using chain-of-trust to root CA. (Typically they already have many trusted CAs saved in browser).
- Client uses both client and server ECDHE pubkeys to compute a shared ECDHE secret. Client uses this secret to compute keys for AEAD. Typically this is an AES-128-GCM key.
- Server also uses both client and server ECDHE pubkeys to compute the same shared ECDHE secret. Server uses this secret to compute keys for AEAD, and obtain the same AES-128-GCM-key as the client.
- Now either client or server can send TCP packets to other, encrypted and authenticated using this key.
- In older connections, encryption and authentication were done separately. Authentication was done by generating a MAC by computing SHA256 on the message and AES key. See also: Wikipedia: Encrypt-then-MAC, Cryptographic doom principle by Moxie Marlinspike
- Nowadays, encryption and authentication are done together in a single operation. See also: Wikipedia: AES-128-GCM
Looking at this makes it even more clear to me why a third-party (not involved in ECDHE key generation process) has no reason to trust the ECDHE shared secret or anything encrypted or authenticated by keys ultimately derived from the ECDHE shared secret. Also, an ethereum smart contract cannot directly participate in ECDHE key generation directly because a smart contract (i.e. thousands of ethereum nodes) cannot keep a secret.
P.S.
- Big thanks to Ethereum Foundation for doing most of the research behind this post.
Subscribe
Enter email or phone number to subscribe. You will receive atmost one update per month.
Alternatively, you can subscribe via RSS, or a third-party service like blogtrottr
Comment
Enter comment