# Codificador Web Push: pedido RFC 8030 + VAPID + cifragem RFC 8291

Codifica um envio Web Push completo: cifragem aes128gcm do RFC 8291, JWT ES256 do VAPID (RFC 8292), cabeçalhos RFC 8030, correspondência APNs/FCM e verificação por descriptografia de ida e volta.

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

- **Categoria:** Format Conversion

- **Palavras-chave:** cifragem web push, rfc 8291 aes128gcm, jwt vapid, rfc 8292, cabeçalhos rfc 8030, p256dh auth secret, ecdh p-256 hkdf, cabeçalhos apns, collapse key fcm, verificação de ida e volta

## Visão geral

A cifragem segue o RFC 8291 à risca: ECDH sobre P-256 entre uma chave efêmera do servidor de aplicação e a chave p256dh da assinatura, combinação de chaves HKDF-SHA256 com o auth secret (contexto «WebPush: info»), sal aleatório de 16 bytes, derivação de CEK/nonce pelos contextos «Content-Encoding» e AES-128-GCM com o cabeçalho binário do RFC 8188 (sal + tamanho de registro + id de chave). A implementação reproduz byte a byte os exemplos do RFC 8291 §5 e do draft-ietf-webpush-encryption-04.

## Entradas

- **Carga útil (texto claro)** (textarea): Message body sent to the user agent, e.g. {"title":"Order shipped"}
- **Codificação de conteúdo** (select)
- **p256dh da assinatura (base64url)** (text): uncompressed P-256 point from subscription.keys.p256dh
- **Segredo auth da assinatura (base64url)** (text): 16-byte secret from subscription.keys.auth
- **Chave privada do receptor (base64url, opcional — ativa a verificação)** (text): user-agent P-256 scalar, only if you own the subscription keys
- **Chave privada efêmera do 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 preenchimento** (number)
- **TTL em segundos (RFC 8030)** (number)
- **Urgência (RFC 8030)** (select)
- **Tópico (RFC 8030, opcional)** (text): coalescing key, e.g. new-message
- **Host do serviço de push** (text)
- **Caminho do endpoint** (text)
- **Construir cabeçalho VAPID Authorization (RFC 8292)** (checkbox)
- **VAPID sub (contato)** (text)
- **VAPID aud (origem do serviço)** (text)
- **VAPID exp (segundos unix)** (number)
- **Chave privada de assinatura VAPID (base64url)** (text): P-256 scalar, MUST differ from the encryption key

## Quando usar

- Ao depurar falhas de cifragem em bibliotecas de Web Push ou validar o cálculo de CEK, salt e nonce.
- Ao estruturar cabeçalhos de requisição HTTP/2 (TTL, Urgency, Topic, Authorization VAPID) para envio direto a endpoints de push.
- Ao testar a compatibilidade entre o padrão moderno RFC 8291 (aes128gcm) e implementações legadas draft-04 (aesgcm).

## Como funciona

- O utilitário executa a troca de chaves ECDH sobre a curva P-256 combinando a chave efêmera com a chave pública p256dh e o segredo de autenticação.
- Deriva o CEK (Content Encryption Key) e o nonce utilizando HKDF-SHA256 e cifra o texto em claro com AES-128-GCM juntamente com o cabeçalho binário RFC 8188.
- Assina o cabeçalho de autorização VAPID gerando um JWT ES256 a partir da chave privada informada, audiência e tempo de expiração.
- Exibe a requisição HTTP completa, valores criptográficos intermediários e valida a integridade através do teste de descriptografia de ida e volta se a chave privada do receptor for fornecida.

## Casos de uso

- Validação de vetores de teste oficiais das RFCs 8291 e 8292 durante o desenvolvimento de backends de notificações.
- Diagnóstico de erros 400 Bad Request ou 401 Unauthorized retornados por serviços de push como Google FCM, Mozilla autopush ou Apple Web Push.
- Mapeamento de parâmetros RFC 8030 como Urgency e Topic para cabeçalhos equivalentes dos ecossistemas APNs e FCM.

## Perguntas frequentes

### Qual é a diferença entre aes128gcm e o padrão legado aesgcm?

O aes128gcm (RFC 8291) insere metadados binários (salt, tamanho do registro e chave) no próprio corpo da mensagem, enquanto o aesgcm (draft-04) envia esses dados nos cabeçalhos Encryption e Crypto-Key.

### Por que a chave efêmera do servidor deve ser diferente a cada envio?

O uso de uma chave efêmera única e de um novo salt por mensagem garante confidencialidade persistente e impede a reutilização de pares chave/nonce no AES-GCM.

### O que o parâmetro Topic do RFC 8030 faz?

Ele funciona como chave de agregação (collapse key), permitindo que mensagens pendentes com o mesmo tópico sejam substituídas pela notificação mais recente no serviço de push.

### Para que serve preencher a chave privada do receptor (uaPrivateKey)?

É um campo opcional usado exclusivamente para realizar o teste de descriptografia de ciclo completo (round-trip) e confirmar que o receptor conseguirá decifrar o payload.

### Como o cabeçalho VAPID autentica o remetente?

O servidor assina um token JWT com sua chave privada P-256 contendo informações de contato (sub) e a origem do serviço de push (aud), atendendo à RFC 8292.

## Ferramentas relacionadas

- [Gerador de Data URI](https://elysiatools.com/pt/tools/data-uri-generator): Converte arquivos em Data URIs (Base64 ou porcentagem-codificada) para incorporar imagens, fontes e recursos diretamente em HTML, CSS ou Markdown
- [Comparador de algoritmos de hash](https://elysiatools.com/pt/tools/hash-algorithm-comparator): Aplica MD5, SHA-1, SHA-256, SHA-512, BLAKE2b e BLAKE3 à mesma entrada e compara: tamanho, digest hex/Base64, status de segurança (quebrado/moderno) e benchmark de velocidade relativa. Útil para ensino, escolha de algoritmo ou checagem de checksums.
- [Criptografar / Descriptografar RSA](https://elysiatools.com/pt/tools/rsa-encrypt-decrypt): Criptografa texto com uma chave pública RSA ou descriptografa o texto cifrado com a chave privada correspondente, usando padding OAEP (SHA-1 ou SHA-256). Trata mensagens longas em blocos. Chaves e dados ficam locais. PKCS#1 v1.5 não é oferecido (Node o desabilita para descriptografia devido a ataques Bleichenbacher).
- [Validador de propagação OpenTelemetry W3C traceparent / tracestate / baggage e cabeçalhos OTLP](https://elysiatools.com/pt/tools/opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator): Valida traceparent pela ABNF do W3C Trace Context (versão / trace-id de 16 bytes / parent-id de 8 bytes / trace-flags de 1 byte; zeros e versão ff rejeitados, maiúsculas avisadas), tracestate (≤32 membros, chaves simples e tenant@sistema, duplicatas avisadas) e baggage (valores percent-encoded com propriedades opacas); verifica o Content-Type de exportação OTLP e o contexto binário de 25 bytes do grpc-trace-context-bin; correlaciona dois traceparent num round-trip simulado (estabilidade do trace-id e colisão de um span-id filho aleatório) e emite cabeçalhos normalizados.
- [Conversor Base64](https://elysiatools.com/pt/tools/base64-converter): Codifica e decodifica dados para/de formato Base64 com opções URL-safe
- [Decodificador LTSSM e Lane Margining PCIe](https://elysiatools.com/pt/tools/pcie-link-training-linkstate-and-lane-margining-eye-decode): Decodifica um log de treinamento de link PCIe (sequência LTSSM + conjuntos TS1/TS2): linha do tempo Gen1-Gen6, velocidade/largura negociadas, bits do identificador de taxa, inversão de polaridade/lanes, fases de equalização e diagnóstico de reinícios; avalia relatórios de lane margining (CSV pcilmr) e desenha o mapa de calor do olho.
- [Gerador de PKCE Code Verifier e Challenge](https://elysiatools.com/pt/tools/pkce-code-verifier-generator): Gera, valida e verifica pares code_verifier / code_challenge PKCE (RFC 7636) de OAuth2 / OIDC. Três modos: (1) gerar um par novo a partir de bytes aleatórios criptográficos (256/384/512/768 bits), (2) auditar um verifier existente frente ao RFC — comprimento (43–128), charset \[A-Za-z0-9-._~\] e ≥256 bits de entropia, e (3) verificar um par recalculando BASE64URL(SHA256(verifier)). Opcionalmente constrói a URL completa de autorização e o corpo de troca de token. Complementa o nonce-generator genérico (que só emite o par) com auditoria de conformidade RFC e verificação de pares.
- [Gerador de marcadores de capítulos de podcast (ID3 / Podcasting 2.0)](https://elysiatools.com/pt/tools/podcast-chapter-marker-builder): Cole uma lista de capítulos com timecodes e gere de uma vez todos os formatos de entrega: JSON de capítulos Podcasting 2.0 (v1.2.0) e tag RSS podcast:chapters, gravação opcional dos frames ID3v2.4 CHAP+CTOC direto num MP3 enviado (milissegundos como uint32 big-endian simples, offsets 0xFFFFFFFF, subframe TIT2 por capítulo, frames existentes preservados), pares de comentários Vorbis CHAPTER001 (OGG/Opus), texto mp4chaps, bloco de timestamps para a descrição do YouTube e sidecar SRT, mais a matriz real de suporte dos players (Apple aceita o JSON via RSS desde 2025; Pocket Casts/Overcast leem só ID3 embutido; Spotify ignora ambos).

## Exemplos

- [Exemplos de Processamento de Imagem Web Python](https://elysiatools.com/pt/samples/web-image-processing-python): Exemplos de processamento de imagem Web Python usando PIL/Pillow incluindo leitura, salvamento, redimensionamento e conversão de formato
- [Exemplos de Processamento de Imagem Web Rust](https://elysiatools.com/pt/samples/web-image-processing-rust): Exemplos de processamento de imagem Web Rust incluindo leitura/gravação, redimensionamento e conversão de formato
- [Exemplos de Processamento de Imagens Web TypeScript](https://elysiatools.com/pt/samples/web-image-processing-typescript): Exemplos de processamento de imagens Web TypeScript incluindo leitura/salvamento, redimensionamento e conversão de formato
- [Exemplos de Operações de Arquivo Web Go](https://elysiatools.com/pt/samples/web-file-operations-go): Exemplos de operações de arquivo Web Go incluindo leitura/escrita de arquivo de texto, copiar/mover, travessia de diretório e validação de arquivo