1
1
Fork 0
mirror of https://github.com/oxen-io/lokinet synced 2023-12-14 06:53:00 +01:00
lokinet/doc/proto_v0.txt

656 lines
15 KiB
Plaintext
Raw Normal View History

2017-10-27 19:22:10 +02:00
LLARP v0
2017-10-27 19:22:10 +02:00
LLARP (Low Latency Anon Routing Protocol) is a protocol for anonymizing senders and
recipiants of encrypted messages sent over the internet without a centralied
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 19:22:10 +02:00
notation:
2017-10-27 19:22:10 +02: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 19:22:10 +02:00
cryptography:
2018-04-30 13:26:01 +02:00
see crypto_v0.txt
2017-10-27 19:22:10 +02:00
---
2018-02-16 13:25:35 +01: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 14:38:29 +01: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 17:32:11 +01: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 17:32:11 +01:00
An address info (AI) defines a publically reachable endpoint
2017-10-27 19:22:10 +02:00
{
c: transport_rank_uint16,
d: "<transport dialect name>",
2018-02-16 13:30:41 +01:00
e: "<32 bytes public encryption key>",
2018-02-15 17:32:11 +01:00
i: "<net address>",
p: port_uint16,
v: 0
}
2018-02-16 13:25:35 +01:00
example iwp address info:
2018-02-15 17:32:11 +01:00
{
c: 1,
2018-02-16 13:25:35 +01:00
d: "iwp",
2018-02-16 13:30:41 +01:00
e: "<32 bytes of 0x61>",
2018-02-15 17:32:11 +01:00
i: "123.123.123.123",
p: 1234,
v: 0
}
2018-02-16 13:30:41 +01:00
bencoded form:
2018-02-22 17:48:31 +01:00
d1:ci1e1:d3:iwp1:e32:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1:d3:iwp1:i15:123.123.123.1231:pi1234e1:vi0ee
2018-02-15 17:32:11 +01:00
2017-09-28 19:02:05 +02:00
Exit Info (XI)
2018-01-30 14:38:29 +01:00
An exit info (XI) defines a exit address that can relay exit traffic to the
internet.
2017-09-28 19:02:05 +02:00
{
2018-04-04 18:10:27 +02:00
a: "<net address exit address>",
b: "<net address exit netmask>",
2018-01-29 21:02:23 +01:00
k: "<32 bytes public encryption/signing key>",
v: 0
2017-09-28 19:02:05 +02:00
}
2018-01-30 14:38:29 +01: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-04-04 18:10:27 +02:00
l: lifetime_in_seconds_uint64,
2018-01-30 14:38:29 +01:00
v: 0
}
router contact (RC)
2018-04-06 17:48:28 +02:00
router's full identity
{
a: [ one, or, many, AI, here ... ],
2018-05-28 22:51:15 +02:00
k: "<32 bytes public long term identity signing key>",
p: "<32 bytes public path encryption key>",
2018-01-30 14:38:29 +01:00
u: last_updated_seconds_since_epoch_uint64,
2018-01-19 17:51:27 +01:00
v: 0,
2018-01-26 15:17:51 +01:00
x: [ Exit, Infos ],
2018-01-19 17:51:27 +01:00
z: "<64 bytes signature using identity key>"
}
service info (SI)
2018-04-06 17:48:28 +02:00
public information blob for a hidden service
e is the long term public encryption key
2018-04-06 17:48:28 +02: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
if x is included it MUST be less than or equal to 16 bytes, any larger and it is
considered invalid.
{
e: "<32 bytes public encryption key>",
s: "<32 bytes public signing key>",
2018-01-19 17:51:27 +01:00
v: 0,
x: "<optional nounce for vanity>"
}
service address (SA)
2018-04-06 17:48:28 +02: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))
2017-10-27 19:22:10 +02:00
introducer (I)
2018-04-06 17:48:28 +02:00
a descriptor annoucing a path to a hidden service
k is the rc.k value of the router to contact
2018-04-06 17:48:28 +02:00
p is the path id on the router that is owned by the service
v is the protocol version
x is the timestamp seconds since epoch that this introducer expires at
{
k: "<32 bytes public identity key of router>",
2018-06-12 14:49:23 +02:00
p: "<16 bytes path id>",
2018-01-19 17:51:27 +01:00
v: 0,
x: time_expires_seconds_since_epoch_uint64
}
2017-10-27 19:22:10 +02:00
introducer set (IS)
2018-04-06 17:48:28 +02:00
a signed set of introducers for a hidden service
a is the service info
i is the list of introducers that this service is advertising with
v is the protocol version
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 17:48:28 +02:00
a: SI,
2018-01-08 14:49:05 +01:00
i: [ I, I, I, ... ],
2018-01-19 17:51:27 +01:00
v: 0,
z: "<64 bytes signature using service info signing key>"
}
2018-01-25 18:54:16 +01:00
---
Encrypted frames:
2018-02-22 21:04:42 +01:00
{
v: 0,
2018-02-22 21:05:09 +01:00
w: "<32+32+32+N bytes payload>"
2018-02-22 21:04:42 +01:00
}
2018-01-25 18:54:16 +01: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)
S = PKE(p, A.k, B.k)
1) encode and encrypt
x = BE(msg)
new_x = SE(S, n[0:24], x)
2) generate hmac
2018-02-16 13:24:25 +01:00
h = MDS(n + A.k + new_x, S)
2018-01-25 18:54:16 +01: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 14:38:29 +01: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.
2018-05-19 15:36:42 +02:00
if r is not present in sessions made by clients.
2018-01-30 14:38:29 +01:00
{
a: "i",
r: RC,
v: 0
}
link relay commit message (LRCM)
2018-01-30 14:38:29 +01:00
request a commit to relay traffic to another node.
{
a: "c",
c: [ list, of, encrypted, frames ],
f: encrypted data for last hop ,
r: [ list, of, encrypted, acks ],
2018-02-22 21:11:06 +01:00
v: 0
2017-10-27 19:22:10 +02:00
}
c and r MUST contain dummy records if the hop length is less than the maximum
hop length.
2018-01-19 17:51:27 +01:00
2018-01-25 18:54:16 +01:00
link relay commit record (LRCR)
2017-10-27 19:22:10 +02:00
record requesting path with id p relay messages for 600 seconds to router
2018-02-22 21:11:06 +01:00
on network who's i is equal to RC.k and decrypt data any messages using
2018-01-19 17:51:27 +01:00
PKE(n, rc.K, c) as symettric key for encryption and decryption.
2017-10-27 19:22:10 +02:00
additionally an ephemeral encryption keypair is made for the downstream
direction.
2017-10-27 19:22:10 +02:00
{
c: "<32 byte public encryption key used for upstream>",
2018-01-08 14:49:05 +01:00
i: "<32 byte RC.k of next hop>",
n: "<32 bytes nounce for key exchange>",
p: "<16 bytes tx path id>",
s: "<32 bytes symmettric key for encrypting reply downstream public key>",
u: "<24 bytes nonce for encrypting reply downstream public key>",
v: 0,
w: proof of work (optional),
}
2017-10-27 19:22:10 +02:00
if i is equal to RC.k then any LRDM.z values are decrypted and interpreted as
routing layer messages. This indicates that we are the farthest hop in the path.
if we are the farthest hop s and u MUST be present and discarded.
we decrypt the encrypted frame f, as encrypted to RC.e
2017-10-27 19:22:10 +02:00
if i is not equal to RC.k then forward the LRCM with first element removed
and the last element holding our hop's LRAR, encrypted via
x = SE(s, u, LRAR)
h = MDS(x, s)
h + x is stored as the ack and appended to the end of r and the first element of
r is removed.
2018-05-30 22:53:55 +02:00
link relay acknowledgement record (LRAR)
{
c: "<32 bytes public encryption key>",
r: "<16 bytes rx path id>",
}
all parameters in the LRAR are chosen by the hop
it puts an association (rxid, next_hop) -> ( prev_hop, LRAR.c )
when we get an LCAM from next_hop with rxid we will know the parameters for it.
2017-10-27 19:22:10 +02:00
plaintext contents of f is:
[ PRI, PRI, PRI ...]
path reply info (PRI):
2018-05-30 22:53:55 +02:00
{
n: "<24 bytes nonce>",
s: "<32 bytes symmettric key>",
v: 0
2018-05-30 22:53:55 +02:00
}
link commit acknowledgement message (LCAM)
sent in the opposite direction of an LRCM by the farthest hop in the path.
this establishes the downstream keys.
{
a: "a",
c: [ list, of, encrypted, LCAR],
l: encrypted frame for path creator,
2018-06-11 16:52:29 +02:00
t: "<16 bytes tx hop>",
v: 0
}
the recipiant's public key for frame encryption of l is obtained from the LRCM's
last hop frame. the sender's public key is RC.e of the farthest hop.
each entry in c is encrypted using the symettric key and nonce provided from the
corrisponding LRCM previously received.
link commit acknowledgement record (LCAR)
a record in an LCAM
2017-10-27 19:22:10 +02:00
{
c: "<32 bytes public encryption key for downstream traffic>",
n: "<32 bytes nonce for kdf>",
r: "<16 bytes next rx path id>",
2018-02-22 21:11:06 +01:00
v: 0
2017-10-27 19:22:10 +02:00
}
downstream key is generated via:
k_down = PKE(LRAR.c, LCAM.c, LCAM.n)
next a LCAM is sent to prev_hop with LCAR.r as rxid with the first element
popped off and the last element filled with random.
2017-10-27 19:22:10 +02:00
link relay upstream message (LRUM)
sent to relay data via upstream direction of a previously created path.
{
a: "u",
p: "<16 bytes tx path id>",
2018-01-19 17:51:27 +01:00
v: 0,
2018-06-11 16:52:29 +02:00
x: "<N bytes encrypted x1 value>",
y: "<32 bytes nonce>",
z: "<discard>"
}
2018-06-11 16:52:29 +02:00
plaintext x1 is a routing message
2018-06-11 16:52:29 +02:00
x1 = BD(SD(k_up, y[0:24], x))
new_y = HS(y + k_up)
verify new_y == x1.n
in the event we get a path data message (PDM), transmit a LRUM to next hop
{
2018-06-11 16:52:29 +02:00
a: "u",
p: x1.P,
v: x1.V,
x: x1.D,
y: x1.N,
z: RAND(x1.R)
}
2018-06-11 16:52:29 +02:00
if we are the farthest hop, process x1 as a routing message
link relay downstream message (LRDM)
sent to relay data via downstream direction of a previously created path.
same as LRUM but a is 'd' and p/x1.p refer to the rx path id
link relay exit message (LRXM) [under construction]
sent to exit a previously commited path before it expires.
verify signature using cancel key c in relay commit message.
2018-01-08 14:49:05 +01:00
{
a: "x",
b: [ list, of, ecrypted, exit, records ],
2018-02-22 21:11:06 +01:00
v: 0
2018-01-08 14:49:05 +01:00
}
2018-01-08 14:49:05 +01:00
link relay exit record (LRXR)
{
2018-01-08 14:49:05 +01:00
c: "x",
p: "<16 bytes tx path id>",
2018-01-19 17:51:27 +01:00
v: 0,
2018-01-08 14:49:05 +01:00
x: "<N bytes padding>",
z: "<64 bytes signature>"
}
2018-02-06 18:02:06 +01:00
link immediate dht message (LIDM):
transfer one or more dht messages directly without a previously made path.
{
2018-06-01 01:10:48 +02:00
a: "m",
2018-06-01 16:08:54 +02:00
m: [many, dht, messages],
2018-02-22 21:11:06 +01:00
v: 0
2018-02-06 18:02:06 +01:00
}
2018-01-19 17:51:27 +01:00
2018-02-06 18:02:06 +01:00
link stateless relay message (LSRM)
2018-01-19 17:51:27 +01:00
2018-02-06 18:02:06 +01:00
statelessly relay a link message.
{
a: "r",
c: r_counter_uint8,
2018-02-06 18:02:06 +01:00
d: "<32 bytes rc.K of destination>",
s: "<32 bytes rc.K of source>",
v: 0,
x: "<N bytes encrypted link message>",
y: "<24 bytes nounce>",
z: "<64 bytes signature>"
}
ONLY exchanged over ethernet, if recieved from an IP link it MUST be discarded.
relay an encrypted link message from source s to destination d.
check signature z using public key s and discard if invalid signature.
if d is equal to ourRC.k then decrypt x via SD(KE(d, s), y, x) and process it as
a link message. if the inner decrypted link message is a LRCM forward all
following LRUM, LRDM and LRSM to s via a LSRM. LIDM and LSRM are discarded.
if d is not equal to ourRC.k then forward it to an ethernet peer that is cloeser
to d than you are. if you are closer to d than all of your other ethernet peers
then increment c and send to the ethernet peer with the lowest detected latency
that isn't the peer that this message was recieved from but ONLY if c is less
than 128. if c is equal to or greater than 128 then the message is discarded.
2018-01-19 17:51:27 +01:00
---
routing layer:
2018-01-19 17:51:27 +01: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.
2018-01-30 14:38:29 +01:00
ipv4 addresses are allowed via ipv4 mapped ipv6 addresses, i.e. ::ffff.10.0.0.1
2018-06-11 16:52:29 +02:00
path data message (PDM)
intermediate path data
forward N as LRUM if we got it in a LRUM
forward N as LRDM if we got it in a LRDM
{
A: "D",
D: "<N bytes payload here>",
N: "<32 bytes next nonce>",
P: "<16 bytes next path id>",
R: number_of_bytes_Z_padding,
V: 0
}
obtain exit address message (OXAM)
sent to an exit router to obtain a NAT ip address for ip exit traffic.
replies are sent down the path that messages originate from.
{
2017-10-27 19:22:10 +02:00
A: "X",
I: "<32 bytes signing public key for future communication>",
2018-01-19 17:51:27 +01:00
V: 0,
2017-09-28 19:02:05 +02:00
X: lifetime_of_address_mapping_in_seconds_uint64,
}
grant exit address messsage (GXAM)
2018-01-29 21:02:23 +01:00
sent in response to an OXAM to grant an ip for exit traffic from an external
ip address used for exit traffic.
{
A: "G",
2018-01-30 14:38:29 +01:00
E: XR,
I: "<32 bytes signing public key of requester>",
2018-01-29 21:02:23 +01:00
T: transaction_id_uint64,
2018-01-19 17:51:27 +01:00
V: 0,
2018-01-29 21:02:23 +01:00
Z: "<64 bytes signature using exit info's signing key>"
}
2018-01-30 14:38:29 +01:00
E contains an exit route that was granted to the requester that can be used with
2018-01-29 21:02:23 +01:00
IP exit traffic.
2018-01-30 14:38:29 +01:00
The requester will now have any ip traffic going to address S forwarded to them
via the path that originally sent the OXAM and any TDFM will is recieved on the
same path will be forwarded out to the internet, given that they have
2018-01-29 21:02:23 +01:00
valid signatures and addresses.
reject exit address message (RXAM)
2018-01-29 21:02:23 +01:00
sent in response to an OXAM to indicate that exit traffic is not allowed or
was denied.
{
A: "R",
B: backoff_milliseconds_uint64,
I: "<32 bytes signing public key of requester>",
R: "<optional reject metadata>",
2018-01-29 21:02:23 +01:00
T: transaction_id_uint64,
2018-01-19 17:51:27 +01:00
V: 0,
2018-01-29 21:02:23 +01:00
Z: "<64 bytes signature signed by exit info's signing key>"
}
2018-01-29 21:02:23 +01:00
B is set to a backoff value.
R contains additional metadata text describing why the exit was rejected.
2017-09-28 19:02:05 +02:00
hidden service data message (HSDM)
signed data sent anonymously over the network to a recipiant from a sender.
sent inside a TDFM encrypted to the hidden service's public encryption key.
{
2018-06-11 16:52:29 +02:00
A: "H",
H: "<payload bytes>",
I: Introducer for reply,
R: SA of recipiant,
S: SI of sender,
V: 0,
Z: "<64 bytes signature from sender of the entire message>"
}
2017-09-28 19:02:05 +02:00
transfer data fragment message (TDFM)
variant 1 (with path id):
2018-01-29 21:02:23 +01:00
transfer data between paths.
2017-09-28 19:02:05 +02:00
{
A: "T",
P: path_id_uint64,
2018-01-19 17:51:27 +01:00
V: 0,
2017-09-28 19:02:05 +02:00
X: "<N bytes payload>",
2017-10-27 19:22:10 +02:00
Y: "<24 bytes nounce>",
2018-02-22 21:11:06 +01:00
Z: "<64 bytes signature>"
2017-09-28 19:02:05 +02:00
}
2018-01-29 21:02:23 +01:00
transfer data to another path with id P on the local router place Y and X values
into y and z values into a LRDM message (respectively) and send it in the
downstream direction.
2017-09-28 19:02:05 +02:00
variant 2 (no path id):
transfer ip traffic for exit
{
A: "T",
2018-01-19 17:51:27 +01:00
V: 0,
2017-10-27 19:22:10 +02:00
X: "<N bytes ipv6 packet>",
2018-01-29 21:02:23 +01:00
Y: "<16 bytes nounce>",
Z: "<64 bytes signature using previously provided signing key>"
2017-09-28 19:02:05 +02:00
}
2018-01-29 21:02:23 +01:00
X is parsed as an IPv6 packet and the source addresss is extracted.
Next we find the corrisponding signing key for a previously granted exit address
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
the X value is sent on the appropriate exit network interface.
When we recieve an ip packet from the internet to an exit address, we put it
into a TDFM, signed with the exit info's signing key and send it downstream the
2018-02-06 18:02:06 +01:00
corrisponding path in an LRDM.
2018-01-29 21:02:23 +01: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",
T: transaction_id_uint64,
V: 0,
Y: "<16 bytes nounce>",
Z: "<64 bytes signature using previously provided signing key>"
}
T is the transaction ID from the GXAM
close exit path message (CXPM)
client sends a CXPM when the exit is no longer needed.
The address used in exit MAY be reused later.
{
A: "C",
T: transaction_id_uint64,
V: 0,
Y: "<16 bytes nounce>",
Z: "<64 bytes signagure using previously provided signing key>"
}