A project initiated by Google to streghten TLS' public key infrastructure (PKI).
- TLS certificates bind a public key to a domain
- These certificates are used by clients (e.g. browsers) to initiate an encrypted channel to the domain's server
- TLS certificates are issued by centralized institutions called Certificate Authorities
- (For more info, see the Let's encrypt project)
TLS certificates must initially be downloaded from somewhere. (Note that the OS and browser implementations provide a set of certificates. However, these need to be trusted as well)
But: Can you trust the new certificate? Man-in-the-middle attack is possible!
This leads to a TOFU - Trust on first use - situation
(Ever connected to a new server via SSH? This is what the scary unknown host, trust certificate? [y,n] message is about)
Build a Merkle Tree of known certificates, i.e. build a public, append-only log.
This log can be read by clients to cross-check whether their downloaded certificate is known.
The log can be trusted, because everyone can audit (fully or partially) the log.
(Note that after the initial download, the certificate can easily be cached local)
Golang's Checksum Database
- Go programs can have external dependencies, e.g. code hosted at github.
- Q: How can devs have verifiable reproducible build while downloading code from the internet?
- A: Build a Merkle Tree of go packages
"This ensures that unexpected code changes cannot be introduced when first adding a dependency to a module or when upgrading a dependency." (see initial proposal) (Note "first adding")
Learning:
- Don't TOFU!
- After initial download: Either cache data or the data's hash
Want to aidrop an amount of tokens to a set of addresses.
Q: How can an address prove it is part of the set of eligible addresses?
A:
- Post the merkle root on-chain
- Make the merkle tree publicly available
- Address can submit proof that its part of the tree leading to the merkle root
- Verify proof on-chain against merkle root