> Do you mean that the verifier is allowed to know the client's or > server's keys, or only to see the encrypted session as a passive > network adversary would see it?
The verifier is allowed to know the certificate, which means a public key that is tied to a Common Name, possibly signed by an authority. The verifier must know the client's keys so it can decrypt the conversation, but not the server's private keys. I think the 'node' (client) can always forge his own side of the story unless you modify TLS, but this shouldn't matter. Maybe an example works better: The user wants to look up the frontpage of Wikipedia. The user's SlowTor client has a certificate store with trusted certificates for certain Common Names, such as Wikipedia. The client magics around and from a SlowTor node receives a TLS handshake and an encrypted HTTP response purportedly from Wikipedia, as well as the key to the response (which is not Wikipedia's private key). Can the client now verify that what the node was honest? Honest meaning that the decrypted HTTP response really came from Wikipedia. I won't even set the requirement that the response is the frontpage. Might as well be the article about the NSA or a Wikipedia 404, but using the certificate store it must be verifiable that it came from Wikipedia. How does Perfect Forward Secrecy factor into this? How does the 'implicit signing' work here? -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
