# Codificador de Web Push: petición RFC 8030 + VAPID + cifrado RFC 8291

Codifica un envío completo de Web Push: cifrado aes128gcm del RFC 8291, JWT ES256 VAPID del RFC 8292, cabeceras RFC 8030, correspondencia con APNs/FCM y verificación por descifrado de ida y vuelta.

> Página canónica: https://elysiatools.com/es/tools/web-push-rfc8030-vapid-rfc8291-payload-encrypted-content-encoder

- **Categoría:** Format Conversion

- **Palabras clave:** cifrado web push, rfc 8291 aes128gcm, jwt vapid, rfc 8292, cabeceras rfc 8030, p256dh auth secret, ecdh p-256 hkdf, cabeceras apns, collapse key fcm, verificación de ida y vuelta

## Descripción general

El cifrado sigue el RFC 8291 al pie de la letra: ECDH sobre P-256 entre una clave efímera del servidor de aplicación y la clave p256dh de la suscripción, combinación de claves HKDF-SHA256 con el auth secret (contexto «WebPush: info»), sal aleatoria de 16 bytes, derivación de CEK/nonce mediante contextos «Content-Encoding» y AES-128-GCM con la cabecera binaria del RFC 8188 (sal + tamaño de registro + id de clave). La implementación reproduce byte a byte los ejemplos del RFC 8291 §5 y del draft-ietf-webpush-encryption-04.

## Entradas

- **Carga útil (texto claro)** (textarea): Message body sent to the user agent, e.g. {"title":"Order shipped"}
- **Codificación de contenido** (select)
- **p256dh de la suscripción (base64url)** (text): uncompressed P-256 point from subscription.keys.p256dh
- **Secreto auth de la suscripción (base64url)** (text): 16-byte secret from subscription.keys.auth
- **Clave privada del receptor (base64url, opcional — habilita la verificación)** (text): user-agent P-256 scalar, only if you own the subscription keys
- **Clave privada efímera del servidor (base64url)** (text): 32-byte P-256 scalar; generate fresh per send in production
- **Sal (base64url, 16 bytes)** (text): random 16 bytes per message in production
- **Bytes de relleno** (number)
- **TTL en segundos (RFC 8030)** (number)
- **Urgencia (RFC 8030)** (select)
- **Tema (RFC 8030, opcional)** (text): coalescing key, e.g. new-message
- **Host del servicio de push** (text)
- **Ruta del endpoint** (text)
- **Construir cabecera VAPID Authorization (RFC 8292)** (checkbox)
- **VAPID sub (contacto)** (text)
- **VAPID aud (origen del servicio)** (text)
- **VAPID exp (segundos unix)** (number)
- **Clave privada de firma VAPID (base64url)** (text): P-256 scalar, MUST differ from the encryption key

## Cuándo usarlo

- Al implementar o depurar el protocolo de cifrado de mensajes Web Push en un servidor de aplicaciones.
- Al diagnosticar errores de autenticación VAPID o rechazos de payload por parte de servicios como FCM, Mozilla Push Service o APNs.
- Al validar vectores de prueba criptográficos para verificar la derivación de claves CEK y nonces binarios.

## Cómo funciona

- Calcula el secreto compartido ECDH sobre P-256 entre la clave privada del servidor y la clave pública p256dh del suscriptor.
- Aplica HKDF-SHA256 junto con el auth secret y la sal de 16 bytes para derivar la Content Encryption Key (CEK) y el nonce.
- Cifra el payload en texto claro mediante AES-128-GCM, estructurando el cuerpo según el RFC 8188 o las cabeceras draft-04.
- Genera el token JWT VAPID firmado con ES256 y ensambla las cabeceras HTTP/2 del RFC 8030 (TTL, Urgency, Topic y Authorization).

## Casos de uso

- Generación de payloads cifrados y cabeceras exactas para pruebas unitarias de bibliotecas Web Push en backend.
- Auditoría técnica de tokens JWT VAPID y comparación de cabeceras para compatibilidad entre FCM y APNs.
- Inspección de valores criptográficos intermedios (PRK, IKM, CEK y nonce) frente a las especificaciones oficiales del IETF.

## Preguntas frecuentes

### ¿Cuál es la diferencia entre aes128gcm y aesgcm?

aes128gcm es el estándar oficial (RFC 8291/8188) que incluye metadatos en el cuerpo cifrado, mientras que aesgcm (draft-04) usa cabeceras HTTP separadas (Encryption y Crypto-Key).

### ¿Por qué se requiere un authSecret de 16 bytes?

El RFC 8291 exige este secreto como material de clave adicional en la derivación HKDF para proteger contra ataques de canal lateral o suplantación.

### ¿Para qué sirve proporcionar uaPrivateKey?

Es opcional y permite a la herramienta realizar un descifrado de ida y vuelta para comprobar que el receptor puede recuperar el mensaje original.

### ¿Qué función cumple el parámetro Topic en RFC 8030?

Permite agrupar y reemplazar notificaciones pendientes en el servidor push con el mismo identificador, equivalente a collapse_key en FCM.

### ¿La clave privada VAPID debe ser la misma que la clave efímera del servidor?

No, el RFC 8292 estipula que la clave de firma VAPID debe gestionarse de forma independiente a la clave efímera generada por envío.

## Herramientas relacionadas

- [Generador de Data URI](https://elysiatools.com/es/tools/data-uri-generator): Convierte archivos en Data URIs (Base64 o porcentaje-codificado) para incrustar imágenes, fuentes y recursos directamente en HTML, CSS o Markdown
- [Comparador de algoritmos hash](https://elysiatools.com/es/tools/hash-algorithm-comparator): Aplica MD5, SHA-1, SHA-256, SHA-512, BLAKE2b y BLAKE3 a la misma entrada y compáralos lado a lado: longitud de salida, digest hex/Base64, estado de seguridad (roto/moderno) y benchmark de velocidad relativa. Útil para enseñanza, elegir algoritmo o verificar checksums.
- [Cifrado / Descifrado RSA](https://elysiatools.com/es/tools/rsa-encrypt-decrypt): Cifra texto con una clave pública RSA o descifra el texto cifrado con la clave privada correspondiente, usando padding OAEP (SHA-1 o SHA-256). Maneja mensajes largos por bloques. Las claves y datos se quedan en local. No se ofrece PKCS#1 v1.5 (Node lo deshabilita para descifrar por ataques Bleichenbacher).
- [Validador de propagación OpenTelemetry W3C traceparent / tracestate / baggage y cabeceras OTLP](https://elysiatools.com/es/tools/opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator): Valida traceparent según la ABNF de W3C Trace Context (versión / trace-id de 16 bytes / parent-id de 8 bytes / trace-flags de 1 byte; rechaza ceros y versión ff, avisa en mayúsculas), tracestate (≤32 miembros, claves simples y tenant@sistema, avisos por duplicados) y baggage (valores percent-codificados con propiedades opacas); comprueba el Content-Type de exportación OTLP y el contexto binario de 25 bytes de grpc-trace-context-bin; correlaciona dos traceparent en un round-trip simulado (estabilidad del trace-id y colisión de span-id hijo aleatorio) y emite cabeceras normalizadas listas para reenviar.
- [Convertidor Base64](https://elysiatools.com/es/tools/base64-converter): Codifica y decodifica datos hacia/desde formato Base64 con opciones URL-safe
- [Decodificador LTSSM y Lane Margining de PCIe](https://elysiatools.com/es/tools/pcie-link-training-linkstate-and-lane-margining-eye-decode): Decodifica un registro de entrenamiento de enlace PCIe (secuencia LTSSM + conjuntos ordenados TS1/TS2): línea de tiempo Gen1-Gen6, velocidad/anchura negociadas, bits de identificador de tasa, inversión de polaridad y de lanes, fases de ecualización y diagnóstico de reinicios; también califica informes de lane margining (CSV de pcilmr) y dibuja un mapa de calor del ojo.
- [Generador de PKCE Code Verifier y Challenge](https://elysiatools.com/es/tools/pkce-code-verifier-generator): Genera, valida y verifica pares code_verifier / code_challenge PKCE (RFC 7636) de OAuth2 / OIDC. Tres modos: (1) generar un par nuevo a partir de bytes aleatorios criptográficos (256/384/512/768 bits), (2) auditar un verifier existente frente al RFC — longitud (43–128), charset \[A-Za-z0-9-._~\] y ≥256 bits de entropía, y (3) verificar un par recomputando BASE64URL(SHA256(verifier)). Opcionalmente construye la URL completa de autorización y el cuerpo del intercambio de token. Complementa al nonce-genérico (que solo emite el par) con auditoría de cumplimiento RFC y verificación de pares.
- [Generador de marcadores de capítulos de podcast (ID3 / Podcasting 2.0)](https://elysiatools.com/es/tools/podcast-chapter-marker-builder): Pega una lista de capítulos con marcas de tiempo y genera de una vez todos los formatos de entrega: JSON de capítulos Podcasting 2.0 (v1.2.0) y etiqueta RSS podcast:chapters, opción de grabar marcos ID3v2.4 CHAP+CTOC directamente en un MP3 subido (milisegundos como uint32 big-endian normal, offsets 0xFFFFFFFF, subtrama TIT2 por capítulo, se preservan los marcos existentes), pares de comentarios Vorbis CHAPTER001 (OGG/Opus), texto mp4chaps, bloque de marcas de tiempo para la descripción de YouTube y sidecar SRT, más la matriz real de soporte por reproductor (Apple acepta el JSON por RSS desde 2025; Pocket Casts/Overcast solo leen ID3 incrustado; Spotify ignora ambos).

## Ejemplos

- [Ejemplos de Procesamiento de Imágenes Web Python](https://elysiatools.com/es/samples/web-image-processing-python): Ejemplos de procesamiento de imágenes Web Python usando PIL/Pillow incluyendo lectura, guardado, redimensionamiento y conversión de formato
- [Ejemplos de Procesamiento de Imágenes Web Rust](https://elysiatools.com/es/samples/web-image-processing-rust): Ejemplos de procesamiento de imágenes Web Rust incluyendo lectura/escritura, escalado y conversión de formato
- [Ejemplos de Procesamiento de Imágenes Web TypeScript](https://elysiatools.com/es/samples/web-image-processing-typescript): Ejemplos de procesamiento de imágenes Web TypeScript incluyendo lectura/guardado de imágenes, escalado y conversión de formato
- [Ejemplos de Operaciones de Archivo Web Go](https://elysiatools.com/es/samples/web-file-operations-go): Ejemplos de operaciones de archivo Web Go incluyendo lectura/escritura de archivos de texto, copiar/mover, recorrido de directorio y validación de archivos