smite: add BOLT 4 onion routing (Sphinx) - #170
Open
erickcestari wants to merge 2 commits into
Open
Conversation
BOLT 1 truncated integers show up as TLV values in BOLT 4 hop payloads (amt_to_forward, outgoing_cltv_value, total_msat). They are big-endian with leading zero bytes stripped, so their width is only recoverable from the enclosing TLV record: read consumes all remaining bytes, which makes them usable with TlvStream::get_as but not as a field in the middle of a message. Non-minimal encodings and values wider than the integer are rejected.
Adds an `onion` module that builds and peels BOLT 4 packets. - `keys`: shared secrets and the rho/mu/um/pad/ammag/ammagext key derivation, plus the zero-nonce ChaCha20 stream. - `payload`: the `HopPayload` TLV (types 2, 4, 6, 8, 10, 12, 16, 18), with `forward()` and `receive()` constructors. - `packet`: `OnionBuilder` for the 1366-byte packet, and `peel` for the reverse direction. Verified against `onion-test.json` and `onion-error-test.json` from the BOLT repository, vendored verbatim: the reference packet is reproduced byte for byte, peels at every hop, and the derived shared secrets and keys match. What this enables today: constructing a spec-valid onion for any route and decrypting one addressed to us. Malformed onions are reachable through `OnionBuilder::raw_hop`, which accepts the reserved payload lengths 0 and 1, non-TLV bytes, and oversized payloads, and through the public fields of `OnionPacket`. Deferred to follow-ups: - Failure decryption. `KeyType::Ammag` and `Um` are derived here but unused; obfuscating a `reason`, recovering the erring hop, and the failure codes are not implemented, so `update_fail_htlc.reason` stays opaque. - Attribution data crypto. The wire type already exists in `bolt::attribution_data`; the `ammagext` stream and the 210 truncated HMACs over it do not. - Route blinding. `HopPayload` carries `encrypted_recipient_data` and `current_path_key`, and `peel` accepts a path key, but there is no blinded path builder or `encrypted_data` TLV to produce either side. - Onion messages (type 513), which use a variable-size packet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an
onionmodule that builds and peels BOLT 4 packets.keys: shared secrets and the rho/mu/um/pad/ammag/ammagext key derivation, plus the zero-nonceChaCha20stream.payload: theHopPayloadTLV (types 2, 4, 6, 8, 10, 12, 16, 18), withforward()andreceive()constructors.packet:OnionBuilderfor the 1366-byte packet, andpeelfor the reverse direction.Verified against
onion-test.jsonandonion-error-test.jsonfrom the BOLT repository: the reference packet is reproduced byte for byte, peels at every hop, and the derived shared secrets and keys match.What this enables today: constructing a spec-valid onion for any route and decrypting one addressed to us. Malformed onions are reachable through
OnionBuilder::raw_hop, which accepts the reserved payload lengths 0 and 1, non-TLV bytes, and oversized payloads, and through the public fields ofOnionPacket.Deferred to follow-ups:
KeyType::AmmagandUmare derived here but unused; obfuscating areason, recovering the erring hop, and the failure codes are not implemented, soupdate_fail_htlc.reasonstays opaque.bolt::attribution_data; theammagextstream and the 210 truncated HMACs over it do not.HopPayloadcarriesencrypted_recipient_dataandcurrent_path_key, andpeelaccepts a path key, but there is no blinded path builder orencrypted_dataTLV to produce either side.Depends on #166