Keep hmac case consistent

Change `hmac` to `HMAC` fields in packet description to keep consistent
with the convention of uppercase cryptographic acronym field names

04-onion-routing.md

@@ -132,7 +132,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
@@ -157,11 +157,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.
 
@@ -512,7 +512,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
@@ -645,7 +645,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