nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-30 23:53:32 +01:00
Code Issues Packages Projects Releases Wiki Activity

Add start of rransom's notes on tor crypto requirements

Browse Source
This commit is contained in:
Nick Mathewson 2010-12-14 23:22:21 -05:00
parent 9776ba7fa4
commit 1361376e14
1 changed files with 83 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
doc/spec/proposals/ideas/xxx-crypto-requirements.txt Normal file
View File

@ -0,0 +1,83 @@
This draft is intended to specify the meaning of ‘secure’ for a Tor
circuit protocol, hopefully in enough detail that
mathematically-inclined cryptographers can use this definition to
prove that a Tor circuit protocol (or component thereof) is secure
under reasonably well-accepted assumptions.
Tor's current circuit protocol consists of the CREATE, CREATED, RELAY,
DESTROY, CREATE_FAST, CREATED_FAST, and RELAY_EARLY cells (including
all subtypes of RELAY and RELAY_EARLY cells). Tor currently has two
circuit-extension handshake protocols: one consists of the CREATE and
CREATED cells; the other, used only over the TLS connection to the
first node in a circuit, consists of the CREATE_FAST and CREATED_FAST
cells.
1. Every circuit-extension handshake protocol must provide forward
secrecy -- the protocol must allow both the client and the relay to
destroy, immediately after a circuit is closed, enough key material
that no attacker who can eavesdrop on all handshake and circuit cells
and who can seize and inspect the client and relay after the circuit
is closed will be able to decrypt any non-handshake data sent along
the circuit.
In particular, the protocol must not require that a key which can be
used to decrypt non-handshake data be stored for a predetermined
period of time, as such a key must be written to persistent storage.
2. Every circuit-extension handshake protocol must specify what key
material must be used only once in order to allow unlinkability of
circuit-extension handshakes.
3. Every circuit-extension handshake protocol must authenticate the relay
to the client -- an attacker who can eavesdrop on all handshake and
circuit cells and who can participate in handshakes with the client
must not be able to determine a symmetric session key that a circuit
will use without either knowing a secret key corresponding to a
handshake-authentication public key published by the relay or breaking
a cryptosystem for which the relay published a
handshake-authentication public key.
4. Every circuit-extension handshake protocol must ensure that neither
the client nor the relay can cause the handshake to result in a
predetermined symmetric session key.
5. Every circuit-extension handshake protocol should ensure that an
attacker who can predict the relay's ephemeral secret input to the
handshake and can eavesdrop on all handshake and circuit cells, but
does not know a secret key corresponding to the
handshake-authentication public key used in the handshake, cannot
break the handshake-authentication public key's cryptosystem, and
cannot predict the client's ephemeral secret input to the handshake,
cannot predict the symmetric session keys used for the resulting
circuit.
6. The circuit protocol must specify an end-to-end flow-control
mechanism, and must allow for the addition of new mechanisms.
7. The circuit protocol should specify the statistics to be exchanged
between circuit endpoints in order to support end-to-end flow control,
and should specify how such statistics can be verified.
8. The circuit protocol should allow an endpoint to verify that the other
endpoint is participating in an end-to-end flow-control protocol
honestly.