arti/TODO

149 lines
4.3 KiB
Plaintext

KEY:
- Not done
. Partially done
o complete
X Won't do.
MILESTONE 0: Build a circuit and use it
o Read a directory from disk
o Pick random relays
o Construct a one-hop circuit with CREATE_FAST
o Construct a one-hop circuit with ntor
o Build relay cells
o Construct a multihop circuit.
o Open a stream
o Make a request, get a response (no sendmes yet)
MILESTONE 1: Refactoring on above
o Stop parameterizing all APIs on TLS type.
o Combine "create circuit" and "create first hop"?
o More types of circent for clarity.
o Improve testing
o Improve documentation
o Make sure readme is right
MILESTONE 2: Working streams
o Improve circuit API.
o Get an initial stream API together.
o Make end cells work, and get sent both ways.
- Use same ideas for circuit DESTROYs.
- Make SENDMEs work
- Make authenticated sendmes work.
- Improve testing
- Improve documentation
- Make sure readme is right
MILESTONE 3: Clean and tidy
- Less copying, esp around Box<RawCellBody>. Consider bytes crate.
- Is this "reactor" business a sensible design? Is there a better one?
- Use better types for cases when only a few messages are possible.
- Get a data-oriented stream API
- Make a plan for what closes when
- Make sure everything closes when it is supposed to.
- Refactor XXXX and TODO code; make sure everything is tested and
documented.
MILESTONE C???: Client parity (not hidden services yet, no needless junk)
- Correct path selection
- Timeouts
- Circuit timeout logic
- Connection timeout logic.
- What other kinds of timeouts?
- Downloading directory information, using compression and diffs.
- Connection padding (link protocol 5)
- Circuit padding (with padding machines)
- Optionally, expose a socks port
- Automatically build circuits
- Build preemptive circuits
- Guard nodes
- Rate-limiting
- Fairness on circuits/streams?
- CBT logic?
- Change behavior depending on network parameters
- Figure out which consensus method we require, and say so.
LATER MILESTONES:
- Client hidden service support
- Be-a-hidden-service support.
- Spec issues
- Test vectors
. Add test vectors for ntor
- Add test vectors for relay crypto
- Add test vectors for hs-ntor
- Add test vectors for hs-relay crypto
- Add test vectors for TAP
- Clarity
- END cell format
- Directory consistency
- "-----BEGIN" should not be a valid keyword
- Whitespace at start of line, y/n? Mixed whitespace, y/n? CR, y/n?
- UTF-8.
- Primitive crypto
- Wrap x25519 in a trait?
- Use signature trait for ed25519?
- Ed25519 needs to have an "identity" non-parsed version, maybe.
o Add RSA-pkcs1 signature support
o Add RSA-pem encode/decode support
- RSA-oaep, if supported and we actually want it.
o test vectors for sha1
o test vectors for sha2
o test vectors for sha3/shake
- RSA test vectors as needed
- Higher level crypto
- Test vectors for hmac
- Test vectors for tap-kdf
- Test vectors for hkdf
- Test vectors for other kdfs
- Main Protocol functionality
o encode and decode regular cell types.
. handshakes
o ntor
o fast
X TAP
. relay crypto
o implement
- tests
- Internals:
- Consider using a safer thing instead of current bytereader. Like the
one rustls has? Like "untrusted"?
- Consider using a writer trait that's agnostic about whether it's
writing into an expanding Vec or a fixed slice.
- Use "bytes" crate more natively in tor-bytes trait.
- Tests
- For all cell types
- for all relay cell types
- For all handshakes
. State for multiplexing circuits on a connection
- State for sending sendme cells, both versions.
- V1 sendmes
- State for managing streams
o Initial protocol handshake for client/relay authentication
- Initial protocol handshake for relay/relay authentication
- HS functionality
- encode and decode hs cell types
- State as needed for hs lookup
- hs cell types
- hs directory stuff
- HSv3 directory obejcts, encode
- HSv3 directory objects, decode
- crypto variants
- hsv3 variant of relay crypto
- hsv3 variant of ntor
- tests and vectors for the above.
PROBABLY NEVER:
- TAP
- Link protocols before 4.
- Older consensus milestones