Per-operation input
A nonce is a value intended for one use under a stated scope. An initialization vector is an input that initializes a cryptographic operation. Protocols use the terms in specific ways. The required property can be uniqueness, unpredictability, or both, and it often applies per key.
A nonce is normally not secret. Its security comes from satisfying the construction's rule and binding it to the protected record.
Construction-specific rules
Read the algorithm and protocol requirement. Do not copy one nonce strategy to another construction. Some schemes permit a random nonce with a quantified collision bound. Others use a counter, sequence, or combination of fixed and invocation fields. Some require unpredictability.
Use the library's high-level interface and recommended nonce size. Store or transmit the nonce with the ciphertext when required. Never derive it from low-entropy user data or reuse it intentionally because the plaintext is the same.
Distributed state
Design for replicas, threads, retry, failover, backup restore, virtual-machine cloning, and rollback. A local counter can repeat when two nodes share a key or when state restores. Random generation can collide when entropy or sample bounds are wrong. Partition nonce space by key or node only through a reviewed construction.
Rotate the key before the design can exhaust its safe invocation bound. Monitor invocation count and generation failure. Treat suspected nonce reuse as a key and data compromise event according to the construction.
Failure and residual risk
Nonce reuse may reveal plaintext relationships, enable forgery, or expose the key without producing a runtime warning. A timestamp alone can repeat or be attacker-controlled. A random UUID is not automatically the correct size or distribution. Encryption retries can accidentally create a second record under the same nonce with different plaintext.
Pomerium boundary
Pomerium's protocol implementations own their documented cryptographic nonce behavior. Applications must not reuse Pomerium session identifiers, request IDs, timestamps, or other public values as cryptographic nonces without a construction that explicitly supports them. Application data encryption needs its own nonce design and key scope.
Evaluation checklist
- What exact property does the selected construction require from the nonce or IV?
- Is the scope per key, sender, session, or record defined?
- Can replicas, retries, restore, cloning, or rollback repeat the value under one key?
- Is the format and length exactly what the library expects?
- Is the invocation bound measured and tied to key rotation?
- What response follows suspected generation failure or reuse?
