mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 21:32:31 +01:00
Code Issues Projects Releases Wiki Activity

Keep hmac case consistent (#547)

Browse Source 
Use `hmac` (lower-case) in packet fields to stay consistent with other fields.
This commit is contained in:
Orfeas Stefanos Thyfronitis Litos 2020-02-18 08:51:57 +00:00 committed by GitHub
parent 7b0169263e
commit a2afdfd12b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
04-onion-routing.md
View File

@ -140,7 +140,7 @@ The packet consists of four sections:
generation
- a 1300-byte `hop_payloads` consisting of multiple, variable length,
`hop_payload` payloads or up to 20 fixed sized legacy `hop_data` payloads.
- a 32-byte `HMAC`, used to verify the packet's integrity
- a 32-byte `hmac`, used to verify the packet's integrity
The network format of the packet consists of the individual sections
serialized into one contiguous byte-stream and then transferred to the packet
@ -165,11 +165,11 @@ It is 1300 bytes long and has the following structure:
2. data:
* [`varint`:`length`]
* [`hop_payload_length`:`hop_payload`]
* [`32*byte`:`HMAC`]
* [`32*byte`:`hmac`]
* ...
* `filler`
Where, the `length`, `hop_payload` (with contents dependent on `length`), and `HMAC` are repeated for each hop;
Where, the `length`, `hop_payload` (with contents dependent on `length`), and `hmac` are repeated for each hop;
and where, `filler` consists of obfuscated, deterministically-generated padding, as detailed in [Filler Generation](#filler-generation).
Additionally, `hop_payloads` is incrementally obfuscated at each hop.
@ -526,7 +526,7 @@ following operations:
- `shift_size` is defined as the length of the `hop_payload` plus the varint encoding of the length and the length of that HMAC. Thus if the payload length is `l` then the `shift_size` is `1 + l + 32` for `l < 253`, otherwise `3 + l + 32` due to the varint encoding of `l`.
- The `hop_payload` field is right-shifted by `shift_size` bytes, discarding the last `shift_size`
bytes that exceed its 1300-byte size.
- The varint-serialized length, serialized `hop_payload` and `HMAC` are copied into the following `shift_size` bytes.
- The varint-serialized length, serialized `hop_payload` and `hmac` are copied into the following `shift_size` bytes.
- The _rho_-key is used to generate 1300 bytes of pseudo-random byte stream
which is then applied, with `XOR`, to the `hop_payloads` field.
- If this is the last hop, i.e. the first iteration, then the tail of the
@ -665,7 +665,7 @@ generates `2*1300` pseudo-random bytes (using the _rho_-key), and applies the re
The first few bytes correspond to the varint-encoded length `l` of the `hop_payload`, followed by `l` bytes of the resulting routing information become the `hop_payload`, and the 32 byte HMAC.
The next 1300 bytes are the `hop_payloads` for the outgoing packet.
A special `HMAC` value of 32 `0x00`-bytes indicates that the currently processing hop is the intended recipient and that the packet should not be forwarded.
A special `hmac` value of 32 `0x00`-bytes indicates that the currently processing hop is the intended recipient and that the packet should not be forwarded.
If the HMAC does not indicate route termination, and if the next hop is a peer of the
processing node; then the new packet is assembled. Packet assembly is accomplished