Clause 5: Requirements on the usage of tweakable block ciphers

What the clause requires

Whichever way the key and tweak split the tweakey, the key must be at least 128 bits. Stricter conditions that a use case needs must be met. Skinny-64/192 is limited to schemes whose security argument holds below 2^64 data blocks. The tweakey is key followed by tweak, and a key must not be reused in instances whose tweak lengths differ.

What the public text does not state

• How a use case demonstrates that its stricter conditions are satisfied
• Whether the amendment changes any of the four requirements

What it means for you

This is the only clause in the ISO public preview that places duties on the user rather than describing an algorithm, so it is the clause the buyer should read first. Four requirements sit in it. The first is a floor: however the implementer divides the input, the secret part is at least 128 bits. The second is a conditional: where a mode of operation needs more than the base conditions, those extra conditions apply as well. The third is a data bound on the smallest Skinny variant. The fourth is a separation rule across tweak lengths.

The tweak is not secret by default. The text treats it as public, and it allows a use case to add stricter conditions where its security needs them. That is the sentence to read twice: the default is public, and the exception runs towards more protection, never less.

The key floor is easy to test and easy to get wrong in a procurement answer. A module that offers Deoxys-TBC-384 could be configured with a 128-bit key and a 256-bit tweak, which meets the floor, or with a 256-bit key and a 128-bit tweak, which also meets it. The lengths in the algorithm name are the tweakey length, not the key length. The record states that distinction on every Deoxys and Skinny page because it is the most common misreading of Table 1.

The Skinny-64/192 bound is the requirement most likely to be missed. The clause does not ban the algorithm. It limits the security argument to a data volume, and it says the scheme built on the algorithm must carry an advantage bound that stays meaningful below 2^64 blocks. For a buyer, that becomes a question to the engineering team: what is the data volume per key, and what is the bound at that volume?

The separation rule is short and absolute in the text. The same keying material must not appear in two instances whose tweak sizes differ. A key management procedure that rotates by key label but not by tweak length will not show this, so the record treats it as a separate evidence line rather than folding it into key rotation.

Evidence to keep

What an auditor or a customer is likely to ask for

Artefact	Owner	Why it matters
Key management procedure showing the key length per algorithm and use case	Security operations	Proves the 128-bit floor is applied, not assumed.
Tweak policy stating what the tweak is, who may see it, and whether a use case needs stricter conditions	Security architecture	The clause makes the tweak public by default and conditional by exception.
Data volume and advantage bound for any Skinny-64/192 use	Engineering	The clause ties the algorithm to a bound below 2^64 blocks.
Key separation record across tweak lengths	Security operations	The no-reuse rule is across instances, not only across time.
Mode selection record for any authenticated encryption or MAC built on the primitive	Engineering	The stricter-conditions sentence points at the mode, not the primitive.

How to verify it

Take one deployed configuration. Write down the block length, the key length and the tweak length separately. If the key is below 128 bits, or the three lengths cannot be produced, the configuration is outside the clause.

Dates

The kit plan for clause 5 sets the evidence review at 17 June 2027, 90 days before the estimated publication date of 15 September 2027.

Cross references

• 1 Scope
• 3 Terms and definitions
• 6 Deoxys-TBC
• 7 Skinny
• A Annex A, Numerical examples

Where this comes from