Key Below Security-Strength Floor

URI: https://docs.ankatech.co/errors/key-below-security-strength-floor
HTTP Status: 403 Forbidden

When you see this

A request asked a key to apply protection — to encrypt, to sign, or to be the target of a re-encryption or a re-signature — and the key's security strength is below the tenant's minimum security strength (minSecurityStrengthBits of its algorithm policy). Nothing was encrypted or signed.

The key itself is not changed by the refusal. Everything it already protected still decrypts and verifies, and it can still be the source of a re-encryption or a re-signature onto a key at or above the minimum, which is how data moves off it.

Which operations are refused

NIST SP 800-131A Rev. 2 (§1.2) and SP 800-57 Part 1 Rev. 5 (§5.6.2) separate applying protection, which is disallowed below the minimum, from processing data that is already protected ("legacy use"), which stays allowed so that old data remains readable.

A key's security strength is the one its algorithm is admitted on at creation: the algorithm's classical security strength in bits (RSA-2048 112, RSA-3072 128, P-256 128, ML-KEM-768 192, ...), and for a composite key the strength of its weaker component. At the default minimum of 112 bits no catalogue algorithm is refused.

Common Causes

• The tenant's minimum was raised after the key was created. A key created under a minimum of 112 bits keeps working for decryption and verification, but no longer protects new data under a minimum of 128.
• The deployment's minimum was raised. A tenant enforces the larger of its own minimum and the deployment's.
• A composite key has one weaker component. X25519+ML-KEM-768 is admitted on 128 bits, the strength of X25519, not on the 192 bits of ML-KEM-768.

Response Example

{
  "type": "https://docs.ankatech.co/errors/key-below-security-strength-floor",
  "title": "Key Below Security-Strength Floor",
  "status": 403,
  "detail": "Operation 'encrypt' is refused: the key's security strength is 112 bits, below the tenant's minimum of 128 bits. Protect new data with a key at or above the minimum; what this key already protected can still be decrypted and verified, and re-encrypted or re-signed onto a stronger key.",
  "instance": "/api/v3/crypto/encrypt",
  "correlationId": "3f2b8c1e-6d4a-4b7e-9a05-1c8e2d7f4a60",
  "timestamp": 1768472400,
  "extensions": {
    "securityStrengthBits": 112,
    "minSecurityStrengthBits": 128
  }
}

• extensions.securityStrengthBits: the key's security strength in bits (a composite key's weaker component).
• extensions.minSecurityStrengthBits: the tenant's effective minimum in bits.

The detail names the refused operation (encrypt or sign) and the two strengths, never the key. On a PKCS#7 conversion the refused signer or recipient is named under extensions.actor (index, role, leg), never by its key. The refusal is decided after the caller's Capability Grant for the key, so it tells the caller nothing about a key it may not use.

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. There is no Retry-After: retrying cannot succeed.

Where it is answered

Every operation that applies protection with a tenant key, on the buffered, streaming and PKCS#7 conversion routes. On a streaming operation the refusal is decided before any output exists.

Each refusal is recorded in the audit trail as a signed crypto operation with status DENIED and error code KEY_BELOW_SECURITY_STRENGTH_FLOOR, naming the refused key and its material version.

When the tenant's algorithm policy cannot be read or verified, the minimum is not known and an operation that applies protection is refused with the generic Forbidden answer of the key lifecycle gate instead; decryption and verification keep the lifecycle gate's own answer.

How to Resolve

1. Protect new data with a stronger key. Create or rotate to a key whose algorithm meets the minimum, and encrypt or sign with it.

2. Move existing data off the weak key. Re-encrypt or re-sign with the weak key as the source and the stronger key as the target: the source leg is legacy use and is admitted. Two cases cannot be moved that way, because the operation itself applies protection with the weak key again:

   • a multi-recipient JWE whose remaining recipients are below the minimum: a re-encryption keeps every recipient it does not replace and encrypts to them again;
   • a PKCS#7 artifact whose signers or recipients are below the minimum: the conversion signs and encrypts to every one of them.

   For those, decrypt (or verify) the data, which stays admitted, and encrypt (or sign) it again with a key at or above the minimum. 3. Check the policy. The tenant's minimum is minSecurityStrengthBits of its algorithm policy, or the deployment's when the deployment's is larger — see Key algorithm availability policy^*.

Standards basis

NIST SP 800-131A Rev. 2 §1.2 and NIST SP 800-57 Part 1 Rev. 5 §5.6.1-§5.6.2.

Related: Algorithm Not Admitted — the same minimum refusing a key's creation, rotation or import; Key Material Expired and Key Material Usage Exhausted — the other refusals of an operation that applies protection.