lokinet/docs/proto_v0.txt

813 lines
18 KiB
Plaintext
Raw Normal View History

2017-10-27 17:22:10 +00:00
LLARP v0
2017-10-27 17:22:10 +00:00
LLARP (Low Latency Anon Routing Protocol) is a protocol for anonymizing senders and
2018-11-09 00:06:58 +00:00
recipiants of encrypted messages sent over the internet without a centralised
trusted party.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
basic structures:
all structures are key, value dictionaries encoded with bittorrent encoding
2017-10-27 17:22:10 +00:00
notation:
2017-10-27 17:22:10 +00:00
a + b is a concatanated with b
a ^ b is a bitwise XOR b
x[a:b] is a memory slice of x from index a to b
BE(x) is bittorrent encode x
BD(x) is bittorrent decode x
{ a: b, y: z } is a dictionary with two keys a and y
who's values are b and z respectively
[ a, b, c ... ] is a list containing a b c and more items in that order
"<description>" is a bytestring who's contents and length is described by the
quoted value <description>
"<value>" * N is a bytestring containing the <value> concatenated N times.
2017-10-27 17:22:10 +00:00
cryptography:
2018-04-30 11:26:01 +00:00
see crypto_v0.txt
2017-10-27 17:22:10 +00:00
---
2018-02-16 12:25:35 +00:00
wire protocol
see iwp-v0.txt
---
datastructures:
all datastructures are assumed version 0 if they lack a v value
otherwise version is provided by the v value
2018-01-30 13:38:29 +00:00
all ip addresses can be ipv4 via hybrid dual stack ipv4 mapped ipv6 addresses,
i.e ::ffff.8.8.8.8. The underlying implementation MAY implement ipv4 as native
ipv4 instead of using a hybrid dual stack.
2018-02-15 16:32:11 +00:00
net address:
net addresses are a variable length byte string, if between 7 and 15 bytes it's
treated as a dot notation ipv4 address (xxx.xxx.xxx.xxx)
if it's exactly 16 bytes it's treated as a big endian encoding ipv6 address.
address info (AI)
2018-02-15 16:32:11 +00:00
An address info (AI) defines a publically reachable endpoint
2017-10-27 17:22:10 +00:00
{
c: transport_rank_uint16,
d: "<transport dialect name>",
2018-02-16 12:30:41 +00:00
e: "<32 bytes public encryption key>",
2018-02-15 16:32:11 +00:00
i: "<net address>",
p: port_uint16,
v: 0
}
2018-02-16 12:25:35 +00:00
example iwp address info:
2018-02-15 16:32:11 +00:00
{
c: 1,
2018-02-16 12:25:35 +00:00
d: "iwp",
2018-02-16 12:30:41 +00:00
e: "<32 bytes of 0x61>",
2018-02-15 16:32:11 +00:00
i: "123.123.123.123",
p: 1234,
v: 0
}
2018-02-16 12:30:41 +00:00
bencoded form:
2018-02-22 16:48:31 +00:00
d1:ci1e1:d3:iwp1:e32:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1:d3:iwp1:i15:123.123.123.1231:pi1234e1:vi0ee
2018-02-15 16:32:11 +00:00
2018-10-04 13:03:59 +00:00
Traffic Policy (TP)
Traffic policy (TP) defines port, protocol and QoS/drop policy.
{
a: protocol_integer,
b: port_integeger,
d: drop_optional_integer,
v: 0
}
drop d is set to 1 to indicate that packets of protocol a with source port b will be dropped.
if d is 0 or not provided this traffic policy does nothing.
2017-09-28 17:02:05 +00:00
Exit Info (XI)
2018-01-30 13:38:29 +00:00
An exit info (XI) defines a exit address that can relay exit traffic to the
internet.
2017-09-28 17:02:05 +00:00
{
2018-04-04 16:10:27 +00:00
a: "<net address exit address>",
b: "<net address exit netmask>",
2018-01-29 20:02:23 +00:00
k: "<32 bytes public encryption/signing key>",
2018-10-04 13:03:59 +00:00
p: [ list, of, traffic, policies],
v: 0
2017-09-28 17:02:05 +00:00
}
2018-01-30 13:38:29 +00:00
Exit Route (XR)
An exit route (XR) define an allocated exit address and any additional
information required to access the internet via that exit address.
{
a: "<16 bytes big endian ipv6 gateway address>",
b: "<16 bytes big endian ipv6 netmask>",
c: "<16 bytes big endian ipv6 source address>",
2018-10-27 12:46:59 +00:00
l: lifetime_in_milliseconds_uint64,
2018-01-30 13:38:29 +00:00
v: 0
}
router contact (RC)
2018-04-06 15:48:28 +00:00
router's full identity
{
a: [ one, or, many, AI, here ... ],
2018-05-28 20:51:15 +00:00
k: "<32 bytes public long term identity signing key>",
n: "<optional max 32 bytes router nickname>",
2018-05-28 20:51:15 +00:00
p: "<32 bytes public path encryption key>",
2018-10-16 17:09:40 +00:00
u: next_update_needed_milliseconds_since_epoch_uint64,
2018-01-19 16:51:27 +00:00
v: 0,
2018-01-26 14:17:51 +00:00
x: [ Exit, Infos ],
2018-01-19 16:51:27 +00:00
z: "<64 bytes signature using identity key>"
}
service info (SI)
2018-04-06 15:48:28 +00:00
public information blob for a hidden service
e is the long term public encryption key
2018-04-06 15:48:28 +00:00
s is the long term public signing key
v is the protocol version
x is a nounce value for generating vanity addresses that can be omitted
2018-06-23 00:00:44 +00:00
if x is included it MUST be equal to 16 bytes
2018-04-06 15:48:28 +00:00
{
e: "<32 bytes public encryption key>",
s: "<32 bytes public signing key>",
2018-01-19 16:51:27 +00:00
v: 0,
2018-06-23 00:00:44 +00:00
x: "<optional 16 bytes nonce for vanity>"
}
service address (SA)
2018-04-06 15:48:28 +00:00
the "network address" of a hidden service, which is computed as the blake2b
256 bit hash of the public infomration blob.
HS(BE(SI))
2018-07-06 16:08:30 +00:00
when in string form it's encoded with z-base32 and uses the .loki tld
introduction (I)
2018-04-06 15:48:28 +00:00
a descriptor annoucing a path to a hidden service
k is the rc.k value of the router to contact
2018-04-06 15:48:28 +00:00
p is the path id on the router that is owned by the service
v is the protocol version
2018-10-27 12:46:59 +00:00
x is the timestamp milliseconds since epoch that this introduction expires at
2018-04-06 15:48:28 +00:00
{
k: "<32 bytes public identity key of router>",
l: advertised_path_latency_ms_uint64, (optional)
2018-06-12 12:49:23 +00:00
p: "<16 bytes path id>",
2018-01-19 16:51:27 +00:00
v: 0,
2018-10-27 12:46:59 +00:00
x: time_expires_milliseconds_since_epoch_uint64
}
introduction set (IS)
a signed set of introductions for a hidden service
a is the service info of the publisher
i is the list of introductions that this service is advertising with
k is the public key to use when doing encryption to this hidden service
2018-07-17 06:41:52 +00:00
n is a 16 byte null padded utf-8 encoded string tagging the hidden service in
2018-07-17 07:30:03 +00:00
a topic searchable via a lookup (optional)
2018-04-06 15:48:28 +00:00
v is the protocol version
w is an optinal proof of work for DoS protection (slot for future)
2018-04-06 15:48:28 +00:00
z is the signature of the entire IS where z is set to zero signed by the hidden
service's signing key.
{
2018-04-06 15:48:28 +00:00
a: SI,
2018-01-08 13:49:05 +00:00
i: [ I, I, I, ... ],
k: "<1218 bytes sntrup4591761 public key block>",
n: "<16 bytes service topic (optional)>",
t: timestamp_uint64_milliseconds_since_epoch_published_at,
2018-01-19 16:51:27 +00:00
v: 0,
w: optional proof of work,
z: "<64 bytes signature using service info signing key>"
}
2018-01-25 17:54:16 +00:00
---
Encrypted frames:
2018-02-22 20:04:42 +00:00
2018-01-25 17:54:16 +00:00
Encrypted frames are encrypted containers for link message records like LRCR.
32 bytes hmac, h
32 bytes nounce, n
32 bytes ephmeral sender's public encryption key, k
remaining bytes ciphertext, x
decryption:
0) verify hmac
S = PKE(n, k, our_RC.K)
verify h == MDS(n + k + x, S)
If the hmac verification fails the entire parent message is discarded
1) decrypt and decode
new_x = SD(S, n[0:24], x)
msg = BD(new_x)
If the decoding fails the entire parent message is discarded
encryption:
to encrypt a frame to a router with public key B.k
0) prepare nounce n, ephemeral keypair (A.k, s) and derive shared secret S
A.k, s = ECKG()
n = RAND(32)
2018-06-12 16:45:12 +00:00
S = PKE(p, A.k, B.k, n)
2018-01-25 17:54:16 +00:00
1) encode and encrypt
x = BE(msg)
new_x = SE(S, n[0:24], x)
2018-06-12 16:45:12 +00:00
2) generate message authentication
2018-01-25 17:54:16 +00:00
2018-02-16 12:24:25 +00:00
h = MDS(n + A.k + new_x, S)
2018-01-25 17:54:16 +00:00
resulting frame is h + n + A.k + new_x
---
link layer messages:
the link layer is responsible for anonymising the source and destination of
routing layer messages.
any link layer message without a key v is assumed to be version 0 otherwise
indicates the protocol version in use.
2018-01-30 13:38:29 +00:00
link introduce message (LIM)
This message MUST be the first link message sent before any others. This message
identifies the sender as having the RC contained in r. The recipiant MUST
validate the RC's signature and ensure that the public key in use is listed in
the RC.a matching the ipv6 address it originated from.
{
a: "i",
n: "<32 bytes nonce for key exhcange>",
p: uint64_milliseconds_session_period,
2018-01-30 13:38:29 +00:00
r: RC,
v: 0,
z: "<64 bytes signature of entire message by r.k>"
2018-01-30 13:38:29 +00:00
}
the link session will be kept open for p milliseconds after which
the session MUST be renegotiated.
link relay commit message (LRCM)
2018-01-30 13:38:29 +00:00
request a commit to relay traffic to another node.
{
a: "c",
c: [ list, of, encrypted, frames ],
2018-02-22 20:11:06 +00:00
v: 0
2017-10-27 17:22:10 +00:00
}
c and r MUST contain dummy records if the hop length is less than the maximum
hop length.
2018-01-25 17:54:16 +00:00
link relay commit record (LRCR)
2017-10-27 17:22:10 +00:00
2018-06-28 15:10:25 +00:00
record requesting relaying messages for 600 seconds to router
2018-02-22 20:11:06 +00:00
on network who's i is equal to RC.k and decrypt data any messages using
2018-01-19 16:51:27 +00:00
PKE(n, rc.K, c) as symettric key for encryption and decryption.
2017-10-27 17:22:10 +00:00
2018-06-28 15:10:25 +00:00
if l is provided and is less than 600 and greater than 10 then that lifespan
is used (in seconds) instead of 600 seconds.
2018-06-17 14:49:42 +00:00
if w is provided and fits the required proof of work then the lifetime of
the path is extended by w.y seconds
2017-10-27 17:22:10 +00:00
{
c: "<32 byte public encryption key used for upstream>",
2018-01-08 13:49:05 +00:00
i: "<32 byte RC.k of next hop>",
2018-06-28 15:10:25 +00:00
l: uint_optional_lifespan,
2018-01-08 13:49:05 +00:00
n: "<32 bytes nounce for key exchange>",
2018-06-22 00:25:30 +00:00
r: "<16 bytes rx path id>",
t: "<16 bytes tx path id>",
v: 0,
2018-06-17 14:49:42 +00:00
w: proof of work
}
2018-06-17 14:49:42 +00:00
w if provided is a dict with the following struct
{
2018-06-28 15:10:25 +00:00
t: time_created_seconds_since_epoch,
2018-06-17 14:49:42 +00:00
v: 0,
y: uint32_seconds_extended_lifetime,
z: "<32 bytes nonce>"
}
2018-06-17 14:49:42 +00:00
the validity of the proof of work is that given
2017-10-27 17:22:10 +00:00
2018-06-17 14:49:42 +00:00
h = HS(BE(w))
2018-06-29 12:15:15 +00:00
h has log_e(y) prefixed bytes being 0x00
2018-06-17 14:49:42 +00:00
this proof of work requirement is subject to change
2018-06-17 14:49:42 +00:00
if i is equal to RC.k then any LRDM.x values are decrypted and interpreted as
routing layer messages. This indicates that we are the farthest hop in the path.
2017-10-27 17:22:10 +00:00
link relay upstream message (LRUM)
sent to relay data via upstream direction of a previously created path.
{
a: "u",
2018-06-17 14:49:42 +00:00
p: "<16 bytes path id>",
2018-01-19 16:51:27 +00:00
v: 0,
2018-06-11 14:52:29 +00:00
x: "<N bytes encrypted x1 value>",
2018-06-17 14:49:42 +00:00
y: "<32 bytes nonce>"
}
2018-06-17 14:49:42 +00:00
x1 = SD(k, y, x)
2018-06-11 14:52:29 +00:00
2018-06-17 14:49:42 +00:00
if we are the farthest hop, process x1 as a routing message
otherwise transmit a LRUM to the next hop
{
2018-06-11 14:52:29 +00:00
a: "u",
2018-06-17 14:49:42 +00:00
p: p,
v: 0,
x: x1,
y: y ^ HS(k)
}
2018-06-11 14:52:29 +00:00
link relay downstream message (LRDM)
sent to relay data via downstream direction of a previously created path.
2018-06-17 14:49:42 +00:00
{
a: "d",
p: "<16 bytes path id>",
v: 0,
x: "<N bytes encrypted x1 value>",
y: "<32 bytes nonce>"
}
2018-06-11 14:52:29 +00:00
2018-06-17 14:49:42 +00:00
if we are the creator of the path decrypt x for each hop key k
2018-06-17 14:49:42 +00:00
x = SD(k, y, x)
2018-06-17 14:49:42 +00:00
otherwise transmit LRDM to next hop
2018-06-17 14:49:42 +00:00
x1 = SE(k, y, x)
{
2018-06-17 14:49:42 +00:00
a: "d",
p: p,
2018-01-19 16:51:27 +00:00
v: 0,
2018-06-17 14:49:42 +00:00
x: x1,
y: y ^ HS(k)
}
2018-02-06 17:02:06 +00:00
link immediate dht message (LIDM):
transfer one or more dht messages directly without a previously made path.
{
2018-05-31 23:10:48 +00:00
a: "m",
2018-06-01 14:08:54 +00:00
m: [many, dht, messages],
2018-02-22 20:11:06 +00:00
v: 0
2018-02-06 17:02:06 +00:00
}
2018-10-29 16:49:36 +00:00
2018-10-27 12:46:59 +00:00
link immediate SML message (LISM)
2018-01-19 16:51:27 +00:00
2018-10-27 12:46:59 +00:00
transfer an SML message between nodes
2018-01-19 16:51:27 +00:00
2018-10-27 12:46:59 +00:00
{
a: "s",
s: SMLMessage,
v: 0
}
----
2018-10-29 16:49:36 +00:00
Stateles Mesh Layer (SML)
As a censor circumvention method layer 4 (udp) or layer 2 (ethernet)
network bridges are used to stateless route messages to the main onion
routing network in a stateless manner such that these network bridges
can be cacsaded many layers deep. The incentive to run these would be
the ability to hide your traffic shape in the shape of others without
the need to excess node churn.
2018-10-27 12:46:59 +00:00
stateless mesh discovery protocol (SMDP)
2018-10-29 16:49:36 +00:00
protocol for detecting and discovering mesh local
topology and where the mainline network is.
2018-10-27 12:46:59 +00:00
TODO: implement me
stateless mesh layer (SML)
similar to link layer messeages but sent over the connectivity mesh layer that
uses ethernet.
SML messages MUST be contained inside a LISM when not over ethernet.
2018-02-06 17:02:06 +00:00
2018-10-29 16:49:36 +00:00
SML message MUST be routed to the recipiant if we are not the recipiant based
on the currently unspecified stateless routing protocol.
TODO: implement routing protocol :^)
2018-02-06 17:02:06 +00:00
{
a: protocol_id_uint16,
2018-10-27 12:46:59 +00:00
r: "<32 bytes public identity key of recipiant>",
s: "<32 bytes public identity key of sender>",
2018-10-29 16:49:36 +00:00
t: "<1280 bytes payload>",
2018-02-06 17:02:06 +00:00
v: 0,
2018-10-27 12:46:59 +00:00
z: "<64 bytes signature generated by sender>"
2018-02-06 17:02:06 +00:00
}
2018-10-27 12:46:59 +00:00
protocol values:
2018-02-06 17:02:06 +00:00
2018-10-27 12:46:59 +00:00
0 - mesh discovery
2018-10-29 16:49:36 +00:00
t is a SMDP frame (todo: specify me)
2018-02-06 17:02:06 +00:00
2018-10-27 12:46:59 +00:00
1 - direct chat
t is a NUL padded plaintext chat message for node opers to communicate between
nodes.
2018-02-06 17:02:06 +00:00
2018-10-29 16:49:36 +00:00
2 - relayed data packet
2018-10-27 12:46:59 +00:00
t is a udp packet relayed from a client behind a client.
2018-01-19 16:51:27 +00:00
2018-10-29 16:49:36 +00:00
3 - snode to snode direct ip traffic
t is an ip packet for "0 hop" direct ip traffic between service nodes
2018-01-19 16:51:27 +00:00
---
routing layer:
2018-01-19 16:51:27 +00:00
the routing layer provides inter network communication between the LLARP link
layer and ip (internet protocol) for exit traffic or ap (anonymous protocol) for
hidden services. replies to messages are sent back via the path they
originated from inside a LRDM. all routing messages have an S value which
provides the sequence number of the message so the messages can be ordered.
2018-01-30 13:38:29 +00:00
ipv4 addresses are allowed via ipv4 mapped ipv6 addresses, i.e. ::ffff.10.0.0.1
2018-06-21 15:46:35 +00:00
path confirm message (PCM)
2018-06-11 14:52:29 +00:00
2018-06-21 15:46:35 +00:00
sent as the first message down a path after it's built to confirm it was built
2018-06-11 14:52:29 +00:00
always the first message sent
2018-06-11 14:52:29 +00:00
{
2018-06-21 15:46:35 +00:00
A: "P",
L: uint64_milliseconds_path_lifetime,
S: 0,
T: uint64_milliseconds_sent_timestamp,
2018-06-21 15:46:35 +00:00
V: 0
}
path latency message (PLM)
a latency measurement message, reply with a PLM response if we are the far end
of a path.
2018-06-21 15:46:35 +00:00
variant 1, request, generated by the path creator:
{
A: "L",
S: uint64_sequence_number,
2018-06-21 15:46:35 +00:00
V: 0
}
variant 2, response, generated by the endpoint that recieved the request.
{
A: "L",
S: uint64_sequence_number,
T: uint64_timestamp_recieved,
2018-06-11 14:52:29 +00:00
V: 0
}
obtain exit message (OXM)
sent to an exit router to obtain ip exit traffic context.
replies are sent down the path that messages originate from.
{
2017-10-27 17:22:10 +00:00
A: "X",
2018-10-27 12:46:59 +00:00
B: [list, of, permitted, blacklisted, traffic, policies],
E: 0 for snode communication or 1 for internet access,
I: "<32 bytes signing public key for future communication>",
S: uint64_sequence_number,
2018-06-21 15:46:35 +00:00
T: uint64_transaction_id,
2018-01-19 16:51:27 +00:00
V: 0,
2018-10-27 12:46:59 +00:00
W: [list, of, required, whitelisted, traffic, policies],
2017-09-28 17:02:05 +00:00
X: lifetime_of_address_mapping_in_seconds_uint64,
2018-06-21 15:46:35 +00:00
Z: "<64 bytes signature using I>"
}
grant exit messsage (GXM)
sent in response to an OXM to grant an ip for exit traffic from an external
ip address used for exit traffic.
{
A: "G",
S: uint64_sequence_number,
2018-01-29 20:02:23 +00:00
T: transaction_id_uint64,
2018-11-14 18:02:27 +00:00
Y: "<16 byte nonce>",
V: 0,
Z: "<64 bytes signature>"
}
any TITM recieved on the same path will be forwarded out to the internet if
OXAM.E is not 0, otherwise it is interpreted as service node traffic.
2018-01-29 20:02:23 +00:00
reject exit message (RXM)
2018-01-29 20:02:23 +00:00
sent in response to an OXAM to indicate that exit traffic is not allowed or
was denied.
{
A: "J",
B: backoff_milliseconds_uint64,
2018-10-27 12:46:59 +00:00
R: [list, of, rejected, traffic, policies],
S: uint64_sequence_number,
2018-01-29 20:02:23 +00:00
T: transaction_id_uint64,
2018-11-14 18:02:27 +00:00
V: 0,
Y: "<16 byte nonce>",
Z: "<64 bytes signature>"
}
2017-09-28 17:02:05 +00:00
discarded data fragment message (DDFM)
sent in reply to TDFM when we don't have a path locally or are doing network
2018-11-14 18:02:27 +00:00
congestion control from a TITM.
{
A: "D",
P: "<16 bytes path id>",
S: uint64_sequence_number_of_fragment_dropped,
V: 0
}
transfer data fragment message (TDFM)
transfer data between paths.
{
A: "T",
P: "<16 bytes path id>",
S: uint64_sequence_number,
T: hidden_service_frame,
V: 0
}
transfer data to another path with id P on the local router place a random 32
byte and T values into y and z values into a LRDM message (respectively) and
send it in the downstream direction. if this path does not exist on the router
it is replied to with a DDFM.
hidden service data (HSD)
data sent anonymously over the network to a recipiant from a sender.
sent inside a HSFM encrypted with a shared secret.
{
a: protocol_number_uint,
d: "<N bytes payload>",
i: Introduction for reply,
n: uint_message_sequence_number,
o: N seconds until this converstation plans terminate,
s: SI of sender,
t: "<16 bytes converstation tag present only when n is 0>",
v: 0
}
2018-07-12 18:21:44 +00:00
hidden service frame (HSF)
2018-07-12 15:46:30 +00:00
TODO: document this better
2018-07-12 15:46:30 +00:00
intro message (variant 1)
2018-07-22 23:14:29 +00:00
start a new session
{
2018-06-11 14:52:29 +00:00
A: "H",
C: "<1048 bytes ciphertext block>",
2018-07-12 15:46:30 +00:00
D: "<N bytes encrypted HSD>",
N: "<32 bytes nonce for key exchange>",
V: 0,
Z: "<64 bytes signature of entire message using sender's signing key>"
}
alice (A) wants to talk to bob (B) over the network, both have hidden services
set up and are online on the network.
2018-07-22 23:14:29 +00:00
A and B are both SI.
A_sk is alice's private signing key.
2018-07-22 23:14:29 +00:00
for alice (A) to send the string "beep" to bob (B), alice picks an introduction
to use on one of her paths (I_A) such that I_A is aligning with one of bobs's
paths (I_B)
2018-07-12 15:46:30 +00:00
alice generates:
T = RAND(16)
m = {
a: 0,
d: "beep",
i: I_A,
n: 0,
s: A,
t: T,
v: 0
2018-07-12 15:46:30 +00:00
}
X = BE(m)
2018-07-12 15:46:30 +00:00
C, K = PQKE_A(I_B.k)
N = RAND(32)
D = SE(X, K, N)
2018-07-12 15:46:30 +00:00
M = {
A: "T",
P: I_B.P,
S: uint64_sequence_number,
T: {
A: "H",
C: C,
D: D,
N: N,
V: 0,
2018-09-17 13:28:26 +00:00
Z: "\x00" * 64
},
V: 0
}
Z = S(A_sk, BE(M))
2017-09-28 17:02:05 +00:00
alice transmits a TDFM to router with public key I_B.K via her path that ends
with router with public key I_B.k
2017-09-28 17:02:05 +00:00
{
A: "T",
P: I_B.P,
S: uint64_sequence_number,
T: {
A: "H",
C: C,
D: D,
N: N,
V: 0,
Z: Z
},
2018-07-12 15:46:30 +00:00
V: 0
2017-09-28 17:02:05 +00:00
}
the shared secret (S) for further message encryption is:
S = HS(K + PKE(A, B, sk, N))
given sk is the local secret encryption key used by the current hidden service
please note:
signature verification can only be done after decryption
TODO: explain bob's side too (it's invsere of alice's process)
data from a previously made session (variant 2)
transfer data on a session previously made
{
A: "H",
D: "<N bytes encrypted HSD>",
N: "<32 bytes nonce for symettric cipher>",
T: "<16 bytes converstation tag>",
V: 0,
Z: "<64 bytes signature using sender's signing key>"
}
2018-01-29 20:02:23 +00:00
2018-06-26 16:23:43 +00:00
transfer ip traffic message (TITM)
2017-09-28 17:02:05 +00:00
2018-11-14 18:02:27 +00:00
transfer ip traffic
2017-09-28 17:02:05 +00:00
{
A: "I",
S: uint64_sequence_number,
2018-01-19 16:51:27 +00:00
V: 0,
2018-09-17 13:28:26 +00:00
X: "<N bytes ip packet>",
2018-11-14 18:02:27 +00:00
Y: "<16 bytes nonce>",
2018-01-29 20:02:23 +00:00
Z: "<64 bytes signature using previously provided signing key>"
2017-09-28 17:02:05 +00:00
}
2018-09-17 13:28:26 +00:00
X is parsed as an IP packet and the source addresss is extracted.
2018-11-14 18:02:27 +00:00
Next we find the corrisponding signing key for a previously granted address
2018-01-29 20:02:23 +00:00
and use it to validate the siganture of the entire message. If the signing key
cannot be found or the signature is invalid this message is dropped, otherwise
2018-11-14 18:02:27 +00:00
the X value is sent on the appropriate network interface.
2018-01-29 20:02:23 +00:00
When we recieve an ip packet from the internet to an exit address, we put it
2018-11-14 18:02:27 +00:00
into a TITM, signed with the router's signing key and send it downstream the
2018-02-06 17:02:06 +00:00
corrisponding path in an LRDM.
2018-01-29 20:02:23 +00:00
update exit path message (UXPM)
sent from a new path by client to indicate that a previously established exit
should use the new path that this message came from.
{
A: "U",
2018-11-14 12:23:08 +00:00
P: "<16 bytes previous tx path id>",
S: uint64_sequence_number,
2018-11-14 12:23:08 +00:00
T: uint64_txid,
2018-01-29 20:02:23 +00:00
V: 0,
2018-11-14 18:02:27 +00:00
Y: "<16 bytes nonce>",
2018-01-29 20:02:23 +00:00
Z: "<64 bytes signature using previously provided signing key>"
}
close exit path message (CXPM)
2018-11-14 18:02:27 +00:00
client sends a CXPM when the exit is no longer needed or by the exit if the
exit wants to close prematurely.
also sent by exit in reply to a CXPM to confirm close.
2018-01-29 20:02:23 +00:00
{
A: "C",
S: uint64_sequence_number,
2018-01-29 20:02:23 +00:00
V: 0,
2018-11-14 18:02:27 +00:00
Y: "<16 bytes nonce>",
Z: "<64 bytes signature>"
2018-01-29 20:02:23 +00:00
}
2018-11-14 12:23:08 +00:00
update exit verify message (EXVM)
sent in reply to a UXPM to verify that the path handover was accepted
{
A: "V",
S: uint64_sequence_number,
T: uint64_txid,
2018-11-14 18:02:27 +00:00
V: 0,
Y: "<16 bytes nonce>",
Z: "<64 bytes signature>"
2018-11-14 12:23:08 +00:00
}
DHT message holder message:
wrapper message for sending many dht messages down a path.
{
A: "M",
M: [many, dht, messages, here],
S: uint64_sequence_number,
V: 0
}