Re-encrypt or re-sign under a new key

Move protected data to another key without handling the plaintext yourself: re-encrypt a JWE for a new key, or replace a signature with one made by a new key, for example to move from a classical to a post-quantum or hybrid key.

Who can do it

An application authenticated as a cryptographic actor of your tenant. Its token must carry the scope of the operation, and the actor must hold an active Capability Grant covering the source and the target key:

No console role performs these operations.

Before you start

• The target key exists and serves the same purpose as the source: an encryption key for a JWE, a signing key for a JWS. See Create a key.
• The application can obtain a token. See Get an access token for an application.

Steps

1. Re-encrypt:
   • Java SDK: sdk.reencrypt(newKid, jwe) returns a ReencryptResult; keep getJweToken(). For files, sdk.reencryptFile(newKid, input, output) picks the path from the input's format; reencryptFileStream(newKid, sourceKid, input, output) always streams.
   • Crypto CLI: AnkaSecureCLI reencrypt-file --new-kid <kid> --input-file <file> --output-file <file>, or reencrypt-file-stream with the same options.
   • API: POST /api/v3/crypto/reencrypt with {"jweToken": {...}, "newKid": "<kid>"}. For a stream, POST /api/v3/crypto/stream/reencrypt with newKid as a query parameter.
2. Re-sign:
   • Java SDK: sdk.resign(newKid, jws) returns a ResignResult; keep getJwsToken(). For a detached signature, resignFileStream(oldJwsHeader, newKid, input, output).
   • Crypto CLI: AnkaSecureCLI resign-file --new-kid <kid> --old-signature-file <file> --new-signature-file <file>, or AnkaSecureCLI resign-file-stream --new-kid <kid> --old-signature-file <file> --input-file <file> --new-signature-file <file> for a detached signature.
   • API: POST /api/v3/crypto/resign with {"jwsToken": {...}, "newKid": "<kid>"}. For a stream, POST /api/v3/crypto/stream/resign.
3. Name the source key when the token does not name exactly one: sourceKid in the request, --source-kid in the CLI or the sourceKid argument of the SDK methods. For a JWE addressed to several keys, or a JWS signed by several keys, sourceKid is required and names the one recipient or signer that is replaced; every other one is kept in its position.
4. On a streaming re-encryption, wait for the verdict part. The source's integrity is known only at the end of the stream; an INVALID verdict means the new ciphertext must not be used. The SDK and the CLI keep the output only on a VALID verdict.

What you see when it worked

A re-encryption returns a new JWE under a fresh content encryption key for the target key, with the source and target keys, their material versions and algorithms. When a JWE addressed to several keys is re-encrypted, the replaced key can no longer read the result, and the kept recipients are listed.

A re-signature returns the JWS with the new signature in place of the old one, over the same payload. Every existing signature is verified first; a re-signature never replaces a signature that does not verify.

If it fails

Without the console

These operations have no console screen.

Related

• Streaming re-encryption with the SDK
• Crypto CLI commands