BACK TO 2016 WINTER DEV MEETING NOTES PAGE
__Tor Transparency __
Goal is the detect a malicious signed consensus. Vote alone is not enough, we should put it in logs (read-only)
Certificate Transparency Explanation by Linus Document is the consensus that would be put in log servers. No need to trust the log operators because they can be monitored of course. DA could monitor the log for anything they did not issued => something is wrong. Non-DA could also monitor the logs ( look for larger consensus than usual etc).
Prototype is already in place and monitoring. A Consensus could be in one of three states (maybe_included? included? not-included?) Client sends to guards, then send it random relays for verifications.
User/relay experience:
- user would fetch the consensus + inclusion proof from the log servers
- user would need to know the log servers also (included in the client?)
Pros: Everyone can run a log. Issues: Which log to verify from client perspective? How to be sure consensus would be logged ? What to do when we have different signatures for the same content ? (log ? not log? merge? Spamming issue (could send O(n!^2) combination) but this problem is rare). Injection of toxic data (?)
Do we want Signed Certificate Timestamp ? => proof of inclusion for the future. Pb: Is it too much data again to handle for a log ? (Differents kind of logs)
Alternative:
- DA issue STH instead (replaces the log)
- Pb: Overhead for DAs ?
- Cons: Put that in CTor !!
Two considerations:
- how many hours ? (+many more questions will arise when implementation is done)
- will we break something?
Data of log could be extracted to be put online on website also.