Volver a cifrar o volver a firmar con una clave nueva

Mueve datos protegidos a otra clave sin manejar tú el texto en claro: vuelve a cifrar un JWE para una clave nueva, o reemplaza una firma por otra hecha con una clave nueva, por ejemplo para pasar de una clave clásica a una post-cuántica o híbrida.

Quién puede hacerlo

Una aplicación autenticada como actor criptográfico de tu tenant. Su token debe llevar el scope de la operación, y el actor debe tener una concesión de capacidad activa que cubra la clave de origen y la clave de destino:

Operación	Scope	Concesión de capacidad
Volver a cifrar en una sola solicitud	`secure.reencrypt`	REENCRYPT sobre las claves de origen y de destino
Volver a cifrar un stream	`stream.reencryptStream`	REENCRYPT sobre las claves de origen y de destino
Volver a firmar en una sola solicitud	`secure.resign`	RESIGN sobre las claves de origen y de destino, y VERIFY sobre cada firmante que se conserva
Volver a firmar un stream	`stream.resignStream`	RESIGN sobre las claves de origen y de destino, y VERIFY sobre cada firmante que se conserva

Ningún rol de la consola realiza estas operaciones.

Antes de empezar

La clave de destino existe y sirve para el mismo propósito que la de origen: una clave de cifrado para un JWE, una clave de firma para un JWS. Consulta Crear una clave.
La aplicación puede obtener un token. Consulta Obtener un token de acceso para una aplicación.

Pasos

Vuelve a cifrar:
- SDK de Java: sdk.reencrypt(newKid, jwe) devuelve un ReencryptResult; conserva getJweToken(). Para archivos, sdk.reencryptFile(newKid, input, output) elige el camino según el formato de la entrada; reencryptFileStream(newKid, sourceKid, input, output) siempre usa streaming.
- CLI criptográfica: AnkaSecureCLI reencrypt-file --new-kid <kid> --input-file <file> --output-file <file>, o reencrypt-file-stream con las mismas opciones.
- API: POST /api/v3/crypto/reencrypt con {"jweToken": {...}, "newKid": "<kid>"}. Para un stream, POST /api/v3/crypto/stream/reencrypt con newKid como parámetro de consulta.
Vuelve a firmar:
- SDK de Java: sdk.resign(newKid, jws) devuelve un ResignResult; conserva getJwsToken(). Para una firma separada, resignFileStream(oldJwsHeader, newKid, input, output).
- CLI criptográfica: AnkaSecureCLI resign-file --new-kid <kid> --old-signature-file <file> --new-signature-file <file>, o AnkaSecureCLI resign-file-stream --new-kid <kid> --old-signature-file <file> --input-file <file> --new-signature-file <file> para una firma separada.
- API: POST /api/v3/crypto/resign con {"jwsToken": {...}, "newKid": "<kid>"}. Para un stream, POST /api/v3/crypto/stream/resign.
Nombra la clave de origen cuando el token no nombra exactamente una: sourceKid en la solicitud, --source-kid en la CLI o el argumento sourceKid de los métodos del SDK. Para un JWE dirigido a varias claves, o un JWS firmado por varias claves, sourceKid es obligatorio y nombra el único destinatario o firmante que se reemplaza; todos los demás se conservan en su posición.
En un nuevo cifrado en streaming, espera la parte del veredicto. La integridad del origen solo se conoce al final del stream; un veredicto INVALID significa que el nuevo texto cifrado no se debe usar. El SDK y la CLI conservan la salida solo con un veredicto VALID.

Qué ves cuando funcionó

Un nuevo cifrado devuelve un JWE nuevo con una clave de cifrado de contenido nueva para la clave de destino, con las claves de origen y de destino, sus versiones de material y sus algoritmos. Cuando se vuelve a cifrar un JWE dirigido a varias claves, la clave reemplazada ya no puede leer el resultado, y se listan los destinatarios que se conservan.

Una nueva firma devuelve el JWS con la firma nueva en lugar de la anterior, sobre la misma carga útil. Primero se verifica cada firma existente; una nueva firma nunca reemplaza una firma que no se verifica.

Si falla

Qué ves	Causa	Qué hacer
`400` que nombra `sourceKid` o `newKid`	Falta `sourceKid` donde es obligatorio, no nombra ningún destinatario o firmante del token, o `newKid` nombra uno que se conserva	Nombra la única clave que se reemplaza, y un destino que no esté ya en el token
`400` `.../errors/invalid-input` al volver a firmar	Una firma del token no se verifica. No se firma nada	No confíes en el token
`400` `.../errors/key-operation-incompatible`	Las claves de origen y de destino son de clases distintas, por ejemplo un origen simétrico y un destino asimétrico	Elige un destino de la misma clase
`403` `.../errors/forbidden`	Al token le falta el scope, o el actor no tiene ninguna concesión que cubra las claves de origen y de destino	Pide a un administrador del tenant que revise las concesiones del actor
`404` `.../errors/not-found`	La clave de origen o la de destino no existe o no puede servir para la operación	Revisa los identificadores de clave
`409` `.../errors/invalid-key-state` o `.../errors/conflict`	Una clave está revocada o suspendida	Usa claves activas
`422` con un detalle que indica que no se pudo descifrar porque la clave no coincide o falló la integridad del texto cifrado ("Unable to decrypt: key mismatch or ciphertext integrity failure.")	Se alteró el JWE de origen, o su confirmación de clave no coincide	No uses los datos
Un nuevo cifrado en streaming termina con el veredicto `INVALID`	Se alteró el texto cifrado de origen	Descarta la salida; el SDK lanza `StreamIntegrityException` y no escribe ningún archivo

Sin la consola

Estas operaciones no tienen pantalla en la consola.

Superficie	Cómo
SDK de Java	`reencrypt`, `reencryptFile`, `reencryptFileStream`, `resign`, `resignFileCompact`, `resignFileStream` en `AuthenticatedSdk`
CLI criptográfica	`AnkaSecureCLI reencrypt-file`, `reencrypt-file-stream`, `resign-file`, `resign-file-stream`
API	`POST /api/v3/crypto/reencrypt` (`reencryptData`), `POST /api/v3/crypto/stream/reencrypt` (`reencryptDataStream`), `POST /api/v3/crypto/resign` (`resignData`), `POST /api/v3/crypto/stream/resign` (`resignDataStream`)

Relacionado

Estas páginas están en inglés: