HMTFTP - HMAC-based Trivial File Transfer Protocol (v0.1)

TFTP () is extremely simple but offers no security properties. HMTFTP v0.1 keeps UDP, a fixed header with TLVs, and a block-and-ACK transfer model, while introducing an optional AEAD protection based on a pre-shared key (PSK). The intended scope covers LAN or controlled networks, device provisioning, and small images/configurations. HMTFTP aims to remain comprehensible and implementable on constrained systems, reusing common cryptographic primitives and clear operational guidance. It is not meant to compete with secure, general-purpose transports such as TLS or QUIC (), but to provide a small and deterministic surface fit for specific operational niches.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in and when, and only when, they appear in all capitals. Terminology: PSK - pre-shared key; AEAD - Authenticated Encryption with Associated Data; AAD - Additional Authenticated Data; CSPRNG - cryptographically secure pseudorandom number generator; PMTU - Path Maximum Transmission Unit.

HMTFTP exchanges begin with a stateless discovery and capability exchange, followed by a transfer request and a TFTP-like data/acknowledgment loop. When encryption is negotiated, all DATA payloads are protected with AES-256-GCM and the header and TLVs are authenticated as AAD. Flow (happy path): HELLO -> HELLO_ACK; NEGOTIATE -> NEGOTIATE_ACK; XFER_REQ (GET or PUT) -> DATA/ACK ... -> EOF. Opcodes: HELLO(0), HELLO_ACK(1), NEGOTIATE(2), NEGOTIATE_ACK(3), DATA(4), ACK(5), ERROR(6 - reserved codes), XFER_REQ(7). TLVs (Type:Length): CNONCE(0x08,16), SNONCE(0x09,16), BLKSIZE(0x10,2), FNAME(0x20,var), MODE(0x21,1 - 1=PUT, 2=GET), ENC(0x22,1 - 1=request), CIPHER(0x23,1 - 1=AES-256-GCM). Additional TLVs MAY be defined; unknown TLVs MUST be ignored if the critical bit is not set. Default UDP port: user-configured (examples use 49696). BLKSIZE range: 64..4096 octets (default 512). EOF is signaled by a DATA block strictly shorter than BLKSIZE.

All multi-octet fields use network byte order (big-endian). The fixed header is 24 octets:

Magic (16 bits): 0x484D ("HM").
Ver (4) | Op (4): Protocol version and opcode.
Flags (8): Bitmask; see below.
Reserved (8): MUST be zero.
Pad (8): MUST be zero.
SessionID (32): Chosen by the initiator.
Seq (32): Monotonically increasing data sequence starting at 0.
Ack (32): Last contiguous block received.
HdrLen (16): Length in octets of the TLV area following the header.
PayLen (16): Length in octets of the payload (ciphertext when ENC=1).
Reserved2 (16): MUST be zero.

Flags: 0x01 = TLVs present; 0x02 = ENCRYPTED. When ENCRYPTED=1, the GCM tag (16 octets) follows the payload. AAD: the AEAD AAD MUST cover the entire 24-octet fixed header, and in v0.1 also the TLV area (HdrLen octets).

TLVs are encoded as Type(1), Length(1), Value(Length). Types are unsigned 8-bit; Length is unsigned 8-bit. Multi-octet values within TLVs are big-endian.

HMTFTP runs over UDP/IPv4 (and MAY run over UDP/IPv6). The internal maximum datagram size is 4096 octets. To avoid IP fragmentation, BLKSIZE SHOULD be selected such that IP header + UDP header + HMTFTP header + TLVs + payload (+ tag if encrypted) remain within the PMTU. Implementations SHOULD follow for UDP usage, and use (IPv4) and (IPv6) PMTU discovery or PLPMTUD. Senders SHOULD react to ICMP Packet Too Big or retransmission timeouts by reducing BLKSIZE. Retransmissions: a sender maintains an RTO with exponential backoff. ACKs carry the last in-order block number; selective ACKs are out of scope for v0.1.

Material and inputs:

PSK: 32 octets generated with at least 128 bits of entropy (preferably 256), stored with OS permissions 0400/0600.
CNONCE and SNONCE: 16 octets each from a CSPRNG.
HKDF-SHA-256 (): IKM = PSK; salt = CNONCE || SNONCE (32 octets); info = "hmtftp v1 keys". Output: key (32) and iv_base (12). v0.1 uses iv_base[0..7] (8 octets) to build the IV.
GCM IV construction: IV = iv_base[0..7] || seq_be32, totaling 12 octets. For a given key, key/IV pairs MUST be unique. Before seq wraps (2^32), a new session SHOULD be negotiated well in advance (for example at 2^24 blocks).
AAD and tag: AAD is the 24-octet header and the TLV area (HdrLen). The GCM tag is 16 octets appended after the payload.
Retransmissions: a given Seq MUST retransmit the exact same ciphertext and tag; an endpoint MUST NOT re-encrypt a modified payload under the same (key, IV).
On AEAD failure: silently drop (no ERROR, no ACK) to avoid validity oracles.

The CIPHER TLV selects AEAD_AES_256_GCM when ENC is requested, as specified in . Future ciphersuites MAY be registered; endpoints MUST ignore unknown ciphers when ENC is not requested.

XFER_REQ includes MODE (PUT or GET), FNAME, and optionally BLKSIZE, ENC, and CIPHER. The server replies with ACK(0) to confirm parameters or ERROR. Data blocks are numbered from 0. Each DATA carries the current Seq (block number) and PayLen up to BLKSIZE. The receiver sends ACK with Ack set to the highest contiguous block received. A block shorter than BLKSIZE indicates EOF. ERROR codes (non-exhaustive): 0x01 = Unsupported TLV; 0x02 = Invalid parameter; 0x03 = Access denied; 0x04 = Not found; 0x05 = Integrity failure; 0x06 = Internal error.

Logging: Implementations SHOULD avoid logging keys, PSKs, and nonces. Logging of session identifiers, aggregate sizes, timing, negotiated parameters, and ciphersuite is RECOMMENDED. PSK lifecycle: PSKs MUST NOT be embedded in images or world-readable. Rotation policies SHOULD be in place; devices SHOULD provide out-of-band key provisioning. Amplification: Servers SHOULD cap the size of unauthenticated responses and MAY require a cookie mechanism for untrusted networks in future versions.

Threat model includes passive observers (confidentiality), on-path adversaries (integrity, authenticity), off-path spoofers, DoS, and reflection/amplification. See and . No PFS: v0.1 uses only PSK and does not provide forward secrecy. A future extension may add PSK + ECDH. Replay and duplicates: receivers SHOULD de-duplicate on (SessionID, Seq). Anti-replay windows MAY be used; session lifetimes SHOULD be bounded. Downgrade: endpoints SHOULD reject negotiation that drops from ENC=1 to ENC=0 after initial agreement. A future KEY_CONFIRM message can strengthen this. Limits: Implementations MUST enforce AEAD usage limits and IV uniqueness. Resource caps SHOULD mitigate DoS. See also for AEAD usage limits.

This document has no IANA actions. See for general IANA policy guidance if future code points are requested.

Example (hex):

PSK = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
CNONCE = 00112233445566778899aabbccddeeff
SNONCE = 0102030405060708090a0b0c0d0e0f10
HKDF-salt = CNONCE || SNONCE
info = "hmtftp v1 keys"
Derived key (32) and iv_base (12) - implementation-defined output for this example.

The author thanks reviewers and operators for early feedback and implementation guidance.