Summary

  • RFC 2040 made “RC5” operational only as a full tuple: word size, rounds, key length and bytes, mode, IV and the final-block rule all have to agree.
  • Its objects, sample code, ASN.1 and vectors establish bounded implementation evidence; they do not establish security, entropy, IV uniqueness, memory erasure, deployment or present-day suitability.

In October 1996, Robert Baldwin and Ronald Rivest published an Informational memo with an unusually practical promise. RFC 2040 would define four ciphers in enough detail for separate implementations to interoperate: raw RC5, RC5-CBC, RC5-CBC-Pad and RC5-CTS. The status matters. The RFC Editor record says plainly that the document is not an Internet Standard. The memo also says it is a restatement of existing material, including Rivest's earlier RC5 work and established CBC and padding descriptions.

That leaves a more precise historical achievement. RFC 2040 turned an adjustable cipher family into a checkable interface. It showed why an algorithm name is only the first line of an identity record.

The parameter tuple comes before the brand

RC5 is parameterised. W is the word size; the block size B is twice that value, and BB is the block size in bytes. R is the round count. b is the number of bytes in the user key, and K is that byte sequence. The expanded table S contains T = 2(R+1) words. CBC adds an initialisation vector I of exactly one block.

Two programs can therefore both say “RC5” while computing different transformations. They may disagree on W, on R, on the length or byte order of K, on the selected mode, or on how the final partial block is handled. Even matching W/R/b is insufficient if the actual key bytes or IV differ. Interoperability belongs to the complete tuple and to the state transition, not to the label.

The RFC makes that dependence visible in key expansion. It packs the user-key bytes into words in little-endian order, builds S from constants determined by W, and mixes the temporary key array and expanded table for three times the larger of their lengths. The sample C fixes the block at 64 bits for concreteness. That choice is part of the tested path; it is not evidence that every parameterisation was exercised.

Objects make hidden state inspectable

The memo explains its cipher bottom-up through key and cipher objects. The key object can be created, set and destroyed. The CBC object stores the padding flag, round count, expanded key, original IV, current chain block, a partial input block and an index into it.

That structure is not merely programming style. It names the state on which the next output depends. Encrypt_Init binds a key, expands it, restores the chaining block from the IV and prepares the input buffer. SetIV changes the IV without replacing the expanded key, while also clearing the buffered position and resetting the chain. Update may be called repeatedly: it holds incomplete input, emits only full blocks, XORs each complete plaintext block with the current chain, encrypts it and turns the result into the next chain.

Then Final decides what the message meant. In ordinary CBC, residual bytes are an error because the input must be block-aligned. In CBC-Pad, finalisation always creates a block. It appends between one and BB bytes, each equal to the padding length. A message already aligned to the block boundary receives an entire padding block. The same Update history can therefore produce a valid result or an error depending on the object's mode and its final call.

Three endings, three identities

The most consequential distinction appears at the last block.

Ordinary RC5-CBC accepts only a multiple of the block size. RC5-CBC-Pad accepts other lengths by making the ciphertext longer. RC5-CTS preserves the plaintext length by treating the final two portions specially: encrypt the chained penultimate block, expose the needed prefix of that intermediate value as the short final ciphertext, zero-pad the final plaintext fragment, combine it with the intermediate value, and encrypt again to form the preceding full ciphertext block. The output order is the full block followed by the stolen fragment.

This is why CTS cannot be bolted onto a streaming interface as a cosmetic option. The implementation must retain up to two blocks until finalisation. Before that point it does not know which apparently complete block is actually penultimate, nor how many bytes must be stolen.

The current RFC Editor errata record is part of the executable reading. Verified Errata 513 corrects “any length” to plaintext longer than one block. Errata 514 says encryption uses the IV when the earlier ciphertext block does not exist. Errata 587 restores a missing XOR in the decryption procedure and applies the same IV rule for short messages. An implementation built from the uncorrected prose can be internally coherent and still disagree at the boundary.

What the vectors actually test

Section 9 states its ambition narrowly: help confirm the correctness of an implementation. The presented test program uses an eight-byte block and reads a padding flag, round count, key bytes, eight-byte IV and plaintext. Its vectors vary those inputs and report ciphertext.

That is valuable evidence. A matching output shows that, for one exact input tuple, the implementation agreed with the document's key conversion, expansion, block operation, CBC chaining and finalisation path. A mismatch reveals that agreement has failed somewhere.

But the vector is composite evidence. A passing ciphertext does not independently certify every internal step, and a failing result does not identify the faulty step. More importantly, the listed cases exercise CBC and CBC-Pad—not CTS. The CTS construction is described in prose and repaired by errata, but this RFC does not supply a corresponding CTS vector suite.

Nor can the vectors answer operational questions they never observe. They do not show how a key or IV was generated, whether an IV was unique, whether callers respected message boundaries, whether memory was erased in a compiled program, whether any protocol transported the parameters faithfully, or whether the code was deployed.

ASN.1 identifies only part of the machine

Section 11 assigns numerical object-identifier arcs ending in 8 and 9 to CBC and CBC-Pad. Its parameter sequence carries a version, a round count, a block size and an optional IV. When the IV is absent, the historical rule supplies a zero block of the selected size. Verified Errata 6380 repairs the ASN.1 names, letter case and constraint syntax; it does not add new fields.

The omission is revealing. The ASN.1 parameters do not contain b, the actual key bytes or the expanded table, and the section assigns no identifier to CTS. An algorithm identifier can therefore settle part of a decoding contract while leaving decisive execution inputs elsewhere. An absent IV having a defined default proves how the encoding is to be interpreted; it says nothing about uniqueness or randomness in a real exchange.

The evidentiary boundary

RFC 2040's sample destroy functions write zeros into key and cipher storage before freeing it. That proves the source-level instruction. It does not prove that a compiler retained the writes, that an allocator had no copies, or that a running system erased all sensitive material. Likewise, the memo's 1996 security and patent discussion records a contemporary context, not a current security assessment or legal finding.

Read at the right level, the document is unusually strong evidence. It identifies the decisions that must converge before independently written programs can agree. Read at the wrong level, those same details tempt the observer to infer security, deployment and operating discipline from a test that only compared bytes.

Sources