mirror of
https://github.com/lightning/bolts.git
synced 2024-11-19 10:00:04 +01:00
7d3083e79a
This is a multi-part message in MIME format. This patch should apply to http://github.com/lightningnetwork/lightning-rfc Nonidealities: Aspell triggers spelling errors on the hexadecimal strings in the test vectors. I don't have enough aspell-fu to figure out how to make Aspell ignore these. There are 2 possible pluralizations of `HTLC`: `HTLCs` and `HTLC's`. I'd prefer the latter, but for now I support both. We should standardize pluralization; we can edit the `.aspell.en.pws` file to remove the pluralization we won't choose.
745 lines
81 KiB
Markdown
745 lines
81 KiB
Markdown
# BOLT #4: Onion Routing Protocol
|
|
|
|
## Overview
|
|
|
|
This document describes the construction of an onion routed packet that is used to route a payment from a _origin node_ to a _final node_, over a number of intermediate nodes, called _hops_.
|
|
|
|
The routing schema is based on the
|
|
[Sphinx](http://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)
|
|
construction, and is extended with a per-hop payload.
|
|
|
|
Intermediate nodes forwarding the message can verify the integrity of
|
|
the packet, and can learn about which node they should forward the
|
|
packet to. They cannot learn about which other nodes, besides their
|
|
predecessor or successor, are part of this route, nor can they learn
|
|
the length of the route and their position within it. The packet is
|
|
obfuscated at each hop, so that a network level attacker cannot
|
|
associate packets belonging to the same route, i.e., packets belonging
|
|
to a route do not share any identifying information. Notice that this
|
|
does not preclude the possibility to associate packets by performing a
|
|
traffic analysis.
|
|
|
|
The route is constructed by the sender, which knows a public key of
|
|
each intermediate node. Knowing the intermediate node's public key
|
|
allows the sender to create a shared secret using ECDH for each
|
|
intermediate node, including the final recipient. The shared secret is then
|
|
used to generate a _pseudo-random stream_ of bytes to obfuscate the
|
|
packet, and a number of _keys_ used to encrypt the payload and compute
|
|
HMACs ensuring integrity at each hop.
|
|
|
|
This specification describes version 0 of the packet format and
|
|
routing mechanism. Should a node receive a higher version packet that
|
|
it does not implement it MUST report a route failure to the sending
|
|
node and discard the packet.
|
|
|
|
## Conventions
|
|
|
|
There are a number of conventions we will adhere to throughout the document:
|
|
|
|
- The maximum route length is limited to 20 hops.
|
|
- HMAC: the integrity verification of the packet is based on Keyed-Hash Message Authentication Code as defined by the [FIPS 198 Standard](http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf)/[RFC 2104](https://tools.ietf.org/html/rfc2104), using `SHA256` as hashing algorithm.
|
|
- Elliptic Curve: for all computations involving elliptic curves, the
|
|
Bitcoin curve, [`secp256k1`](http://www.secg.org/sec2-v2.pdf), is used.
|
|
- Pseudo-Random Stream: [`ChaCha20`](https://tools.ietf.org/html/rfc7539) is used to generate a pseudo-random byte stream.
|
|
For the generation we use a fixed null-nonce (`0x0000000000000000`), a key derived from a shared secret and a `0x00`-byte stream of the desired output size as message.
|
|
- We use the terms _hop_ and _node_ interchangeably.
|
|
- A _peer_ is a direct neighbor of the processing node in the overlay network.
|
|
|
|
## Key Generation
|
|
|
|
A number of encryption and verification keys are derived from the shared secret:
|
|
|
|
- _rho_: used as key when generating the pseudo-random byte stream
|
|
used to obfuscate the per-hop information.
|
|
- _mu_: used during the HMAC generation.
|
|
- _um_: used during error reporting.
|
|
|
|
The key generation takes a key-type (_rho_=`0x72686F`, _mu_=`0x6d75` or _um_=`0x756d`) and a 32 byte secret as inputs and returns a 32 byte key.
|
|
|
|
Keys are generated by computing an HMAC, with `SHA256` as hashing algorithm, using the key-type, i.e., _rho_, _mu_ or _um_, as HMAC-key and the 32 byte shared secret as the message.
|
|
The resulting HMAC is then returned as the key.
|
|
|
|
Notice that the key-type does not include a C-style `0x00` termination-byte, e.g., the length of the _rho_ key-type is 3 bytes, not 4.
|
|
|
|
## Pseudo Random Byte Stream
|
|
|
|
The pseudo-random byte stream is used to obfuscate the packet at each hop of the path, so that each hop may only recover the address of the next hop as well as the HMAC for the next hop.
|
|
The pseudo-random byte stream is generated by encrypting a `0x00`-byte stream of the required length with `ChaCha20`, initialized with a key derived from the shared secret and a zero-nonce (`0x00000000000000`).
|
|
The use of a fixed nonce is safe since the keys are never reused.
|
|
|
|
## Packet Structure
|
|
|
|
The packet consists of 4 parts:
|
|
|
|
- A `version` byte
|
|
- A 33-byte compressed `secp256k1` `public key`, used during the shared secret generation
|
|
- A 1300-byte `hops_data` consisting of twenty fixed size packets containing information for each hop
|
|
as they forward the message.
|
|
- A 32-byte `HMAC` used to verify the packet's integrity.
|
|
|
|
The overall structure of the packet is depicted below. The network format of the packet consists of the individual parts being serialized into one continguous byte-stream and then transferred to the recipient of the packet. Due to the fixed size of the packet it does not need to be prefixed by its length when transferred over a connection.
|
|
|
|
~~~~
|
|
+------------------+-----------------------+------------------------+-----------------+
|
|
| version (1 byte) | public key (33 bytes) | hops_data (20x65 bytes) | HMAC (32 bytes) |
|
|
+------------------+-----------------------+------------------------+-----------------+
|
|
~~~~
|
|
|
|
For this specification the version byte has a constant value of `0x00`.
|
|
|
|
The `hops_data` field is a structure that holds obfuscated versions of the next hop's address, transfer information and the associated HMAC. It is 1300 bytes long, and has the following structure:
|
|
|
|
~~~~
|
|
+-----------+-------------+----------+-----------+-------------+----------+-----------+
|
|
| n_1 realm | n_1 per-hop | n_1 HMAC | n_2 realm | n_2 per-hop | n_2 HMAC | ...filler |
|
|
+-----------+-------------+----------+----------+--------------+----------+------------+
|
|
~~~~
|
|
|
|
Where `per-hop` is 32 bytes whose contents depend on `realm`, and `filler` consists of obfuscated deterministically generated
|
|
padding. For details about how the `filler` is generated please see
|
|
below. In addition, every _(address, HMAC)_-pair is incrementally
|
|
obfuscated at each hop.
|
|
|
|
The `realm` byte determines the format of the `per-hop`; so far
|
|
only `realm` 0 is defined, and for that, the `per-hop` format is:
|
|
|
|
~~~~
|
|
+----------------------+--------------------------+-------------------------------+--------------------+
|
|
| channel_id (8 bytes) | amt_to_forward (4 bytes) | outgoing_cltv_value (4 bytes) | padding (16 bytes) |
|
|
+----------------------+--------------------------+-------------------------------+--------------------+
|
|
~~~~
|
|
|
|
Using the `per-hop`, the sender is able to precisely specify the path and
|
|
structure of the HTLC's forwarded at each hop. As the `per-hop` is
|
|
protected under the packet-wide HMAC, the information within
|
|
is fully authenticated with each pair-wise relationship between
|
|
the HTLC sender, and each intermediate node in the path. Using this end-to-end
|
|
authentication, forwarding nodes are able to ensure that the incoming node
|
|
didn't forward an ill-crafted HTLC by cross-checking the HTLC parameters with
|
|
the values as specified within the `per-hop`.
|
|
|
|
Field Description:
|
|
|
|
* `channel_id` - The channel used to route the message, which implies the
|
|
next hop is the other end of the channel.
|
|
|
|
* `amt_to_forward` - The amount in milli-satoshi to forward to the next
|
|
(outgoing) hop specified within the routing information.
|
|
|
|
This value MUST factor in the computed fee for this particular hop. When
|
|
processing an incoming Sphinx packet along with the HTLC message it's
|
|
encapsulated within, if the following inequality doesn't hold, then the
|
|
HTLC should be rejected as it indicates a prior node in the path has
|
|
deviated from the specified parameters:
|
|
|
|
incoming_htlc_amt - fee >= amt_to_forward
|
|
|
|
Where `fee` is calculated according to the receiving node's advertised fee
|
|
schema as described in [BOLT 7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#htlc-fees), or 0 if this node is the
|
|
final hop.
|
|
|
|
* `outgoing_cltv_value` - The CLTV value that the _outgoing_ HTLC carrying
|
|
the packet should have.
|
|
|
|
cltv-expiry - cltv-expiry-delta = outgoing_cltv_value
|
|
|
|
Inclusion of this field allows a node to both authenticate the information
|
|
specified by the original sender and the parameters of the HTLC forwarded,
|
|
and ensure the original sender is using the current `cltv-expiry-delta` value.
|
|
If there is no next hop, `cltv-expiry-delta` is zero.
|
|
If the values don't correspond, then the HTLC should be failed+rejected as
|
|
this indicates the incoming node has tampered with the intended HTLC
|
|
values, or the origin has an obsolete `cltv-expiry-delta` value.
|
|
The node MUST be consistent in responding to an unexpected
|
|
`outgoing_cltv_value` whether it is the final hop or not, to avoid
|
|
leaking that information.
|
|
|
|
* `padding` - for future use, and also to ensure that future non-0-realm
|
|
`per-hop` won't change the overall `hops_data` size.
|
|
|
|
Nodes forwarding HTLC's MUST construct the outgoing HTLC as specified within
|
|
`per-hop`. Otherwise, deviation from the specified HTLC parameters
|
|
may lead to extraneous routing failure.
|
|
|
|
## Packet Construction
|
|
|
|
Assuming a _sender node_ `n_0` wants to route a packet to a _final recipient_ `n_r`.
|
|
The sender computes a route `{n_0, n_1, ..., n_{r-1}, n_r}`, where `n_0` is the sender itself and `n_r` is the final recipient.
|
|
The nodes `n_i` and `n_{i+1}` MUST be peers in the overlay network.
|
|
The sender gathers the public keys for `n_1` to `n_r` and generates a random 32 byte `sessionkey`.
|
|
Optionally the sender may pass in _associated data_, i.e., data that the packet commits to, but is not included in the packet itself.
|
|
Associated data will be included in the HMACs and has to match the associated data provided during integrity verification at each hop.
|
|
|
|
For each node the sender computes an _ephemeral public key_, a _shared secret_ and a _blinding factor_.
|
|
The blinding factor is used at each hop to blind the ephemeral public key for the next hop.
|
|
The node receiving the header will perform ECDH with the ephemeral public key and its private key to derive the same shared secret.
|
|
However, when generating the packet we do not have access to the node's private key.
|
|
Hence, we use the commutative property of multiplication and blind the node's public key with all previous blinding factors and perform ECDH using the node's blinded public key and the `sessionkey`.
|
|
|
|
The transformations at hop `k` are given by the following:
|
|
|
|
- The shared secret `ss_k` is computed by first blinding the node's public key `nodepk_k` with all previous blinding factors `{b_1, ..., b_{k-1}}`, if any, and then executing ECDH with the blinded public key and the `sessionkey`.
|
|
- The blinding factor is the `SHA256` hash of the concatenation between the node's public key `nodepk_k` and the hop's shared secret `ss_k`.
|
|
Before concatenation the node's public key is serialized in the compressed format.
|
|
- The ephemeral public key `epk_k` is computed by blinding the previous hop's ephemeral public key `epk_{k-1}` with the previous hop's blinding factor `b_{k-1}`.
|
|
|
|
This recursive algorithm is initialized by setting the first hop's (`k=1`) ephemeral public key to the public key corresponding with the `sessionkey`, i.e., `secp256k1` is used to derive a public key for the randomly selected `sessionkey`.
|
|
|
|
The sender then iteratively computes the ephemeral public keys, shared secrets and blinding factors for nodes `{n_2, ..., n_r}`.
|
|
|
|
Once the sender has all the required information it can construct the packet.
|
|
Constructing a packet routed over `r` hops requires `r` 32 byte ephemeral public keys, `r` 32 byte shared secrets, `r` 32 byte blinding factors and `r` 65 byte `per-hop` payloads.
|
|
The construction returns one 1366 byte packet and the first hop's address.
|
|
|
|
The packet construction is performed in reverse order of the route, i.e., the last hop's operations are applied first.
|
|
|
|
The packet is initialized with 1366 `0x00` bytes.
|
|
|
|
A 65-byte filler is generated with the shared secret:
|
|
See below for details on filler generation.
|
|
|
|
For each hop in the route in reverse order the sender applies the
|
|
following operations:
|
|
|
|
- It generates a _rho_-key and _mu_-key using the hop's shared secret.
|
|
- The `hops_data` field is right-shifted by 65 bytes, discarding the last 65 bytes that exceed the 1300 bytes.
|
|
The `version`, `channel_id`, `amt_to_forward`, `outgoing_cltv_value`, `padding` and `HMAC` are copied into
|
|
the following 65 bytes.
|
|
The _rho_-key is used to generate 1300 bytes of pseudo-random byte stream and applied with `XOR` to the `hops_data` field.
|
|
Should this be the last hop, i.e., the first iteration, then the tail of the `hops_data` field is overwritten with the routing info `filler`.
|
|
- The next HMAC is computed over the concatenated `hops_data` and associated data, with the _mu_-key as HMAC-key.
|
|
|
|
The final value for the HMAC is the HMAC as it should be sent to the first hop.
|
|
|
|
The packet generation returns the serialized packet, consisting of the version byte, the ephemeral pubkey for the first hop, the HMAC for the first hop, the obfuscated `hops_data`.
|
|
|
|
The following code implements the packet construction in Go:
|
|
|
|
```Go
|
|
func NewOnionPacket(paymentPath []*btcec.PublicKey, sessionKey *btcec.PrivateKey,
|
|
hopsData []HopData, assocData []byte) (*OnionPacket, error) {
|
|
|
|
numHops := len(paymentPath)
|
|
hopEphemeralPubKeys := make([]*btcec.PublicKey, numHops)
|
|
hopSharedSecrets := make([][sha256.Size]byte, numHops)
|
|
hopBlindingFactors := make([][sha256.Size]byte, numHops)
|
|
|
|
hopEphemeralPubKeys[0] = sessionKey.PubKey()
|
|
hopSharedSecrets[0] = generateSharedSecret(paymentPath[0], sessionKey)
|
|
hopBlindingFactors[0] = computeBlindingFactor(hopEphemeralPubKeys[0], hopSharedSecrets[0][:])
|
|
|
|
for i := 1; i <= numHops-1; i++ {
|
|
hopEphemeralPubKeys[i] = blindGroupElement(hopEphemeralPubKeys[i-1],
|
|
hopBlindingFactors[i-1][:])
|
|
yToX := blindGroupElement(paymentPath[i], sessionKey.D.Bytes())
|
|
hopSharedSecrets[i] = sha256.Sum256(multiScalarMult(yToX, hopBlindingFactors[:i]).SerializeCompressed())
|
|
|
|
hopBlindingFactors[i] = computeBlindingFactor(hopEphemeralPubKeys[i],
|
|
hopSharedSecrets[i][:])
|
|
}
|
|
|
|
// Generate the padding, called "filler strings" in the paper.
|
|
filler := generateHeaderPadding("rho", numHops, hopDataSize, hopSharedSecrets)
|
|
|
|
// Allocate and initialize fields to zero-filled slices
|
|
var mixHeader [routingInfoSize]byte
|
|
var nextHmac [hmacSize]byte
|
|
|
|
// Now we compute the routing information for each hop, along with a
|
|
// MAC of the routing info using the shared key for that hop.
|
|
for i := numHops - 1; i >= 0; i-- {
|
|
rhoKey := generateKey("rho", hopSharedSecrets[i])
|
|
muKey := generateKey("mu", hopSharedSecrets[i])
|
|
|
|
hopsData[i].HMAC = nextHmac
|
|
|
|
// Shift and obfuscate routing info
|
|
streamBytes := generateCipherStream(rhoKey, numStreamBytes)
|
|
|
|
rightShift(mixHeader[:], hopDataSize)
|
|
buf := &bytes.Buffer{}
|
|
hopsData[i].Encode(buf)
|
|
copy(mixHeader[:], buf.Bytes())
|
|
xor(mixHeader[:], mixHeader[:], streamBytes[:routingInfoSize])
|
|
|
|
// We need to overwrite these so every node generates a correct padding
|
|
if i == numHops-1 {
|
|
copy(mixHeader[len(mixHeader)-len(filler):], filler)
|
|
}
|
|
|
|
packet := append(mixHeader[:], assocData...)
|
|
nextHmac = calcMac(muKey, packet)
|
|
}
|
|
|
|
packet := &OnionPacket{
|
|
Version: 0x01,
|
|
EphemeralKey: hopEphemeralPubKeys[0],
|
|
RoutingInfo: mixHeader,
|
|
HeaderMAC: nextHmac,
|
|
}
|
|
return packet, nil
|
|
}
|
|
```
|
|
|
|
## Packet Forwarding
|
|
|
|
Upon receiving a packet, a node compares the version byte of the packet with its supported versions and aborts otherwise.
|
|
This specification is limited to version `0` packets and the structure of future versions may change.
|
|
The receiving node then splits the packet into its fields.
|
|
|
|
The node MUST check that the ephemeral public key is on the `secp256k1` curve.
|
|
Should this not be the case the node MUST abort processing the packet and report a route failure to the sender.
|
|
|
|
The node then computes the shared secret as described below, using the private key corresponding to its public key and the ephemeral key from the packet.
|
|
|
|
The node MUST detect a duplicated routing info which it has already forwarded or redeemed locally; it MAY immediately redeem the HTLC using the preimage (if known), otherwise it MUST abort processing and report a route failure. This prevents a node on the route from retrying a payment multiple times and attempting to track its progress by traffic analysis. Note that this could be done using a log of previous shared secrets or HMACs, which can be forgotten once that HTLC would not be accepted anyway (eg. once `outgoing_cltv_value` has passed). Such a log may use a probabilistic data structure, but MUST rate-limit commitments as necessary to constrain the worst-case storage requirements or false positives of this log.
|
|
|
|
The shared secret is used to compute a _mu_-key. The node then computes the HMAC of the `hops_data` using the _mu_-key.
|
|
The resulting HMAC is compared with the HMAC from the packet.
|
|
Should the computed HMAC and the HMAC from the packet differ then the node MUST abort processing and report a route failure.
|
|
Comparison of the computed HMAC and the HMAC from the packet MUST be time-constant to avoid leaking information.
|
|
|
|
At this point the node can generate a _rho_-key and a _gamma_-key.
|
|
|
|
The routing info is deobfuscated and the information about the next hop is extracted.
|
|
In order to do so the node copies the `hops_data` field, appends 65 `0x00` bytes and generates 1365 pseudo-random bytes using the _rho_-key and applies it using `XOR` to the copy of the `hops_data`
|
|
The first 65 bytes of the resulting routing info are `per-hop` field for the next hop. The next 1300 bytes is the `hops_data` for the outgoing packet.
|
|
|
|
If the `realm` is unknown, then the node MUST drop the packet and signal a route failure.
|
|
|
|
A special `per-hop` `HMAC` value of 32 `0x00` bytes indicates that the currently processing hop is the intended recipient and that the packet should not be forwarded.
|
|
|
|
Should the HMAC not indicate route termination and the next hop be a peer of the current node, then the new packet is assembled by blinding the ephemeral key with the current node's public key and shared secret, and serializing the `hops_data`.
|
|
The resulting packet is then forwarded to the addressed peer.
|
|
The addressed peer MUST be a direct neighbor of the node processing the packet.
|
|
Should the processing node not have a peer with the matching address, then it MUST drop the packet and signal a route failure.
|
|
|
|
## Shared secret
|
|
|
|
The sender performs ECDH with each hop of the route in order to establish a secret.
|
|
For each message a new _sessionkey_ is generated.
|
|
The sessionkey is a 32 byte EC private key.
|
|
The shared secret creation receives a public key and a 32 byte secret as input and returns a 32 byte secret as output.
|
|
|
|
In the packet generation phase the secret is the `sessionkey` and the public key is the node's public key, blinded with all previous blinding factors.
|
|
In the pocessing phase the secret is the node's private key and the public key is the ephemeral public key from the packet, which has been incrementally blinded by the predecessors.
|
|
|
|
The public key is multiplied by the secret, using to the `secp256k1` curve.
|
|
The DER compressed representation of the multiplication result is serialized and hashed using `SHA256`.
|
|
The resulting hash is returned as the shared secret.
|
|
Notice that this is the ECDH variant implemented in `libsecp256k1`.
|
|
|
|
## Filler Generation
|
|
|
|
Upon receiving a packet, each node extracts the information destined for that node from the route info and the per-hop payload.
|
|
The extraction is done by deobfuscating and left-shifting the field.
|
|
This would make the field shorter at each hop, allowing an attacker to deduce the route length.
|
|
For this reason the field is padded before forwarding.
|
|
Since the padding is part of the HMAC the sender will have to generate an identical padding in order to compute the HMACs correctly for each hop.
|
|
The filler is also used to pad the field-length in case the selected route is shorter than the maximum allowed route length.
|
|
|
|
Before deobfuscating the `hops_data`, the node pads it with 65 `0x00` bytes, such that the total length is `(20 + 1) * 65`.
|
|
It then generates the pseudo-random byte stream of matching length and applies it with `XOR` to the `hops_data`.
|
|
This deobfuscates the information destined for it, and simultaneously obfuscates the added
|
|
`0x00`-bytes at the end.
|
|
|
|
In order to compute the correct HMAC, the sender has to generate the `hops_data` at the hop.
|
|
This also includes the incrementally obfuscated padding added by each hop.
|
|
The incrementally obfuscated padding is called the _filler_.
|
|
|
|
The following code shows how the filler is generated:
|
|
|
|
```Go
|
|
func generateFiller(key string, numHops int, hopSize int, sharedSecrets [][sharedSecretSize]byte) []byte {
|
|
fillerSize := uint((numMaxHops + 1) * hopSize)
|
|
filler := make([]byte, fillerSize)
|
|
|
|
// The last hop does not obfuscate, it's not forwarding anymore.
|
|
for i := 0; i < numHops-1; i++ {
|
|
|
|
// Left-shift the field
|
|
copy(filler[:], filler[hopSize:])
|
|
|
|
// Zero-fill the last hop
|
|
copy(filler[len(filler)-hopSize:], bytes.Repeat([]byte{0x00}, hopSize))
|
|
|
|
// Generate pseudo-random byte stream
|
|
streamKey := generateKey(key, sharedSecrets[i])
|
|
streamBytes := generateCipherStream(streamKey, fillerSize)
|
|
|
|
// Obfuscate
|
|
xor(filler, filler, streamBytes)
|
|
}
|
|
|
|
// Cut filler down to the correct length (numHops+1)*hopSize
|
|
// bytes will be prepended by the packet generation.
|
|
return filler[(numMaxHops-numHops+2)*hopSize:]
|
|
}
|
|
```
|
|
|
|
Notice that this implementation is for demonstration purposes only, the filler can be generated much more efficiently.
|
|
The last hop does not obfuscate the filler since it will not forward the packet and will not extract an HMAC for any followup hops.
|
|
|
|
## Blinding EC Points
|
|
|
|
In order to vary the ephemeral public key (the EC point) between hops, it is blinded at each hop.
|
|
The inputs for the blinding process are the EC point to be blinded, the node's public key and a 32 byte shared secret, while the output is a single EC point, representing the blinded element.
|
|
|
|
Blinding is done by computing a blinding factor from the node's public key and the shared secret for that hop.
|
|
The blinding factor is the result of serializing the node's public key into its compressed format, appending the shared secret and computing the `SHA256` hash.
|
|
The blinded EC point then is the result of the scalar multiplication between the EC point and the blinding factor.
|
|
|
|
## Returning Errors
|
|
|
|
The protocol includes a simple mechanism to return encrypted error messages to the origin node.
|
|
The returned messages may either be failures reported by any intermediate hop, or the final node.
|
|
The format of the forward packet is not usable for the return path, since no node other than the origin has the required information. Note that these error messages are not reliable, as they are not placed on-chain in the case of node failure.
|
|
|
|
Intermediate hops store the shared secret from the forward path and reuse it to obfuscate the error packet on each hop.
|
|
In addition each node locally stores the previous hop it received the forward packet from, in order to determine where to send an eventual return packet.
|
|
The node returning the message builds a return packet consisting of the following fields:
|
|
|
|
1. data:
|
|
* [32:hmac]
|
|
* [2:failure-len]
|
|
* [failure-len:failuremsg]
|
|
* [2:pad-len]
|
|
* [pad-len:pad]
|
|
|
|
Where `hmac` is an HMAC authenticating the remainder of the packet, with a key using the above key generation with key type "_um_", `failuremsg` is defined below, and `pad` as extra bytes to conceal length.
|
|
|
|
The node SHOULD set `pad` such that the `failure-len` plus `pad-len` is equal to 128.
|
|
This is 28 bytes longer than then the longest currently-defined message.
|
|
|
|
The node then generates a new key, using the key type `ammag`.
|
|
This key is then used to generate a pseudo-random stream, which is then applied to the packet using `XOR`.
|
|
|
|
The obfuscation step is repeated by every node on the return path.
|
|
Upon receiving a packet the node will generate its `ammag`, generate the pseudo-random byte stream and apply it to the packet before forwarding.
|
|
|
|
The origin node detects that it is the final hop of the return message since it was the origin of the corresponding forward packet.
|
|
Having the shared secrets of all intermediate nodes it can unwrap the packet until the HMAC is a valid HMAC for the packet, which also identifies the sender of the return message.
|
|
|
|
The association between forward and return packet is handled outside of the protocol, e.g., by association to an HTLC in a payment channel.
|
|
|
|
### Failure Messages
|
|
|
|
The failure message encapsulated in `failuremsg` has identical format to
|
|
a normal message: two byte type (`failure-code`) followed by data suitable
|
|
for that type. The following `failure-code` values are supported. A node MUST select one of
|
|
these codes when creating an error message, and MUST include the
|
|
appropriate data.
|
|
|
|
In the case of more than one error, a node SHOULD select the first one
|
|
listed.
|
|
|
|
The top byte of `failure-code` can be read as a set of flags:
|
|
* 0x8000 (BADONION): unparsable onion, encrypted by previous node.
|
|
* 0x4000 (PERM): permanent failure (otherwise transient)
|
|
* 0x2000 (NODE): node failure (otherwise channel)
|
|
* 0x1000 (UPDATE): new channel update enclosed
|
|
|
|
Any node MAY return one of the following errors:
|
|
|
|
If the realm byte is unknown:
|
|
|
|
1. type: PERM|1 (`invalid_realm`)
|
|
|
|
If an otherwise unspecified transient error occurs for the entire
|
|
node:
|
|
|
|
1. type: NODE|2 (`temporary_node_failure`)
|
|
|
|
If an otherwise unspecified permanent error occurs for the entire
|
|
node:
|
|
|
|
1. type: PERM|NODE|2 (`permanent_node_failure`)
|
|
|
|
If a node has requirement advertised in its `node_announcement`
|
|
`features` which were not present in the onion:
|
|
|
|
1. type: PERM|NODE|3 (`required_node_feature_missing`)
|
|
|
|
A forwarding node MAY return one of the following errors, the final
|
|
node MUST NOT:
|
|
|
|
If the onion version byte is unknown:
|
|
|
|
1. type: BADONION|PERM|4 (`invalid_onion_version`)
|
|
2. data:
|
|
* [32:sha256-of-onion]
|
|
|
|
If the onion HMAC is incorrect:
|
|
|
|
1. type: BADONION|PERM|5 (`invalid_onion_hmac`)
|
|
2. data:
|
|
* [32:sha256-of-onion]
|
|
|
|
If the ephemeral key in the onion is unparsable:
|
|
|
|
1. type: BADONION|PERM|6 (`invalid_onion_key`)
|
|
2. data:
|
|
* [32:sha256-of-onion]
|
|
|
|
If an otherwise unspecified transient error occurs for the outgoing
|
|
channel (eg. peer unresponsive, channel capacity reached):
|
|
|
|
1. type: 7 (`temporary_channel_failure`)
|
|
2. data:
|
|
* [2:len]
|
|
* [len:channel_update]
|
|
|
|
If an otherwise unspecified permanent error occurs for the outgoing
|
|
channel (eg. channel (recently) closed):
|
|
|
|
1. type: PERM|8 (`permanent_channel_failure`)
|
|
|
|
If the outgoing channel has requirement advertised in its
|
|
`channel_announcement` `features` which were not present in the onion:
|
|
|
|
1. type: PERM|9 (`required_channel_feature_missing`)
|
|
|
|
If the next peer specified by the onion is not known:
|
|
|
|
1. type: PERM|10 (`unknown_next_peer`)
|
|
|
|
If the HTLC does not reach the current minimum amount, we tell them
|
|
the amount of the incoming HTLC and the current channel setting for
|
|
the outgoing channel:
|
|
|
|
1. type: UPDATE|11 (`amount_below_minimum`)
|
|
2. data:
|
|
* [4:htlc-msat]
|
|
* [2:len]
|
|
* [len:channel_update]
|
|
|
|
If the HTLC does not pay sufficient fee, we tell them the amount of
|
|
the incoming HTLC and the current channel setting for the outgoing
|
|
channel:
|
|
|
|
1. type: UPDATE|12 (`fee_insufficient`)
|
|
2. data:
|
|
* [4:htlc-msat]
|
|
* [2:len]
|
|
* [len:channel_update]
|
|
|
|
If `outgoing_cltv_value` does not match the`update_add_htlc`'s
|
|
`cltv-expiry` minus `cltv-expiry-delta` for the outgoing channel, we
|
|
tell them the `cltv-expiry` and the current channel setting for the
|
|
outgoing channel:
|
|
|
|
1. type: UPDATE|13 (`incorrect_cltv_expiry`)
|
|
2. data:
|
|
* [4:cltv-expiry]
|
|
* [2:len]
|
|
* [len:channel_update]
|
|
|
|
If the ctlv-expiry is too near, we tell them the the current channel
|
|
setting for the outgoing channel:
|
|
|
|
1. type: UPDATE|14 (`expiry_too_soon`)
|
|
2. data:
|
|
* [2:len]
|
|
* [len:channel_update]
|
|
|
|
The final node may return one of the following errors, intermediate
|
|
nodes MUST NOT:
|
|
|
|
If the payment hash has already been paid, the final node MAY treat
|
|
the payment hash as unknown, or may succeed in accepting the HTLC.
|
|
If the payment hash is unknown, the final node MUST fail the HTLC:
|
|
|
|
1. type: PERM|15 (`unknown_payment_hash`)
|
|
|
|
If the amount paid is less than the amount expected, the final node
|
|
MUST fail the HTLC. If the amount paid is more than twice the amount
|
|
expected, the final node SHOULD fail the HTLC. This allows the sender
|
|
to reduce information leakage by altering the amount, without allowing
|
|
accidental gross overpayment:
|
|
|
|
1. type: PERM|16 (`incorrect_payment_amount`)
|
|
|
|
If the `cltv-expiry` is too low, the final node MUST fail the HTLC:
|
|
|
|
1. type: 17 (`final_expiry_too_soon`)
|
|
|
|
If the `outgoing_cltv_value` does not match the `ctlv-expiry` of the
|
|
HTLC at the final hop:
|
|
|
|
1. type: 18 (`final_incorrect_cltv_expiry`)
|
|
2. data:
|
|
* [4:cltv-expiry]
|
|
|
|
If the `amt_to_forward` does not match the `incoming_htlc_amt` of
|
|
the HTLC at the final hop:
|
|
|
|
1. type: 19 (`final_incorrect_htlc_amount`)
|
|
2. data:
|
|
* [4:incoming-htlc-amt]
|
|
|
|
### Receiving Failure Codes
|
|
|
|
A node MUST ignore any extra bytes in `failuremsg`.
|
|
|
|
If node sending the error is the final node:
|
|
* If the PERM bit is set, the origin node SHOULD fail the payment,
|
|
otherwise it MAY retry the payment if the error code is understood
|
|
and valid. (In particular, `final_expiry_too_soon` can occur if the
|
|
block height has changed since sending, `temporary_node_failure`
|
|
could resolve within a few seconds).
|
|
|
|
Otherwise, the node sending the error is an intermediate node:
|
|
* If the NODE bit is set, the origin node SHOULD remove all channels
|
|
connected with the sending node from consideration.
|
|
* If the PERM bit is not set, the origin node SHOULD restore the
|
|
channels as it sees new `channel_update`s.
|
|
* Otherwise, if UPDATE is set, and the `channel_update` is valid
|
|
and more recent than the `channel_update` used to send the payment:
|
|
* The origin node MAY treat the `channel_update` as invalid if it
|
|
should not have caused the failure.
|
|
* Otherwise, the origin node SHOULD apply the `channel_update`.
|
|
* The origin node MAY queue the `channel_update` for broadcast.
|
|
* Otherwise, the origin node SHOULD eliminate the channel outgoing
|
|
from the sending node from consideration.
|
|
* If the PERM bit is not set, the origin node SHOULD restore the
|
|
channel as it sees a new `channel_update`.
|
|
* The origin node SHOULD then retry routing and sending the payment.
|
|
|
|
The origin node MAY use the data specified in the various types of
|
|
failure for debugging purposes.
|
|
|
|
## Test Vector
|
|
|
|
### Packet Creation
|
|
|
|
The following is an in-depth trace of the packet creation, including intermediate data.
|
|
|
|
|
|
#### Parameters
|
|
|
|
pubkey[0] 0x02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619
|
|
pubkey[1] 0x0324653eac434488002cc06bbfb7f10fe18991e35f9fe4302dbea6d2353dc0ab1c
|
|
pubkey[2] 0x027f31ebc5462c1fdce1b737ecff52d37d75dea43ce11c74d25aa297165faa2007
|
|
pubkey[3] 0x032c0b7cf95324a07d05398b240174dc0c2be444d96b159aa6c7f7b1e668680991
|
|
pubkey[4] 0x02edabbd16b41c8371b92ef2f04c1185b4f03b6dcd52ba9b78d9d7c89c8f221145
|
|
|
|
nhops = 5/20
|
|
sessionkey = 0x4141414141414141414141414141414141414141414141414141414141414141
|
|
associated data = 0x4242424242424242424242424242424242424242424242424242424242424242
|
|
|
|
The HMAC is omitted in the following `hop_data` since it is likely filled by the onion construction. Hence the values below are the `realm`, the `short_channel_id`, the `amt_to_forward`, the `outgoing_cltv` and the 16 bytes padding. These were initialized by byte-filling the `short_channel_id` to the respective position in the route, and by settings `amt_to_forward` and `outgoing_cltv` to the position in the route, starting with 0.
|
|
|
|
hop_payload[0] = 0x000000000000000000000000000000000000000000000000000000000000000000
|
|
hop_payload[1] = 0x000101010101010101000000010000000100000000000000000000000000000000
|
|
hop_payload[2] = 0x000202020202020202000000020000000200000000000000000000000000000000
|
|
hop_payload[3] = 0x000303030303030303000000030000000300000000000000000000000000000000
|
|
hop_payload[4] = 0x000404040404040404000000040000000400000000000000000000000000000000
|
|
|
|
#### Per-Hop Information
|
|
|
|
hop_shared_secret[0] = 0x53eb63ea8a3fec3b3cd433b85cd62a4b145e1dda09391b348c4e1cd36a03ea66
|
|
hop_blinding_factor[0] = 0x2ec2e5da605776054187180343287683aa6a51b4b1c04d6dd49c45d8cffb3c36
|
|
hop_ephemeral_pubkey[0] = 0x02eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619
|
|
|
|
hop_shared_secret[1] = 0xa6519e98832a0b179f62123b3567c106db99ee37bef036e783263602f3488fae
|
|
hop_blinding_factor[1] = 0xbf66c28bc22e598cfd574a1931a2bafbca09163df2261e6d0056b2610dab938f
|
|
hop_ephemeral_pubkey[1] = 0x028f9438bfbf7feac2e108d677e3a82da596be706cc1cf342b75c7b7e22bf4e6e2
|
|
|
|
hop_shared_secret[2] = 0x3a6b412548762f0dbccce5c7ae7bb8147d1caf9b5471c34120b30bc9c04891cc
|
|
hop_blinding_factor[2] = 0xa1f2dadd184eb1627049673f18c6325814384facdee5bfd935d9cb031a1698a5
|
|
hop_ephemeral_pubkey[2] = 0x03bfd8225241ea71cd0843db7709f4c222f62ff2d4516fd38b39914ab6b83e0da0
|
|
|
|
hop_shared_secret[3] = 0x21e13c2d7cfe7e18836df50872466117a295783ab8aab0e7ecc8c725503ad02d
|
|
hop_blinding_factor[3] = 0x7cfe0b699f35525029ae0fa437c69d0f20f7ed4e3916133f9cacbb13c82ff262
|
|
hop_ephemeral_pubkey[3] = 0x031dde6926381289671300239ea8e57ffaf9bebd05b9a5b95beaf07af05cd43595
|
|
|
|
hop_shared_secret[4] = 0xb5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328
|
|
hop_blinding_factor[4] = 0xc96e00dddaf57e7edcd4fb5954be5b65b09f17cb6d20651b4e90315be5779205
|
|
hop_ephemeral_pubkey[4] = 0x03a214ebd875aab6ddfd77f22c5e7311d7f77f17a169e599f157bbcdae8bf071f4
|
|
|
|
#### Per-Packet Information
|
|
|
|
filler = 0xc6b008cf6414ed6e4c42c291eb505e9f22f5fe7d0ecdd15a833f4d016ac974d33adc6ea3293e20859e87ebfb937ba406abd025d14af692b12e9c9c2adbe307a679779259676211c071e614fdb386d1ff02db223a5b2fae03df68d321c7b29f7c7240edd3fa1b7cb6903f89dc01abf41b2eb0b49b6b8d73bb0774b58204c0d0e96d3cce45ad75406be0bc009e327b3e712a4bd178609c00b41da2daf8a4b0e1319f07a492ab4efb056f0f599f75e6dc7e0d10ce1cf59088ab6e873de377343880f7a24f0e36731a0b72092f8d5bc8cd346762e93b2bf203d00264e4bc136fc142de8f7b69154deb05854ea88e2d7506222c95ba1aab065c8a851391377d3406a35a9af3ac
|
|
|
|
#### Wrapping the Onion
|
|
|
|
rhokey[4] = 0x034e18b8cc718e8af6339106e706c52d8df89e2b1f7e9142d996acf88df8799b
|
|
mukey[4] = 0x8e45e5c61c2b24cb6382444db6698727afb063adecd72aada233d4bf273d975a
|
|
routing_info[4] (unencrypted) = 0x00040404040404040400000004000000040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
|
|
routing_info[4] (encrypted) = 0xf6a9e85e5c6a0458c98282b786ffe8efb2f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8369a3555e42db30565b2e12a8e862d0f873bd781ebf8255372e540bf6fbf4c1dae200823144f8da8df82ccd41b1b678eb91a289b88c6ee5aff71d98b64e8b17e2027fcb6826c418dbdb51f06bec866d69d9554931412808bd90021be2e0dad1d1ececfdd41fcdf6f67b88ef09eb9edcc4c226e07bdfe86b8e50e3bf68b19c0c9e0bf9aaaaddb15bc05a5666733789fa6efde866a49d0329185d852dc84a7e16c41f6c2daadc04665197152d9c0db63d0bd926c06bf3646b810186ae908a2f27a33d010b3262b0c0805c3adf135b41f15a033bb82a8db2c38160dbce672290878d7ad8d08fdd483ef9d95b3a1b2ea2b6ff0adde762e9df7b78fe5f3644df54c6d98709d70924ce6ec94650cb207b4f90d35569acb55811ad3f01b28bb2b16cfde454531b9462024abf419fb3bef80db9bb9fa5bd62a7e94f61a667e74140c8da4b27ad7b934c0824756fbc56f8ac7529fc4c5224158fd4915eba25a3f2a72a7f718a5cda6395bd8b2bc484a950aba483c8cadec376f9bee62c93f886d83371b41c361a36c15679ff933422e09c5eaf98d3bdff98680040079daed1d88cfdb74a922c59c81327133971ae5755ffe589152b2d9423a0dcd6b9540cb57a3146fdc256c573c26aa148a00ef28441b3c49ceedff190da2380ebc7bc19ef3082a195f47fdf453e0e0a54e10811b604df1d3c2238d4ec13ce0feb73216a7f100fa6eb7953f42858ef190aad1d271a5262aefb8d7ee6430061899695058feb51c914dc93a24dd1b5cf2b54334b385c54bc9b83748b966fda0d55d8da3324aa1ce4f835d44b379e785b0a95c7c9f7bae6df9cad098f40b0b159e416c5ed4d60950b40a30ecc0c125dbe6ff2cfcec7f8d36925d4252f276279c4d3680bd7180b991a320eba22c5d71079630deae6bf4f766da7cf62d6c410eb5f
|
|
hmac_data[4] = 0xf6a9e85e5c6a0458c98282b786ffe8efb2f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8369a3555e42db30565b2e12a8e862d0f873bd781ebf8255372e540bf6fbf4c1dae200823144f8da8df82ccd41b1b678eb91a289b88c6ee5aff71d98b64e8b17e2027fcb6826c418dbdb51f06bec866d69d9554931412808bd90021be2e0dad1d1ececfdd41fcdf6f67b88ef09eb9edcc4c226e07bdfe86b8e50e3bf68b19c0c9e0bf9aaaaddb15bc05a5666733789fa6efde866a49d0329185d852dc84a7e16c41f6c2daadc04665197152d9c0db63d0bd926c06bf3646b810186ae908a2f27a33d010b3262b0c0805c3adf135b41f15a033bb82a8db2c38160dbce672290878d7ad8d08fdd483ef9d95b3a1b2ea2b6ff0adde762e9df7b78fe5f3644df54c6d98709d70924ce6ec94650cb207b4f90d35569acb55811ad3f01b28bb2b16cfde454531b9462024abf419fb3bef80db9bb9fa5bd62a7e94f61a667e74140c8da4b27ad7b934c0824756fbc56f8ac7529fc4c5224158fd4915eba25a3f2a72a7f718a5cda6395bd8b2bc484a950aba483c8cadec376f9bee62c93f886d83371b41c361a36c15679ff933422e09c5eaf98d3c6b008cf6414ed6e4c42c291eb505e9f22f5fe7d0ecdd15a833f4d016ac974d33adc6ea3293e20859e87ebfb937ba406abd025d14af692b12e9c9c2adbe307a679779259676211c071e614fdb386d1ff02db223a5b2fae03df68d321c7b29f7c7240edd3fa1b7cb6903f89dc01abf41b2eb0b49b6b8d73bb0774b58204c0d0e96d3cce45ad75406be0bc009e327b3e712a4bd178609c00b41da2daf8a4b0e1319f07a492ab4efb056f0f599f75e6dc7e0d10ce1cf59088ab6e873de377343880f7a24f0e36731a0b72092f8d5bc8cd346762e93b2bf203d00264e4bc136fc142de8f7b69154deb05854ea88e2d7506222c95ba1aab065c8a851391377d3406a35a9af3ac4242424242424242424242424242424242424242424242424242424242424242
|
|
hmac[4] = 0x42c10947e06bda75b35ac2a9e38005479a6feac51468712e751c71a1dcf3e31b
|
|
|
|
rhokey[3] = 0xcbe784ab745c13ff5cffc2fbe3e84424aa0fd669b8ead4ee562901a4a4e89e9e
|
|
mukey[3] = 0x5052aa1b3d9f0655a0932e50d42f0c9ba0705142c25d225515c45f47c0036ee9
|
|
routing_info[3] (unencrypted) = 0x00030303030303030300000003000000030000000000000000000000000000000042c10947e06bda75b35ac2a9e38005479a6feac51468712e751c71a1dcf3e31bf6a9e85e5c6a0458c98282b786ffe8efb2f3f0e2cee0283a71aa4d873686d7efeac03dcb113fd91113df4bb5d5e8c13cde4bd12eced21d367381fdc31efe09695d6ecc095083c1571d10ed076ee914745479dfedcab84efd3889e6375f544562ea4a6522035738a9ba1a9ab4204339569d3d0c217324f1d5f3a107e930ade50b913777d1140096e2b26ce47486b66a6740f026ae91429115e17270c5a542b4c82ce438725060248726956e7639da64a55cec00b61719383271e0ab97dafe44ad194e7338ea841bf25a505d0041eb53dc0d0e6c3f7986f6647ede9327467212a3ca5724ece8503bfaba3800372d747abe2c174cbc2da01dd967fc0bae56d2bc7184e1d5d823661b8ff06eb466d483d6fa69a4f8b592ebc3006b7c047055b12407925ea74c2bb09ca21f4bc9d39dc4a7237ef6facbb15f5ba56d8e2ab94ad24267bf85cea55b0605cd6260b4b0f17994a03e39bebfcad0834849b188e83bf5c954dc112d33b0fada26f25d76d53ec9b95ed344059a279719d5edc953a4de2b1cc4f47d5da090c3b0f4c7eef14830f9a2230bffb722f11fd2ea82c43d58261e5a868361262abbd81b9f1e6145562ed6765aac732e7d91bfff7716509d72314d46904bcc8053cfd1e3cd7824b4b6499bf8c77762275fa4f651d163a8701f02a5ca67bb7d37787a66d269d4079aa92a489493020b11d87791a3e3ef66780bd0007c8fa2782bac7a839b57e8ace7618a75fe03604097960d2236616d579207fb943c85bef4f804e7f13d7d78ff3aab0f7f440a3005a363f32c31567b8d64669a7ae0299b06b80e4d224d2d70b80077ff966cfb8c11cf763954f398c592ca619acc2e0e86dad54b9cfa47bc10520f3c9ba2e0d2e27e0ba8ef8ece3e71c8a1ff75fe0c8369a3555e42db30565b2e12a8e862d0f873bd781ebf8255372e540bf6fbf4c1dae200823144f8da8df82ccd41b1b678eb91a289b88c6ee5aff71d98b64e8b17e2027fcb6826c418dbdb51f06bec866d69d9554931412808bd90021be2e0dad1d1ececfdd41fcdf6f67b88ef09eb9edcc4c226e07bdfe86b8e50e3bf68b19c0c9e0bf9aaaaddb15bc05a5666733789fa6efde866a49d0329185d852dc84a7e16c41f6c2daadc04665197152d9c0db63d0bd926c06bf3646b810186ae908a2f27a33d010b3262b0c0805c3adf135b41f15a033bb82a8db2c38160dbce672290878d7ad8d08fdd483ef9d95b3a1b2ea2b6ff0adde762e9df7b78fe5f3644df54c6d98709d70924ce6ec94650cb207b4f90d35569acb55811ad3f01b28bb2b16cfde454531b9462024abf419fb3bef80db9bb9fa5bd62a7e94f61a667e74140c8da4b27ad7b934c0824756fbc56f8ac7529fc4c5224158fd4915eba25a3f2a72a7f718a5cda6395bd8b2bc484a950aba483c8cadec376f9bee62c93f886d83371b41c361a36c15679ff933422e09c5eaf98d3c6b008cf6414ed6e4c42c291eb505e9f22f5fe7d0ecdd15a833f4d016ac974d33adc6ea3293e20859e87ebfb937ba406abd025d14af692b12e9c9c2adbe307a679779259676211c071e614fdb386d1ff02db223a5b2fae03df68d321c7b29f7c7240edd3fa1b7cb6903f89dc01abf41b2eb0b49b6b8d73bb0774b58204c0d0e96d3cce45ad75406be0bc009e327b3e712a4bd178609c00b41da2daf8a4b0e1319f07a492ab4efb056f0f599f75e6dc7e0d10ce1cf59088ab6e873de377343880f7a24f
|
|
routing_info[3] (encrypted) = 0x35dd8ba6f4e53e2f0372992045827fc994c3312b54591844fc713c0cca433626a09629ccb8c0e8f28648628269f29e8bcd5941429852a5e34fdfe080f74b0f19ffaf3e17e529ce3c0c58316f255e42848df14bce0781a4653c84ac8f58bf89671cd0d4b692e9e42584a52509e03f8769bb4ef6a0f6f4002c81011da7f5f9a8da9b19bd25cb25aeb3873c5fa95396b56900847794a97935e542637ef5f42f088c6e24e8e95de7be71d110872c84a60a53bbd789f3a58c1072c5fbb84192dd5f780deb14bdbbf458be297eb3244499a7921db98912625c88350cb29e71ca8d788bfb9bd11146e48659b0d86afe13b47685ec49d36e57292d819442ba516d365be31e7980c0e7b14f40807393b1391d9b83c30191d4bfe49c143da2848d2d7bfd54c32bdfdaefcd4cb84ea895e2305745d2ae257b0414563224af66f3b25d3d451bdd8331670e9dcac78b0690c4ae849d0bd8e956dbc56b5a8114008e9dc54f1252544a45861521efd6376b6c0fb34c1c433b677c08d6bf5356e81772bfeed5a894b590859cd409dedd1cd9881c3b8caed81d4d8d834dbd3e870a39e69d6a1ce2dc15df8f8c34d64d292b0b99bf17bb92b263176b65634dc8f368cf7b558fef5b259964f42ec94eeac74d0abd829baa9b04f89ea3606074a4aace03e7f2217f2dec855f4028392f64f0baddd178d56d84cab16c8484633f7c5e8e7f8651ce8a7f5ce1ca3a966562a0a2a7247d105a3114ab2adbd10cfd70b2765113c42e4d1cbcb8721a719f46b25d8579a670be085d1afd2d2e541c4a27bdfffe49674798cf690f28bf4f58ec1495561be071d1c94156f15c95f3426a7409680ef8cf335a0d4786bbb0bf108589c3c8baf10f04dc7f8beda2f70117f28c771a83890d4e1c47903d642fef8a93a216576f377db3ad5be3abe7eaa924e1e7de9ac88e07177e57cad41ef5a561f6bdb741961eddee56f3d9aef9fc4e52343f2efda3a2d40b8d2b4afa735cd5655d3014d21b41eba3a8cf34a8c29cbf94dfb9a4312ee0851c6e32896b33d52d991560e3ae97c769071453a4969374aecf7423f07ee17ce71111dc925294b0130249ad00d49e26dbfddcaf214dc8356cee3a0d7486fa6144c6c826be0892ceea30e52d7b64a13b08eda3e991f37e210ccd216108c847adb58df3b2a53553689f5119e41b4f4f221474c21e197d8a13e9cf7cf23875a0dbc6ddaeca9eb6d95add2a0054528d9dc03d59bc108157291b4caa0faa53f2511bec3088a164a0768d38d7fe3281ea8459abbe3a5b5f43c697e5cbdc995832220a3c6fcf1e82bd35f4b94b13cc9312efc3ca4e3c8199e862c551fa7916e3cb0ad17ba24e456fcd2159f9e81628c508da4c2de4825100fee1c3226d1d431a740d2d8ab0c04953b073d9a20919e0f2d03e97b3f34a1644cbeeab7d0c78d898e8c523fbccc75ffc329fafe45288e21c82817e23589d0c6db453be7d3f8ecfa0ae1d24ae80c63511193c718195255a576c1b43c8d941ba22f6d9f743a7dd558e08ac2262fd67056d60e837edd3e21ce23ef27d48c9180d845ce8c5d6d4c488fcf55af99aef02f3bdf6a07833660628a672b878f8b15427189e49bf2d9e0e7e63e3c5632d9ef1e412e9bbd732b616a353097e90494a098df6a21729f1d3658f91b1bde4aaaae58530ab0e402fc10eb0910c07cace1afd0aacb579690e6dcbc184025e4160cf4de3e47106339046724d098b5b7b92f5a2bb33c11f86d4953f372fdd9ebc260b0ee2e391420c4b11145bd439954834d9a79e78abc57e03d3ee20d239d8a13014976e3f057ab3c38ca79ee81ff8849d94dca37b0920cc3e72
|
|
hmac_data[3] = 0x35dd8ba6f4e53e2f0372992045827fc994c3312b54591844fc713c0cca433626a09629ccb8c0e8f28648628269f29e8bcd5941429852a5e34fdfe080f74b0f19ffaf3e17e529ce3c0c58316f255e42848df14bce0781a4653c84ac8f58bf89671cd0d4b692e9e42584a52509e03f8769bb4ef6a0f6f4002c81011da7f5f9a8da9b19bd25cb25aeb3873c5fa95396b56900847794a97935e542637ef5f42f088c6e24e8e95de7be71d110872c84a60a53bbd789f3a58c1072c5fbb84192dd5f780deb14bdbbf458be297eb3244499a7921db98912625c88350cb29e71ca8d788bfb9bd11146e48659b0d86afe13b47685ec49d36e57292d819442ba516d365be31e7980c0e7b14f40807393b1391d9b83c30191d4bfe49c143da2848d2d7bfd54c32bdfdaefcd4cb84ea895e2305745d2ae257b0414563224af66f3b25d3d451bdd8331670e9dcac78b0690c4ae849d0bd8e956dbc56b5a8114008e9dc54f1252544a45861521efd6376b6c0fb34c1c433b677c08d6bf5356e81772bfeed5a894b590859cd409dedd1cd9881c3b8caed81d4d8d834dbd3e870a39e69d6a1ce2dc15df8f8c34d64d292b0b99bf17bb92b263176b65634dc8f368cf7b558fef5b259964f42ec94eeac74d0abd829baa9b04f89ea3606074a4aace03e7f2217f2dec855f4028392f64f0baddd178d56d84cab16c8484633f7c5e8e7f8651ce8a7f5ce1ca3a966562a0a2a7247d105a3114ab2adbd10cfd70b2765113c42e4d1cbcb8721a719f46b25d8579a670be085d1afd2d2e541c4a27bdfffe49674798cf690f28bf4f58ec1495561be071d1c94156f15c95f3426a7409680ef8cf335a0d4786bbb0bf108589c3c8baf10f04dc7f8beda2f70117f28c771a83890d4e1c47903d642fef8a93a216576f377db3ad5be3abe7eaa924e1e7de9ac88e07177e57cad41ef5a561f6bdb741961eddee56f3d9aef9fc4e52343f2efda3a2d40b8d2b4afa735cd5655d3014d21b41eba3a8cf34a8c29cbf94dfb9a4312ee0851c6e32896b33d52d991560e3ae97c769071453a4969374aecf7423f07ee17ce71111dc925294b0130249ad00d49e26dbfddcaf214dc8356cee3a0d7486fa6144c6c826be0892ceea30e52d7b64a13b08eda3e991f37e210ccd216108c847adb58df3b2a53553689f5119e41b4f4f221474c21e197d8a13e9cf7cf23875a0dbc6ddaeca9eb6d95add2a0054528d9dc03d59bc108157291b4caa0faa53f2511bec3088a164a0768d38d7fe3281ea8459abbe3a5b5f43c697e5cbdc995832220a3c6fcf1e82bd35f4b94b13cc9312efc3ca4e3c8199e862c551fa7916e3cb0ad17ba24e456fcd2159f9e81628c508da4c2de4825100fee1c3226d1d431a740d2d8ab0c04953b073d9a20919e0f2d03e97b3f34a1644cbeeab7d0c78d898e8c523fbccc75ffc329fafe45288e21c82817e23589d0c6db453be7d3f8ecfa0ae1d24ae80c63511193c718195255a576c1b43c8d941ba22f6d9f743a7dd558e08ac2262fd67056d60e837edd3e21ce23ef27d48c9180d845ce8c5d6d4c488fcf55af99aef02f3bdf6a07833660628a672b878f8b15427189e49bf2d9e0e7e63e3c5632d9ef1e412e9bbd732b616a353097e90494a098df6a21729f1d3658f91b1bde4aaaae58530ab0e402fc10eb0910c07cace1afd0aacb579690e6dcbc184025e4160cf4de3e47106339046724d098b5b7b92f5a2bb33c11f86d4953f372fdd9ebc260b0ee2e391420c4b11145bd439954834d9a79e78abc57e03d3ee20d239d8a13014976e3f057ab3c38ca79ee81ff8849d94dca37b0920cc3e724242424242424242424242424242424242424242424242424242424242424242
|
|
hmac[3] = 0x4e888d0cc6a90e7f857af18ac858834ac251d0d1c196d198df48a0c5bf816803
|
|
|
|
rhokey[2] = 0x11bf5c4f960239cb37833936aa3d02cea82c0f39fd35f566109c41f9eac8deea
|
|
mukey[2] = 0xcaafe2820fa00eb2eeb78695ae452eba38f5a53ed6d53518c5c6edf76f3f5b78
|
|
routing_info[2] (unencrypted) = 0x0002020202020202020000000200000002000000000000000000000000000000004e888d0cc6a90e7f857af18ac858834ac251d0d1c196d198df48a0c5bf81680335dd8ba6f4e53e2f0372992045827fc994c3312b54591844fc713c0cca433626a09629ccb8c0e8f28648628269f29e8bcd5941429852a5e34fdfe080f74b0f19ffaf3e17e529ce3c0c58316f255e42848df14bce0781a4653c84ac8f58bf89671cd0d4b692e9e42584a52509e03f8769bb4ef6a0f6f4002c81011da7f5f9a8da9b19bd25cb25aeb3873c5fa95396b56900847794a97935e542637ef5f42f088c6e24e8e95de7be71d110872c84a60a53bbd789f3a58c1072c5fbb84192dd5f780deb14bdbbf458be297eb3244499a7921db98912625c88350cb29e71ca8d788bfb9bd11146e48659b0d86afe13b47685ec49d36e57292d819442ba516d365be31e7980c0e7b14f40807393b1391d9b83c30191d4bfe49c143da2848d2d7bfd54c32bdfdaefcd4cb84ea895e2305745d2ae257b0414563224af66f3b25d3d451bdd8331670e9dcac78b0690c4ae849d0bd8e956dbc56b5a8114008e9dc54f1252544a45861521efd6376b6c0fb34c1c433b677c08d6bf5356e81772bfeed5a894b590859cd409dedd1cd9881c3b8caed81d4d8d834dbd3e870a39e69d6a1ce2dc15df8f8c34d64d292b0b99bf17bb92b263176b65634dc8f368cf7b558fef5b259964f42ec94eeac74d0abd829baa9b04f89ea3606074a4aace03e7f2217f2dec855f4028392f64f0baddd178d56d84cab16c8484633f7c5e8e7f8651ce8a7f5ce1ca3a966562a0a2a7247d105a3114ab2adbd10cfd70b2765113c42e4d1cbcb8721a719f46b25d8579a670be085d1afd2d2e541c4a27bdfffe49674798cf690f28bf4f58ec1495561be071d1c94156f15c95f3426a7409680ef8cf335a0d4786bbb0bf108589c3c8baf10f04dc7f8beda2f70117f28c771a83890d4e1c47903d642fef8a93a216576f377db3ad5be3abe7eaa924e1e7de9ac88e07177e57cad41ef5a561f6bdb741961eddee56f3d9aef9fc4e52343f2efda3a2d40b8d2b4afa735cd5655d3014d21b41eba3a8cf34a8c29cbf94dfb9a4312ee0851c6e32896b33d52d991560e3ae97c769071453a4969374aecf7423f07ee17ce71111dc925294b0130249ad00d49e26dbfddcaf214dc8356cee3a0d7486fa6144c6c826be0892ceea30e52d7b64a13b08eda3e991f37e210ccd216108c847adb58df3b2a53553689f5119e41b4f4f221474c21e197d8a13e9cf7cf23875a0dbc6ddaeca9eb6d95add2a0054528d9dc03d59bc108157291b4caa0faa53f2511bec3088a164a0768d38d7fe3281ea8459abbe3a5b5f43c697e5cbdc995832220a3c6fcf1e82bd35f4b94b13cc9312efc3ca4e3c8199e862c551fa7916e3cb0ad17ba24e456fcd2159f9e81628c508da4c2de4825100fee1c3226d1d431a740d2d8ab0c04953b073d9a20919e0f2d03e97b3f34a1644cbeeab7d0c78d898e8c523fbccc75ffc329fafe45288e21c82817e23589d0c6db453be7d3f8ecfa0ae1d24ae80c63511193c718195255a576c1b43c8d941ba22f6d9f743a7dd558e08ac2262fd67056d60e837edd3e21ce23ef27d48c9180d845ce8c5d6d4c488fcf55af99aef02f3bdf6a07833660628a672b878f8b15427189e49bf2d9e0e7e63e3c5632d9ef1e412e9bbd732b616a353097e90494a098df6a21729f1d3658f91b1bde4aaaae58530ab0e402fc10eb0910c07cace1afd0aacb579690e6dcbc184025e4160cf4de3e47106339046724d098b5b7b92f5a2bb33c11f86d4
|
|
routing_info[2] (encrypted) = 0xe22ca641baa077154733abc586fae578ea0ed4c1851d0554235171e45e1e2a1868352b14951972fbeec9ffa500e74d24fd6d3b925c191c3454b97f518d68585db436277ec6404d85da476af5cfbfe7a392d4b8c931b57629c04ff70c08e51fa8d73e8ef55fd23b09430d4807dbdc4a7419c97b2e46d0568ca77526944e7c6a615475faea10de1025016f6fcb6f685ebdaf55c7908fd926f531d27e206307f7c9086355a351298fd6ed1f05d8724a6b159f52ed4cb988cde07f1d0eb0384803511b480ed31a1ecb7320bbd98da168ae64de73347d59df8ed0588aba661dc2d0bba2bc74ac0d2c479f466ee73def4a32cd806b0966b8f535e742c6a907af0f3dad003016db95194d381109c53499efcf4d868677c3a6dc4a184eccc2198aec260673a801814e60405670f557e618bb3b5df1e51cc90d995d0832b307c102b3fd1d083f52794ccb5a185885280dbd9e36ce64ddf320b6a7e340180e4f525c682bcd1f9cfa3ae5bbd8cdbd83e3d291e98606a7890bd8abbcf57aea1492fc1d6c876cad86446fc85b2db47ff2c6ea384fdda8bc53e81152687a702318c91f657253403612393ec7f864ddf5e807497cb88816f736f08a593d8d1e2c46c13675de2b2aa8c383b8610a5c772bbcf831e426f750c6358e623d9938890aa1d70297c4e4d238b14967f48da074ca469212336a77a2fe0fc80dc2ecd59a2ca389440cb2c1f9835786ad7e1f5bf3ceb27c8abe10178bffcbd888a9b31b9b9a5e308cefe00bdc25c82597dc22ff814b4dcb717be6ec6d87cf25dbb9fde6726461d504d4b9707d708238415ca3dc6e86d3738b902ff4a449597fcac06757fd97e0fe52c1addf7b34731366e2a5694883c60f4c9676ea6167a9fbf8b7d64932676e11fd38f7338e8954236ae31dbd7e2732d74a16b4d0809229ce44e696ceb383c41375ea0e40686f4e0c3967fa22a9e8a2ebb637816c8d1875edf86b1a4998b8525708a027a57852e28e7e84ab3d0db6b73b7e6775604d317139bc0146fedf45a17bc8b3559d4921cb87c51a21f374e040da55e013f4748b22e58f3a53f8ba733bf823eec2f2e8250d3584bd0719bdc36c1f411bfc3d6baf0db966ff2f60dc348da8ed5d011634677ff04c705b6a6942eaffbea4dc0ff5451083f5f7117df044b868df8ae2291ee68998f4c159e885ebcd1073f751899557546e5d8ddbee87a5747e5fa3f5610adf7dece55a339276e7efc3d9a152f222dd3f0452ee4ec56af7a5c1f3b9130ccf1c689e8e1401e8b885ca67349b69526ff523f217c3b36c643a9c46c46b0dc2d0f1d80c83435f752740ee7e423a59badfd5981706ec62d38ce07295ef4fbe23a4ab6cf85a2289e09cc5ad0bae981d3f42e9c6c85eeaff1f257e8ab99c2e93754e88ccd23fe3ad9c78be182b3944b79877aa1eced48b8fcf1f51c5cd01c4b2b111c97f0338e0efccc61e728e784c51d50371f453d926b02fae5c46e118a2f23a28d6f0830ec04b736ed84cf09ea1b0e228d13d7c8794ae6f363d100538a9baa9fbe533a909717dcce4c012d7f258aaee4b41c2e3f1bfe44a652ba8da51dc67164c43112805d474372b9076f3f3f0e7af94604f4fcddd2136dd7dc80ce3ff845924462cf52f5818aebf3b64f38f98edf8cb9c460477a2f94b891573929c4b51deafe6db81bc30680f7226a68567588f195ce96a791e28204b9b5844c28a61736ac20722fe156175210c7b9b6e1804c89c0a7ee136597b5b3de5d54be23671bc9477805ba10d03afb0715782845d2ab45df012f6644207cc5fa4739aa3eaf6bf84e790128aa08aede33bf30c6be2b264b33fac566209
|
|
hmac_data[2] = 0xe22ca641baa077154733abc586fae578ea0ed4c1851d0554235171e45e1e2a1868352b14951972fbeec9ffa500e74d24fd6d3b925c191c3454b97f518d68585db436277ec6404d85da476af5cfbfe7a392d4b8c931b57629c04ff70c08e51fa8d73e8ef55fd23b09430d4807dbdc4a7419c97b2e46d0568ca77526944e7c6a615475faea10de1025016f6fcb6f685ebdaf55c7908fd926f531d27e206307f7c9086355a351298fd6ed1f05d8724a6b159f52ed4cb988cde07f1d0eb0384803511b480ed31a1ecb7320bbd98da168ae64de73347d59df8ed0588aba661dc2d0bba2bc74ac0d2c479f466ee73def4a32cd806b0966b8f535e742c6a907af0f3dad003016db95194d381109c53499efcf4d868677c3a6dc4a184eccc2198aec260673a801814e60405670f557e618bb3b5df1e51cc90d995d0832b307c102b3fd1d083f52794ccb5a185885280dbd9e36ce64ddf320b6a7e340180e4f525c682bcd1f9cfa3ae5bbd8cdbd83e3d291e98606a7890bd8abbcf57aea1492fc1d6c876cad86446fc85b2db47ff2c6ea384fdda8bc53e81152687a702318c91f657253403612393ec7f864ddf5e807497cb88816f736f08a593d8d1e2c46c13675de2b2aa8c383b8610a5c772bbcf831e426f750c6358e623d9938890aa1d70297c4e4d238b14967f48da074ca469212336a77a2fe0fc80dc2ecd59a2ca389440cb2c1f9835786ad7e1f5bf3ceb27c8abe10178bffcbd888a9b31b9b9a5e308cefe00bdc25c82597dc22ff814b4dcb717be6ec6d87cf25dbb9fde6726461d504d4b9707d708238415ca3dc6e86d3738b902ff4a449597fcac06757fd97e0fe52c1addf7b34731366e2a5694883c60f4c9676ea6167a9fbf8b7d64932676e11fd38f7338e8954236ae31dbd7e2732d74a16b4d0809229ce44e696ceb383c41375ea0e40686f4e0c3967fa22a9e8a2ebb637816c8d1875edf86b1a4998b8525708a027a57852e28e7e84ab3d0db6b73b7e6775604d317139bc0146fedf45a17bc8b3559d4921cb87c51a21f374e040da55e013f4748b22e58f3a53f8ba733bf823eec2f2e8250d3584bd0719bdc36c1f411bfc3d6baf0db966ff2f60dc348da8ed5d011634677ff04c705b6a6942eaffbea4dc0ff5451083f5f7117df044b868df8ae2291ee68998f4c159e885ebcd1073f751899557546e5d8ddbee87a5747e5fa3f5610adf7dece55a339276e7efc3d9a152f222dd3f0452ee4ec56af7a5c1f3b9130ccf1c689e8e1401e8b885ca67349b69526ff523f217c3b36c643a9c46c46b0dc2d0f1d80c83435f752740ee7e423a59badfd5981706ec62d38ce07295ef4fbe23a4ab6cf85a2289e09cc5ad0bae981d3f42e9c6c85eeaff1f257e8ab99c2e93754e88ccd23fe3ad9c78be182b3944b79877aa1eced48b8fcf1f51c5cd01c4b2b111c97f0338e0efccc61e728e784c51d50371f453d926b02fae5c46e118a2f23a28d6f0830ec04b736ed84cf09ea1b0e228d13d7c8794ae6f363d100538a9baa9fbe533a909717dcce4c012d7f258aaee4b41c2e3f1bfe44a652ba8da51dc67164c43112805d474372b9076f3f3f0e7af94604f4fcddd2136dd7dc80ce3ff845924462cf52f5818aebf3b64f38f98edf8cb9c460477a2f94b891573929c4b51deafe6db81bc30680f7226a68567588f195ce96a791e28204b9b5844c28a61736ac20722fe156175210c7b9b6e1804c89c0a7ee136597b5b3de5d54be23671bc9477805ba10d03afb0715782845d2ab45df012f6644207cc5fa4739aa3eaf6bf84e790128aa08aede33bf30c6be2b264b33fac5662094242424242424242424242424242424242424242424242424242424242424242
|
|
hmac[2] = 0x28430b210c0af631ef80dc8594c08557ce4626bdd3593314624a588cc083a1d9
|
|
|
|
rhokey[1] = 0x450ffcabc6449094918ebe13d4f03e433d20a3d28a768203337bc40b6e4b2c59
|
|
mukey[1] = 0x05ed2b4a3fb023c2ff5dd6ed4b9b6ea7383f5cfe9d59c11d121ec2c81ca2eea9
|
|
routing_info[1] (unencrypted) = 0x00010101010101010100000001000000010000000000000000000000000000000028430b210c0af631ef80dc8594c08557ce4626bdd3593314624a588cc083a1d9e22ca641baa077154733abc586fae578ea0ed4c1851d0554235171e45e1e2a1868352b14951972fbeec9ffa500e74d24fd6d3b925c191c3454b97f518d68585db436277ec6404d85da476af5cfbfe7a392d4b8c931b57629c04ff70c08e51fa8d73e8ef55fd23b09430d4807dbdc4a7419c97b2e46d0568ca77526944e7c6a615475faea10de1025016f6fcb6f685ebdaf55c7908fd926f531d27e206307f7c9086355a351298fd6ed1f05d8724a6b159f52ed4cb988cde07f1d0eb0384803511b480ed31a1ecb7320bbd98da168ae64de73347d59df8ed0588aba661dc2d0bba2bc74ac0d2c479f466ee73def4a32cd806b0966b8f535e742c6a907af0f3dad003016db95194d381109c53499efcf4d868677c3a6dc4a184eccc2198aec260673a801814e60405670f557e618bb3b5df1e51cc90d995d0832b307c102b3fd1d083f52794ccb5a185885280dbd9e36ce64ddf320b6a7e340180e4f525c682bcd1f9cfa3ae5bbd8cdbd83e3d291e98606a7890bd8abbcf57aea1492fc1d6c876cad86446fc85b2db47ff2c6ea384fdda8bc53e81152687a702318c91f657253403612393ec7f864ddf5e807497cb88816f736f08a593d8d1e2c46c13675de2b2aa8c383b8610a5c772bbcf831e426f750c6358e623d9938890aa1d70297c4e4d238b14967f48da074ca469212336a77a2fe0fc80dc2ecd59a2ca389440cb2c1f9835786ad7e1f5bf3ceb27c8abe10178bffcbd888a9b31b9b9a5e308cefe00bdc25c82597dc22ff814b4dcb717be6ec6d87cf25dbb9fde6726461d504d4b9707d708238415ca3dc6e86d3738b902ff4a449597fcac06757fd97e0fe52c1addf7b34731366e2a5694883c60f4c9676ea6167a9fbf8b7d64932676e11fd38f7338e8954236ae31dbd7e2732d74a16b4d0809229ce44e696ceb383c41375ea0e40686f4e0c3967fa22a9e8a2ebb637816c8d1875edf86b1a4998b8525708a027a57852e28e7e84ab3d0db6b73b7e6775604d317139bc0146fedf45a17bc8b3559d4921cb87c51a21f374e040da55e013f4748b22e58f3a53f8ba733bf823eec2f2e8250d3584bd0719bdc36c1f411bfc3d6baf0db966ff2f60dc348da8ed5d011634677ff04c705b6a6942eaffbea4dc0ff5451083f5f7117df044b868df8ae2291ee68998f4c159e885ebcd1073f751899557546e5d8ddbee87a5747e5fa3f5610adf7dece55a339276e7efc3d9a152f222dd3f0452ee4ec56af7a5c1f3b9130ccf1c689e8e1401e8b885ca67349b69526ff523f217c3b36c643a9c46c46b0dc2d0f1d80c83435f752740ee7e423a59badfd5981706ec62d38ce07295ef4fbe23a4ab6cf85a2289e09cc5ad0bae981d3f42e9c6c85eeaff1f257e8ab99c2e93754e88ccd23fe3ad9c78be182b3944b79877aa1eced48b8fcf1f51c5cd01c4b2b111c97f0338e0efccc61e728e784c51d50371f453d926b02fae5c46e118a2f23a28d6f0830ec04b736ed84cf09ea1b0e228d13d7c8794ae6f363d100538a9baa9fbe533a909717dcce4c012d7f258aaee4b41c2e3f1bfe44a652ba8da51dc67164c43112805d474372b9076f3f3f0e7af94604f4fcddd2136dd7dc80ce3ff845924462cf52f5818aebf3b64f38f98edf8cb9c460477a2f94b891573929c4b51deafe6db81bc30680f7226a68567588f195ce96a791e28204b9b5844c28a61736ac20722fe156175210c7b9b6e1804c89c0a7ee136
|
|
routing_info[1] (encrypted) = 0x03445185327b8cbf5c5bfa27f925f3a9af4f431f6f7a16ad786704887cbd85bd9396df49c699c185373e4e7ac62eaf2d709eff47aa3705a235186ca412925b98902e464b80d7772900ad5040e65174840ee298625c77768d6199fa32154615bb0bd89aa137d124cb1ffcc83b85bb15ec01132794fa24cd81f94e30cc9f3de57ab16f00b29fe5456be97ea49b4b0b4601a96b8432e111ca36ae7d94c9de13ecda4ed4b7bd20a156a0697d11943871402bb1c32a312fa4f0f6ee1a0e2eb87c1fcb64d57985a7e9c07d9fba335719c04ec18607918874c513ad4c6426bd0181a3233ba12283b03be24cb8e2a530a8cb92b9bed43889267aab86d69d3d72f734e6768324125c75b25988ac2aab93da5939e2059fc0d5479d7c404b6bd1e5a9e995e47cb6966bb063377aedd689052f0a72c6576548f7264989ccd9838068b56cf7e3620f88627276674be6376007208afb027234b9e2a0267a51141ffa8ae1f3da72a8604417e63cffc3d5c4263c7e96c7ef2baa91dcf629efb87a088550b6165686c75ff9f60f24d79b5e560ceb38e987f0371cd002c1ebd09cfe3bfa1191ea1e4b23886d20a64a4526584d7beb2db9c51c3895d84cc9ecb15bff52cc64320c1f79f7d3659e2ee54a4aeed1cebb412eacd782f83ae2288c623e1a1256370262fd1afbb1a61d5e323d5bd679690105b597f027141d035a0f6ec4ef468d9a3ab39b9d54f1817878b745567f181b6678b9900299c11f21c92618da90cb10b2ecbef3d07a0b78cd35ddcc11d02e2e859f9296687268979557b99a9eaffd0875bdce1c03b1f507537916d0aba5aa437c3611ddf9e6975fc82545b67344a4f02125b08a27873079e4490519ec839a105638728d6b2dffa8024b6c4eb08dd793fbd7e53aac0e327401e1de38f826d7ac66beea3925232b0c7d086095a474b1c4f5dbb5651f5de1d1699b90bb500202673d867d00654244ece624c820d7a84db2c5e9515ace71158e45d52790a47b3b7c33ffda69b04dcf107a61a5bb0e6ab6bf06d6b44552d823f2b5969ccbe2f3986cb7180bf7acad66684117c391ff428a2023d7d29063766bb9fbb2c276c3067fab08c7fcf18fa3741b2bd409a58a4fc67d9cffde1faeb39dd86b21fa9b7930c2c6b8d28e4aeea263b3bec2bbc95b939c6ad208689204b83ea8eec2e90a42c0fde1ca8de5aaacd8a614328f83480b4a5bb5e12546ba0e56aef9e88d813dcc7c83f905c91bc5853b7d734a160f3e0efc10237aae97767abea0181c48861f2fabe52a38bcd7859d25ac5dc80eb457615d5064d77a81516b97f90c2feab7861dd9728d51a05247ef5defa05d77486812bd909195ef11c772b374d6cbe18a218af26aa19c72de077307567fa90b18eb1bc77a357ab09cc637b93d5d55793ea075285d60b04ca48bcdd45a32f55932358687db09440ff4ba255fa72e4dacee47e9029bfc16af51e121efdeb189b31dd5be103ef9dd2b5eac641768a81fce1056e6416cb8fc53b8fe946f8e37ab1f94520c3fb0d01dc15207cdec370b0fe76e5234343db30b2f8e0afdc50f1d52d761fbcd3dfcca053f01cfd3c43763546f9d5fc66e1adba7c9d66af0f61d27622f12372c4a75af5861151dcd2da571c7e90c7bde4dae9aea645f85c0781e4472e2b68d63d6789e3dc7ccb543ec47d68d1fa700c0081908a8d2e4687b6e826f4254bc169921b7e02643f3faa0264c7ff77a52205a9388d0a98c0394dc4dee81989115ade30d309374fea8435815418038534d12e4ffe88b91406a71d89d5a083e3b8224d86b2be11be32169afb04b9ea997854be9085472c342ef5fca19bf5479
|
|
hmac_data[1] = 0x03445185327b8cbf5c5bfa27f925f3a9af4f431f6f7a16ad786704887cbd85bd9396df49c699c185373e4e7ac62eaf2d709eff47aa3705a235186ca412925b98902e464b80d7772900ad5040e65174840ee298625c77768d6199fa32154615bb0bd89aa137d124cb1ffcc83b85bb15ec01132794fa24cd81f94e30cc9f3de57ab16f00b29fe5456be97ea49b4b0b4601a96b8432e111ca36ae7d94c9de13ecda4ed4b7bd20a156a0697d11943871402bb1c32a312fa4f0f6ee1a0e2eb87c1fcb64d57985a7e9c07d9fba335719c04ec18607918874c513ad4c6426bd0181a3233ba12283b03be24cb8e2a530a8cb92b9bed43889267aab86d69d3d72f734e6768324125c75b25988ac2aab93da5939e2059fc0d5479d7c404b6bd1e5a9e995e47cb6966bb063377aedd689052f0a72c6576548f7264989ccd9838068b56cf7e3620f88627276674be6376007208afb027234b9e2a0267a51141ffa8ae1f3da72a8604417e63cffc3d5c4263c7e96c7ef2baa91dcf629efb87a088550b6165686c75ff9f60f24d79b5e560ceb38e987f0371cd002c1ebd09cfe3bfa1191ea1e4b23886d20a64a4526584d7beb2db9c51c3895d84cc9ecb15bff52cc64320c1f79f7d3659e2ee54a4aeed1cebb412eacd782f83ae2288c623e1a1256370262fd1afbb1a61d5e323d5bd679690105b597f027141d035a0f6ec4ef468d9a3ab39b9d54f1817878b745567f181b6678b9900299c11f21c92618da90cb10b2ecbef3d07a0b78cd35ddcc11d02e2e859f9296687268979557b99a9eaffd0875bdce1c03b1f507537916d0aba5aa437c3611ddf9e6975fc82545b67344a4f02125b08a27873079e4490519ec839a105638728d6b2dffa8024b6c4eb08dd793fbd7e53aac0e327401e1de38f826d7ac66beea3925232b0c7d086095a474b1c4f5dbb5651f5de1d1699b90bb500202673d867d00654244ece624c820d7a84db2c5e9515ace71158e45d52790a47b3b7c33ffda69b04dcf107a61a5bb0e6ab6bf06d6b44552d823f2b5969ccbe2f3986cb7180bf7acad66684117c391ff428a2023d7d29063766bb9fbb2c276c3067fab08c7fcf18fa3741b2bd409a58a4fc67d9cffde1faeb39dd86b21fa9b7930c2c6b8d28e4aeea263b3bec2bbc95b939c6ad208689204b83ea8eec2e90a42c0fde1ca8de5aaacd8a614328f83480b4a5bb5e12546ba0e56aef9e88d813dcc7c83f905c91bc5853b7d734a160f3e0efc10237aae97767abea0181c48861f2fabe52a38bcd7859d25ac5dc80eb457615d5064d77a81516b97f90c2feab7861dd9728d51a05247ef5defa05d77486812bd909195ef11c772b374d6cbe18a218af26aa19c72de077307567fa90b18eb1bc77a357ab09cc637b93d5d55793ea075285d60b04ca48bcdd45a32f55932358687db09440ff4ba255fa72e4dacee47e9029bfc16af51e121efdeb189b31dd5be103ef9dd2b5eac641768a81fce1056e6416cb8fc53b8fe946f8e37ab1f94520c3fb0d01dc15207cdec370b0fe76e5234343db30b2f8e0afdc50f1d52d761fbcd3dfcca053f01cfd3c43763546f9d5fc66e1adba7c9d66af0f61d27622f12372c4a75af5861151dcd2da571c7e90c7bde4dae9aea645f85c0781e4472e2b68d63d6789e3dc7ccb543ec47d68d1fa700c0081908a8d2e4687b6e826f4254bc169921b7e02643f3faa0264c7ff77a52205a9388d0a98c0394dc4dee81989115ade30d309374fea8435815418038534d12e4ffe88b91406a71d89d5a083e3b8224d86b2be11be32169afb04b9ea997854be9085472c342ef5fca19bf54794242424242424242424242424242424242424242424242424242424242424242
|
|
hmac[1] = 0x2bdc5227c8eb8ba5fcfc15cfc2aa578ff208c106646d0652cd289c0a37e445bb
|
|
|
|
rhokey[0] = 0xce496ec94def95aadd4bec15cdb41a740c9f2b62347c4917325fcc6fb0453986
|
|
mukey[0] = 0xb57061dc6d0a2b9f261ac410c8b26d64ac5506cbba30267a649c28c179400eba
|
|
routing_info[0] (unencrypted) = 0x0000000000000000000000000000000000000000000000000000000000000000002bdc5227c8eb8ba5fcfc15cfc2aa578ff208c106646d0652cd289c0a37e445bb03445185327b8cbf5c5bfa27f925f3a9af4f431f6f7a16ad786704887cbd85bd9396df49c699c185373e4e7ac62eaf2d709eff47aa3705a235186ca412925b98902e464b80d7772900ad5040e65174840ee298625c77768d6199fa32154615bb0bd89aa137d124cb1ffcc83b85bb15ec01132794fa24cd81f94e30cc9f3de57ab16f00b29fe5456be97ea49b4b0b4601a96b8432e111ca36ae7d94c9de13ecda4ed4b7bd20a156a0697d11943871402bb1c32a312fa4f0f6ee1a0e2eb87c1fcb64d57985a7e9c07d9fba335719c04ec18607918874c513ad4c6426bd0181a3233ba12283b03be24cb8e2a530a8cb92b9bed43889267aab86d69d3d72f734e6768324125c75b25988ac2aab93da5939e2059fc0d5479d7c404b6bd1e5a9e995e47cb6966bb063377aedd689052f0a72c6576548f7264989ccd9838068b56cf7e3620f88627276674be6376007208afb027234b9e2a0267a51141ffa8ae1f3da72a8604417e63cffc3d5c4263c7e96c7ef2baa91dcf629efb87a088550b6165686c75ff9f60f24d79b5e560ceb38e987f0371cd002c1ebd09cfe3bfa1191ea1e4b23886d20a64a4526584d7beb2db9c51c3895d84cc9ecb15bff52cc64320c1f79f7d3659e2ee54a4aeed1cebb412eacd782f83ae2288c623e1a1256370262fd1afbb1a61d5e323d5bd679690105b597f027141d035a0f6ec4ef468d9a3ab39b9d54f1817878b745567f181b6678b9900299c11f21c92618da90cb10b2ecbef3d07a0b78cd35ddcc11d02e2e859f9296687268979557b99a9eaffd0875bdce1c03b1f507537916d0aba5aa437c3611ddf9e6975fc82545b67344a4f02125b08a27873079e4490519ec839a105638728d6b2dffa8024b6c4eb08dd793fbd7e53aac0e327401e1de38f826d7ac66beea3925232b0c7d086095a474b1c4f5dbb5651f5de1d1699b90bb500202673d867d00654244ece624c820d7a84db2c5e9515ace71158e45d52790a47b3b7c33ffda69b04dcf107a61a5bb0e6ab6bf06d6b44552d823f2b5969ccbe2f3986cb7180bf7acad66684117c391ff428a2023d7d29063766bb9fbb2c276c3067fab08c7fcf18fa3741b2bd409a58a4fc67d9cffde1faeb39dd86b21fa9b7930c2c6b8d28e4aeea263b3bec2bbc95b939c6ad208689204b83ea8eec2e90a42c0fde1ca8de5aaacd8a614328f83480b4a5bb5e12546ba0e56aef9e88d813dcc7c83f905c91bc5853b7d734a160f3e0efc10237aae97767abea0181c48861f2fabe52a38bcd7859d25ac5dc80eb457615d5064d77a81516b97f90c2feab7861dd9728d51a05247ef5defa05d77486812bd909195ef11c772b374d6cbe18a218af26aa19c72de077307567fa90b18eb1bc77a357ab09cc637b93d5d55793ea075285d60b04ca48bcdd45a32f55932358687db09440ff4ba255fa72e4dacee47e9029bfc16af51e121efdeb189b31dd5be103ef9dd2b5eac641768a81fce1056e6416cb8fc53b8fe946f8e37ab1f94520c3fb0d01dc15207cdec370b0fe76e5234343db30b2f8e0afdc50f1d52d761fbcd3dfcca053f01cfd3c43763546f9d5fc66e1adba7c9d66af0f61d27622f12372c4a75af5861151dcd2da571c7e90c7bde4dae9aea645f85c0781e4472e2b68d63d6789e3dc7ccb543ec47d68d1fa700c0081908a8d2e4687b6e826f4254bc169921b7e02643f3faa0264c7ff77a52205a9388d0a98c0394dc4dee81
|
|
routing_info[0] (encrypted) = 0xe5f14350c2a76fc232b5e46d421e9615471ab9e0bc887beff8c95fdb878f7b3a716a996c7845c93d90e4ecbb9bde4ece2f69425c99e4bc820e44485455f135edc0d10f7d61ab590531cf08000179a333a347f8b4072f216400406bdf3bf038659793d4a1fd7b246979e3150a0a4cb052c9ec69acf0f48c3d39cd55675fe717cb7d80ce721caad69320c3a469a202f1e468c67eaf7a7cd8226d0fd32f7b48084dca885d56047694762b67021713ca673929c163ec36e04e40ca8e1c6d17569419d3039d9a1ec866abe044a9ad635778b961fc0776dc832b3a451bd5d35072d2269cf9b040f6b7a7dad84fb114ed413b1426cb96ceaf83825665ed5a1d002c1687f92465b49ed4c7f0218ff8c6c7dd7221d589c65b3b9aaa71a41484b122846c7c7b57e02e679ea8469b70e14fe4f70fee4d87b910cf144be6fe48eef24da475c0b0bcc6565ae82cd3f4e3b24c76eaa5616c6111343306ab35c1fe5ca4a77c0e314ed7dba39d6f1e0de791719c241a939cc493bea2bae1c1e932679ea94d29084278513c77b899cc98059d06a27d171b0dbdf6bee13ddc4fc17a0c4d2827d488436b57baa167544138ca2e64a11b43ac8a06cd0c2fba2d4d900ed2d9205305e2d7383cc98dacb078133de5f6fb6bed2ef26ba92cea28aafc3b9948dd9ae5559e8bd6920b8cea462aa445ca6a95e0e7ba52961b181c79e73bd581821df2b10173727a810c92b83b5ba4a0403eb710d2ca10689a35bec6c3a708e9e92f7d78ff3c5d9989574b00c6736f84c199256e76e19e78f0c98a9d580b4a658c84fc8f2096c2fbea8f5f8c59d0fdacb3be2802ef802abbecb3aba4acaac69a0e965abd8981e9896b1f6ef9d60f7a164b371af869fd0e48073742825e9434fc54da837e120266d53302954843538ea7c6c3dbfb4ff3b2fdbe244437f2a153ccf7bdb4c92aa08102d4f3cff2ae5ef86fab4653595e6a5837fa2f3e29f27a9cde5966843fb847a4a61f1e76c281fe8bb2b0a181d096100db5a1a5ce7a910238251a43ca556712eaadea167fb4d7d75825e440f3ecd782036d7574df8bceacb397abefc5f5254d2722215c53ff54af8299aaaad642c6d72a14d27882d9bbd539e1cc7a527526ba89b8c037ad09120e98ab042d3e8652b31ae0e478516bfaf88efca9f3676ffe99d2819dcaeb7610a626695f53117665d267d3f7abebd6bbd6733f645c72c389f03855bdf1e4b8075b516569b118233a0f0971d24b83113c0b096f5216a207ca99a7cddc81c130923fe3d91e7508c9ac5f2e914ff5dccab9e558566fa14efb34ac98d878580814b94b73acbfde9072f30b881f7f0fff42d4045d1ace6322d86a97d164aa84d93a60498065cc7c20e636f5862dc81531a88c60305a2e59a985be327a6902e4bed986dbf4a0b50c217af0ea7fdf9ab37f9ea1a1aaa72f54cf40154ea9b269f1a7c09f9f43245109431a175d50e2db0132337baa0ef97eed0fcf20489da36b79a1172faccc2f7ded7c60e00694282d93359c4682135642bc81f433574aa8ef0c97b4ade7ca372c5ffc23c7eddd839bab4e0f14d6df15c9dbeab176bec8b5701cf054eb3072f6dadc98f88819042bf10c407516ee58bce33fbe3b3d86a54255e577db4598e30a135361528c101683a5fcde7e8ba53f3456254be8f45fe3a56120ae96ea3773631fcb3873aa3abd91bcff00bd38bd43697a2e789e00da6077482e7b1b1a677b5afae4c54e6cbdf7377b694eb7d7a5b913476a5be923322d3de06060fd5e819635232a2cf4f0731da13b8546d1d6d4f8d75b9fce6c2341a71b0ea6f780df54bfdb0dd5cd9855179f602f9172
|
|
hmac_data[0] = 0xe5f14350c2a76fc232b5e46d421e9615471ab9e0bc887beff8c95fdb878f7b3a716a996c7845c93d90e4ecbb9bde4ece2f69425c99e4bc820e44485455f135edc0d10f7d61ab590531cf08000179a333a347f8b4072f216400406bdf3bf038659793d4a1fd7b246979e3150a0a4cb052c9ec69acf0f48c3d39cd55675fe717cb7d80ce721caad69320c3a469a202f1e468c67eaf7a7cd8226d0fd32f7b48084dca885d56047694762b67021713ca673929c163ec36e04e40ca8e1c6d17569419d3039d9a1ec866abe044a9ad635778b961fc0776dc832b3a451bd5d35072d2269cf9b040f6b7a7dad84fb114ed413b1426cb96ceaf83825665ed5a1d002c1687f92465b49ed4c7f0218ff8c6c7dd7221d589c65b3b9aaa71a41484b122846c7c7b57e02e679ea8469b70e14fe4f70fee4d87b910cf144be6fe48eef24da475c0b0bcc6565ae82cd3f4e3b24c76eaa5616c6111343306ab35c1fe5ca4a77c0e314ed7dba39d6f1e0de791719c241a939cc493bea2bae1c1e932679ea94d29084278513c77b899cc98059d06a27d171b0dbdf6bee13ddc4fc17a0c4d2827d488436b57baa167544138ca2e64a11b43ac8a06cd0c2fba2d4d900ed2d9205305e2d7383cc98dacb078133de5f6fb6bed2ef26ba92cea28aafc3b9948dd9ae5559e8bd6920b8cea462aa445ca6a95e0e7ba52961b181c79e73bd581821df2b10173727a810c92b83b5ba4a0403eb710d2ca10689a35bec6c3a708e9e92f7d78ff3c5d9989574b00c6736f84c199256e76e19e78f0c98a9d580b4a658c84fc8f2096c2fbea8f5f8c59d0fdacb3be2802ef802abbecb3aba4acaac69a0e965abd8981e9896b1f6ef9d60f7a164b371af869fd0e48073742825e9434fc54da837e120266d53302954843538ea7c6c3dbfb4ff3b2fdbe244437f2a153ccf7bdb4c92aa08102d4f3cff2ae5ef86fab4653595e6a5837fa2f3e29f27a9cde5966843fb847a4a61f1e76c281fe8bb2b0a181d096100db5a1a5ce7a910238251a43ca556712eaadea167fb4d7d75825e440f3ecd782036d7574df8bceacb397abefc5f5254d2722215c53ff54af8299aaaad642c6d72a14d27882d9bbd539e1cc7a527526ba89b8c037ad09120e98ab042d3e8652b31ae0e478516bfaf88efca9f3676ffe99d2819dcaeb7610a626695f53117665d267d3f7abebd6bbd6733f645c72c389f03855bdf1e4b8075b516569b118233a0f0971d24b83113c0b096f5216a207ca99a7cddc81c130923fe3d91e7508c9ac5f2e914ff5dccab9e558566fa14efb34ac98d878580814b94b73acbfde9072f30b881f7f0fff42d4045d1ace6322d86a97d164aa84d93a60498065cc7c20e636f5862dc81531a88c60305a2e59a985be327a6902e4bed986dbf4a0b50c217af0ea7fdf9ab37f9ea1a1aaa72f54cf40154ea9b269f1a7c09f9f43245109431a175d50e2db0132337baa0ef97eed0fcf20489da36b79a1172faccc2f7ded7c60e00694282d93359c4682135642bc81f433574aa8ef0c97b4ade7ca372c5ffc23c7eddd839bab4e0f14d6df15c9dbeab176bec8b5701cf054eb3072f6dadc98f88819042bf10c407516ee58bce33fbe3b3d86a54255e577db4598e30a135361528c101683a5fcde7e8ba53f3456254be8f45fe3a56120ae96ea3773631fcb3873aa3abd91bcff00bd38bd43697a2e789e00da6077482e7b1b1a677b5afae4c54e6cbdf7377b694eb7d7a5b913476a5be923322d3de06060fd5e819635232a2cf4f0731da13b8546d1d6d4f8d75b9fce6c2341a71b0ea6f780df54bfdb0dd5cd9855179f602f91724242424242424242424242424242424242424242424242424242424242424242
|
|
hmac[0] = 0x307c7268724c3618e6817abd793adc214a0dc0bc616816632f27ea336fb56dfd
|
|
|
|
#### Final Packet
|
|
|
|
onionpacket = 0x0102eec7245d6b7d2ccb30380bfbe2a3648cd7a942653f5aa340edcea1f283686619e5f14350c2a76fc232b5e46d421e9615471ab9e0bc887beff8c95fdb878f7b3a716a996c7845c93d90e4ecbb9bde4ece2f69425c99e4bc820e44485455f135edc0d10f7d61ab590531cf08000179a333a347f8b4072f216400406bdf3bf038659793d4a1fd7b246979e3150a0a4cb052c9ec69acf0f48c3d39cd55675fe717cb7d80ce721caad69320c3a469a202f1e468c67eaf7a7cd8226d0fd32f7b48084dca885d56047694762b67021713ca673929c163ec36e04e40ca8e1c6d17569419d3039d9a1ec866abe044a9ad635778b961fc0776dc832b3a451bd5d35072d2269cf9b040f6b7a7dad84fb114ed413b1426cb96ceaf83825665ed5a1d002c1687f92465b49ed4c7f0218ff8c6c7dd7221d589c65b3b9aaa71a41484b122846c7c7b57e02e679ea8469b70e14fe4f70fee4d87b910cf144be6fe48eef24da475c0b0bcc6565ae82cd3f4e3b24c76eaa5616c6111343306ab35c1fe5ca4a77c0e314ed7dba39d6f1e0de791719c241a939cc493bea2bae1c1e932679ea94d29084278513c77b899cc98059d06a27d171b0dbdf6bee13ddc4fc17a0c4d2827d488436b57baa167544138ca2e64a11b43ac8a06cd0c2fba2d4d900ed2d9205305e2d7383cc98dacb078133de5f6fb6bed2ef26ba92cea28aafc3b9948dd9ae5559e8bd6920b8cea462aa445ca6a95e0e7ba52961b181c79e73bd581821df2b10173727a810c92b83b5ba4a0403eb710d2ca10689a35bec6c3a708e9e92f7d78ff3c5d9989574b00c6736f84c199256e76e19e78f0c98a9d580b4a658c84fc8f2096c2fbea8f5f8c59d0fdacb3be2802ef802abbecb3aba4acaac69a0e965abd8981e9896b1f6ef9d60f7a164b371af869fd0e48073742825e9434fc54da837e120266d53302954843538ea7c6c3dbfb4ff3b2fdbe244437f2a153ccf7bdb4c92aa08102d4f3cff2ae5ef86fab4653595e6a5837fa2f3e29f27a9cde5966843fb847a4a61f1e76c281fe8bb2b0a181d096100db5a1a5ce7a910238251a43ca556712eaadea167fb4d7d75825e440f3ecd782036d7574df8bceacb397abefc5f5254d2722215c53ff54af8299aaaad642c6d72a14d27882d9bbd539e1cc7a527526ba89b8c037ad09120e98ab042d3e8652b31ae0e478516bfaf88efca9f3676ffe99d2819dcaeb7610a626695f53117665d267d3f7abebd6bbd6733f645c72c389f03855bdf1e4b8075b516569b118233a0f0971d24b83113c0b096f5216a207ca99a7cddc81c130923fe3d91e7508c9ac5f2e914ff5dccab9e558566fa14efb34ac98d878580814b94b73acbfde9072f30b881f7f0fff42d4045d1ace6322d86a97d164aa84d93a60498065cc7c20e636f5862dc81531a88c60305a2e59a985be327a6902e4bed986dbf4a0b50c217af0ea7fdf9ab37f9ea1a1aaa72f54cf40154ea9b269f1a7c09f9f43245109431a175d50e2db0132337baa0ef97eed0fcf20489da36b79a1172faccc2f7ded7c60e00694282d93359c4682135642bc81f433574aa8ef0c97b4ade7ca372c5ffc23c7eddd839bab4e0f14d6df15c9dbeab176bec8b5701cf054eb3072f6dadc98f88819042bf10c407516ee58bce33fbe3b3d86a54255e577db4598e30a135361528c101683a5fcde7e8ba53f3456254be8f45fe3a56120ae96ea3773631fcb3873aa3abd91bcff00bd38bd43697a2e789e00da6077482e7b1b1a677b5afae4c54e6cbdf7377b694eb7d7a5b913476a5be923322d3de06060fd5e819635232a2cf4f0731da13b8546d1d6d4f8d75b9fce6c2341a71b0ea6f780df54bfdb0dd5cd9855179f602f9172307c7268724c3618e6817abd793adc214a0dc0bc616816632f27ea336fb56dfd
|
|
|
|
### Returning errors
|
|
|
|
We use the same parameters (node ids, shared secrets ,...) as above
|
|
|
|
# node 4 is returning an error
|
|
failure_message = 2002
|
|
# creating error message
|
|
shared_secret = b5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328
|
|
payload = 00022002007e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
|
|
um_key = 4da7f2923edce6c2d85987d1d9fa6d88023e6c3a9c3d20f07d3b10b61a78d646
|
|
raw_error_packet = 807890139cc04c1fdea98b22ebda0a831d1beebe00022002007e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
|
|
# forwarding error packet
|
|
shared_secret = b5756b9b542727dbafc6765a49488b023a725d631af688fc031217e90770c328
|
|
ammag_key = 2f36bb8822e1f0d04c27b7d8bb7d7dd586e032a3218b8d414afbba6f169a4d68
|
|
stream = e9c975b07c9a374ba64fd9be3aae955e917d34d1fa33f2e90f53bbf4394713c6a8c9b16ab5f12fd45edd73c1b0c8b33002df376801ff58aaa94000bf8a86f92620f343baef38a580102395ae3abf9128d1047a0736ff9b83d456740ebbb4aeb3aa9737f18fb4afb4aa074fb26c4d702f42968888550a3bded8c05247e045b866baef0499f079fdaeef6538f31d44deafffdfd3afa2fb4ca9
|
|
error packet for node 4: 69b1e5a3e05a7b5478e6529cd1749fdd8c66da6ffa31d2eb0f2dbbf4394713c6a8c9b16ab5f12fd45edd73c1b0c8b33002df376801ff58aaa94000bf8a86f92620f343baef38a580102395ae3abf9128d1047a0736ff9b83d456740ebbb4aeb3aa9737f18fb4afb4aa074fb26c4d702f42968888550a3bded8c05247e045b866baef0499f079fdaeef6538f31d44deafffdfd3afa2fb4ca9
|
|
# forwarding error packet
|
|
shared_secret = 21e13c2d7cfe7e18836df50872466117a295783ab8aab0e7ecc8c725503ad02d
|
|
ammag_key = cd9ac0e09064f039fa43a31dea05f5fe5f6443d40a98be4071af4a9d704be5ad
|
|
stream = 617ca1e4624bc3f04fece3aa5a2b615110f421ec62408d16c48ea6c1b7c33fe7084a2bd9d4652fc5068e5052bf6d0acae2176018a3d8c75f37842712913900263cff92f39f3c18aa1f4b20a93e70fc429af7b2b1967ca81a761d40582daf0eb49cef66e3d6fbca0218d3022d32e994b41c884a27c28685ef1eb14603ea80a204b2f2f474b6ad5e71c6389843e3611ebeafc62390b717ca53
|
|
error packet for node 3: 08cd44478211b8a4370ab1368b5ffe8c9c92fb8398715ffdcba31d358e842c21a0839ab361940011585323930fa5b9fae0c85770a2279ff59ec427ad1bbff9001c0cd1497004bd2a0f68b50704cf6d6a4bf3c8b6a0833399a24b3456961ba00736785112594f65b6b2d44d9f5ea4e49b5e1ec2af978cbe31c67114440ac51a62081df0ed46d4a3df295da0b0fe25c0115019f03f15ec86fa
|
|
# forwarding error packet
|
|
shared_secret = 3a6b412548762f0dbccce5c7ae7bb8147d1caf9b5471c34120b30bc9c04891cc
|
|
ammag_key = 1bf08df8628d452141d56adfd1b25c1530d7921c23cecfc749ac03a9b694b0d3
|
|
stream = 6149f48b5a7e8f3d6f5d870b7a698e204cf64452aab4484ff1dee671fe63fd4b5f1b78ee2047dfa61e3d576b149bedaf83058f85f06a3172a3223ad6c4732d96b32955da7d2feb4140e58d86fc0f2eb5d9d1878e6f8a7f65ab9212030e8e915573ebbd7f35e1a430890be7e67c3fb4bbf2def662fa625421e7b411c29ebe81ec67b77355596b05cc155755664e59c16e21410aabe53e8040
|
|
# error packet for node 2: 6984b0ccd86f37995857363df13670acd064bfd132c517b23a7dfb4470e7d16aff98e25d41d3dfb7466e74f81b3e545563cdd8f5524dae873de61d7bdfccd496af2584930d2b566b4f8d3881f8c043df92224f38cf094cfc09d92655989531524593ec6d6caec1863bdfaa79229b5020acc034cd6deeea1021c50586947b9b8e6faa83b81fbfa6133c0af5d6b07c017f7158fa94f0d206ba
|
|
# forwarding error packet
|
|
shared_secret = a6519e98832a0b179f62123b3567c106db99ee37bef036e783263602f3488fae
|
|
ammag_key = 59ee5867c5c151daa31e36ee42530f429c433836286e63744f2020b980302564
|
|
stream = 0f10c86f05968dd91188b998ee45dcddfbf89fe9a99aa6375c42ed5520a257e048456fe417c15219ce39d921555956ae2ff795177c63c819233f3bcb9b8b28e5ac6e33a3f9b87ca62dff43f4cc4a2755830a3b7e98c326b278e2bd31f4a9973ee99121c62873f5bfb2d159d3d48c5851e3b341f9f6634f51939188c3b9ff45feeb11160bb39ce3332168b8e744a92107db575ace7866e4b8
|
|
# error packet for node 1: 669478a3ddf9ba4049df8fa51f73ac712b9c20389b5fb185663f16115045868ab7dd8db956128dae8857add94e6702fb4c3a4de22e2e669e1ed926b04447fc73034bb730f4932acd62727b75348a648a1128744657ca6a4e713b9b646c3ca66cac02cdab44dd3439890ef3aaf61708714f7375349b8da541b2548d452d84de7084bb95b3ac2345201d624d31f4d52078aa0fa05a88b4e202
|
|
# forwarding error packet
|
|
shared_secret = 53eb63ea8a3fec3b3cd433b85cd62a4b145e1dda09391b348c4e1cd36a03ea66
|
|
ammag_key = 3761ba4d3e726d8abb16cba5950ee976b84937b61b7ad09e741724d7dee12eb5
|
|
stream = 3699fd352a948a05f604763c0bca2968d5eaca2b0118602e52e59121f050936c8dd90c24df7dc8cf8f1665e39a6c75e9e2c0900ea245c9ed3b0008148e0ae18bbfaea0c711d67eade980c6f5452e91a06b070bbde68b5494a92575c114660fb53cf04bf686e67ffa4a0f5ae41a59a39a8515cb686db553d25e71e7a97cc2febcac55df2711b6209c502b2f8827b13d3ad2f491c45a0cafe7
|
|
# error packet for node 0: 500d8596f76d3045bfdbf99914b98519fe76ea139a47d1ab34da8730a01515e63a04819d896f45610741c83ad40b7712aefaddec8c6baf7325d92ea4ca4d1df8bce517f7e54554608bf2bd8071a4f52a7a2f7ffbb1413edad81eeea5785aa9d990f2865dc23b4bc3c301a94eec4eabebca66be5cf638f693ec256aec514620cc28ee4a94bd9565bc4d4962b9d3641d4278fb319ed2b84de5
|
|
|
|
|
|
<br>
|
|
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
|