Expand description
Facility for detecting and preventing replays on introduction requests.
If we were to permit the introduction point to replay the same request multiple times, it would cause the service to contact the rendezvous point again with the same rendezvous cookie as before, which could help with traffic analysis.
(This could also be a DoS vector if the introduction point decided to overload the service.)
Because we use the same introduction point keys across restarts, we need to make sure that our replay logs are already persistent. We do this by using a file on disk.
Modules§
- data 🔒
- Wrapper around a fast-ish data structure for detecting replays with some false positive rate. Bloom filters, cuckoo filters, and xorf filters are all an option here. You could even use a HashSet.
- ipt 🔒
- Code for a replay log for
Introduce2
messages. - pow 🔒
hs-pow-full
- Code for a replay log for Proof-of-Work
Nonce
s.
Structs§
- Persist
File 🔒 - Persistent state file, and associated data
- Replay
Log 🔒 - A probabilistic data structure to record fingerprints of observed Introduce2 messages.
Enums§
- LogContent
Error 🔒 - A problem that prevents us from reading a ReplayLog from disk.
- Replay
Error 🔒 - An error occurred while checking whether we’ve seen an element before.
Constants§
- MAGIC_
LEN 🔒 - The length of the
ReplayLogType::MAGIC
constant. - OUTPUT_
LEN 🔒 - The length of the message that we store on disk, in bytes.
- REPLAY_
LOG_ 🔒SUFFIX - Replay log files have a
.bin
suffix.
Traits§
- Replay
LogType 🔒 - A trait to represent a set of types that ReplayLog can be used with.
Type Aliases§
- IptReplay
Log 🔒 - A
ReplayLog
forIntroduce2
messages. - PowNonce
Replay 🔒Log hs-pow-full
- A
ReplayLog
for Proof-of-WorkNonce
s.