# 6.13.4.1 The randomizer is derived, not drawn

The signing entity derives the pseudo random integer from the second half of the hashed key material and the message. The digest is read as a little endian integer. Nothing is drawn from a random generator at signing time, which is the property that makes the signature reproducible.

## What it asks

Derive the randomizer exactly as the clause says, from the stored secret material and the message. Do not substitute a random nonce, and do not reseed from a generator. Prove determinism with a test that signs the same message twice and compares the output.

## What the amendment does

Inserts 6.13.4.1.

## Who it binds

The signing implementation owner.

## Evidence an auditor samples

- The code path that derives the randomizer, with the inputs named (source repository)
- The determinism test, same message signed twice (test suite)
- The review note that confirms no generator call remains on the path (review log)

## The test you can run

Sign the same message twice with the same key. Two different signatures mean a generator is still on the path.

## Common failures

- A random nonce is used because it is the pattern the team knows from another mechanism.
- The derived value is truncated to a different length than the clause specifies.

## How to close it

Determinism is easy to test and easy to lose in a refactor. Keep the two signature comparison in continuous integration, and treat any change to the derivation as a change that needs a new test vector.

## Source

ISO/IEC 14888-3:2018/FDAM 1:2026(en), draft, 6.13.4.1. Read on 21 October 2026. Our wording, not the instrument's.
https://www.iso.org/standard/89517.html

Not legal advice; does not certify.