LLARP v0 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 notation: 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 "" is a bytestring who's contents and length is described by the quoted value "" * N is a bytestring containing the concatenated N times. cryptography: see crypto_v0.txt --- 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 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. 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) An address info (AI) defines a publically reachable endpoint { c: transport_rank_uint16, d: "", e: "<32 bytes public encryption key>", i: "", p: port_uint16, v: 0 } example iwp address info: { c: 1, d: "iwp", e: "<32 bytes of 0x61>", i: "123.123.123.123", p: 1234, v: 0 } bencoded form: d1:ci1e1:d3:iwp1:e32:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1:d3:iwp1:i15:123.123.123.1231:pi1234e1:vi0ee Exit Info (XI) An exit info (XI) defines a exit address that can relay exit traffic to the internet. { a: "", b: "", k: "<32 bytes public encryption/signing key>", v: 0 } 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>", l: lifetime_in_seconds_uint64, v: 0 } router contact (RC) router's full identity { a: [ one, or, many, AI, here ... ], k: "<32 bytes public signing/encryption identity key>", u: last_updated_seconds_since_epoch_uint64, v: 0, x: [ Exit, Infos ], z: "<64 bytes signature using identity key>" } service info (SI) public information blob for a hidden service n is the claimed fqdn of the service 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. { n: "", s: "<32 bytes public signing key>", v: 0, x: "" } service address (SA) the "network address" of a hidden service, which is computed as the blake2b 256 bit hash of the public infomration blob. HS(BE(SI)) introducer (I) a descriptor annoucing a path to a hidden service i is the rc.k value of the router to contact 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 { i: "<32 bytes public key of router>", p: path_id_uint64, v: 0, x: time_expires_seconds_since_epoch_uint64 } introducer set (IS) a signed set of introducers for a hidden service a is the service info e is the ephemeral public encryption key 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. { a: SI, e: "<1218 bytes ntru public encryption key>", i: [ I, I, I, ... ], v: 0, z: "<64 bytes signature using service info signing key>" } --- Encrypted frames: { v: 0, w: "<32+32+32+N bytes payload>" } 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 h = MDS(n + A.k + new_x, S) 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. 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. if r is not present in sessions made by clients. { a: "i", r: RC, v: 0 } link relay commit message (LRCM) request a commit to relay traffic to another node. { a: "c", b: [ list, of, encrypted, frames ], v: 0 } link relay commit record (LRCR) record requesting path with id p relay messages for o seconds to router on network who's i is equal to RC.k and decrypt data any messages using PKE(n, rc.K, c) as symettric key for encryption and decryption. { c: "<32 byte public signing/encryption key used for further communication>", i: "<32 byte RC.k of next hop>", n: "<32 bytes nounce for key exchange>", o: seconds_lifetime_uint64, p: path_id_uint64, v: 0 } if i is equal to RC.k then any LRDM.z values are decrypted and interpreted as routing layer messages. if i is not equal to RC.k then forward the LRCM with first element removed and the last element holding our hop's reply. this ensures that the first entry in the forwarded LRCM is for the next hop in the requested path. if i is equal to RC.k unconditionally send a LRDM with encrypted payload holding a LRSM with our record at the end and the previous ones in the front. link relay reject record (LRRR) sent in reply to a LRCM indicating we have rejected the request to relay data for path with id p, the recipiant of this message MUST backoff sending LRCM for b milliseconds or recipiant MAY get banned by recipiant router for an undefined amount of time. r contains a bytestring of 7 bit clean ascii metadata indicating why the commit was rejected. if included r MUST be logged or collected for later review by node operator. inclusion of r is OPTIONAL. review of collected events is RECOMMENDED. { b: miliseconds_backoff_uint64, c: "r", p: path_id_uint64, r: "", v: 0, x: "" } link relay accept record (LRAR) sent in reply to a LRCM indicating we have accepted the request to relay data for path with id p. { c: "a", p: path_id_uint64, v: 0, x: "" } link relay status message (LRSM) sent inside a LRDM after build has reached the end of the path to finish the path build and send the result of the build. { a: "s", p: [list, of, encrypted, replies], v: 0 } link relay upstream message (LRUM) sent to relay data via upstream direction of a previously created path. decrypt z using previously derived key and nounce y. Relay with new_y and new_z in upstream direction as a LRUM. new_z = SD(k, y, z) new_y = y ^ new_z[0:24] { a: "u", p: path_id_uint64, v: 0, y: "", z: "" } link relay downstream message (LRDM) sent to relay data via downstream direction of a previously created path. encrypt z using previously derived key and nonce new_y and relay in downstream direction as a LRDM. new_y = y ^ z[0:24] new_z = SE(k, new_y, z) { a: "d", p: path_id_uint64, v: 0, y: "", z: "" } link relay exit message (LRXM) sent to exit a previously commited path before it expires. verify signature using cancel key c in relay commit message. { a: "x", b: [ list, of, exit, records, as, encrpyted, frames ], v: 0 } link relay exit record (LRXR) { c: "x", p: path_id_uint64, v: 0, x: "", z: "<64 bytes signature>" } link immediate dht message (LIDM): transfer one or more dht messages directly without a previously made path. { a: "d", d: [many, dht, messages], v: 0 } link stateless relay message (LSRM) statelessly relay a link message. { a: "r", c: r5n_counter_uint8, d: "<32 bytes rc.K of destination>", s: "<32 bytes rc.K of source>", v: 0, x: "", 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. --- routing layer: 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. ipv4 addresses are allowed via ipv4 mapped ipv6 addresses, i.e. ::ffff.10.0.0.1 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. { A: "X", I: "<32 bytes signing public key for future communication>", V: 0, X: lifetime_of_address_mapping_in_seconds_uint64, } grant exit address messsage (GXAM) sent in response to an OXAM to grant an ip for exit traffic from an external ip address used for exit traffic. { A: "G", E: XR, I: "<32 bytes signing public key of requester>", T: transaction_id_uint64, V: 0, Z: "<64 bytes signature using exit info's signing key>" } E contains an exit route that was granted to the requester that can be used with IP exit traffic. 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 valid signatures and addresses. reject exit address message (RXAM) 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: "", T: transaction_id_uint64, V: 0, Z: "<64 bytes signature signed by exit info's signing key>" } B is set to a backoff value. R contains additional metadata text describing why the exit was rejected. transfer data fragment message (TDFM) variant 1 (with path id): transfer data between paths. { A: "T", P: path_id_uint64, V: 0, X: "", Y: "<24 bytes nounce>", Z: "<64 bytes signature>" } 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. variant 2 (no path id): transfer ip traffic for exit { A: "T", V: 0, X: "", Y: "<16 bytes nounce>", Z: "<64 bytes signature using previously provided signing key>" } 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 corrisponding path in an LRDM. 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>" } --- DHT messages find introduction message (FIM) recursively find an IS. variant 1, by SA { A: "F", R: r5n_counter, S: "<32 bytes SA>", T: transaction_id_uint64, V: 0 } variant 2, by claimed name { A: "F", N: "service.name.tld", R: r5n_counter, T: transaction_id_uin64, V: 0 } Transactions will persist until replied to by a GIM or 60 seconds, whichever is reached first. If the timeout is reached before a GIM or the forwarding of the request fails: * close transaction * close linked transactions if R is non-zero and less or equal to than 5: * decrement R by 1 * open a transaction with id T for sender's RC.k * pick random dht capable router, F * generate new transaction id, U * open a transaction with id U for F.k * link transaction U to transaction T * send FIM with transaction id U to F if R is greater than 5 or less than 0: * increment shitlist value of sender's RC.k by 1 * if the shitlist value for sender's RC.k is less than 10 reply with a GIM with an X * if the shitlist value for sender's RC.k is equal to or greater than 10 drop the message if R is zero and we have 1 or more IS at position S in dht keyspace: * reply with a GIM holding the IS who contains the introducer with the highest expiration timestamp if R is zero and we do not have any IS at position S in dht keyspace: * find a router who's RC.k is closest to S, N if N is our router: * reply with a GIM with an empty X value if N is not our router: * open transaction with id T for sender's RC.k * generate new transaction id, U * open transaction with id U for N.k * link transaction U to transaction T * forward request to N using transaction id U got introduction message (GIM) { A: "G", T: transaction_id_uint64, V: 0, X: [ IS, IS, IS, ... ] } if we have a transaction with id T: * forward the GIM to all linked transactions * terminate transaction T when a linked transaction gets a GIM: * set T to the current transaction id * foward the GIM to the requester of T publish introduction message (PIM) publish one or many IM into the dht at once. each IS will be placed in the dht version 0 uses the SA of each IS as the keyspace location. in the future the location will be determined by the dht kdf which uses a shared random source to obfuscate keyspace location. R is currently set to 3 +/- 2 by the sender. { A: "P", R: r5n_counter, V: 0, X: [ IS, IS, IS, ... ] } The following steps happen in order: first stage: reduction if X's length is divisble by 2: * split X in half as J and K * generate 2 new PIM with the same values as the parent with empty X * put J and K into the new PIM's X values * associate the 2 new PIM with the current PIM batch if X's length is not divisible by 2 and greater than 1: * pop off an IS from X as A * generate a new PIM with the same values as the parent with an X value of A * associate the new PIM with the current PIM batch * associate the old PIM having A removed from X with the current PIM batch if X's length is 1: * associate the PIM with the current PIM batch any other cases for X are ignored. for each PIM in the current batch: if R is greater than 0: * decrement R by 1 * queue the PIM for shuffle (second stage) if R is 0: * queue the PIM for distribution (third stage) if R is less than 0: * drop the message entirely second stage: shuffle * The dht node waits until we have collected 10 or more PIM or for 5 seconds, which ever comes first. * shuffle the list of IS randomly * re-combine the IS into new PIMs * queue each newly shuffled PIM for distribution (third stage) if we collected 10 or more PIM: * X holds 5 IS at most if we collected less than 10 but more than 1 PIM: * X holds 2 IS at most if we only collected 1 PIM: * the single PIM is unmodified third stage: distribution if R is less than 0: * drop message and terminate current transaction, this should never happen but this case is left here in the event of implementation bugs. if R is greater than 0: * pick a random dht capable router, N * forward the PIM to N if R is equal to 0: for each IS in X as A: * find the router closest to the SA in A, N if N is our router: * create dht positon S from SA in A * store A for lookup at S if N is not our router: * send a PIM with X value containing just A to N In the future post random walk keyspace batching may be done here. As of version 0, none is done. find router contact message (FRCM) find a router by long term RC.k public key { A: "F", K: "<32 byte public key of router>", T: transaction_id_uint64, V: 0 } find RC who's RC.k is closest to K: if A.k is equal to K: * reply with a GRCM with an R value of just A if A.k is not equal to K and we are closesr to A.k than anyone we know: * reply with a GRCM with an empty R value find a pending transaction id for K, P if P exists: * link transaction T to P if P does not exist: * generate a new transaction id, U * start transaction U for A.k * link transaction U to transaction T * send FRCM to A.k requesting K got router contact message (GRCM) R is a list containing a single RC if found or is an empty list if not found sent in reply to FRCM only { A: "G", R: [RC], T: transaction_id_uint64, V: 0 } * send a GRCM with R to requesters in all linked transactions * terminate transaction with id T notes: if we get a GRCM with empty R on one Tx and then one with a filled R on another with the same K, the request is terminated by the first message as not found. A backtrack case is needed.