[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Aside of Tor Research Project: SlowTor



> 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 - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk