# Кодировщик Web Push: запрос RFC 8030 + VAPID + шифрование RFC 8291

Кодирует полную отправку Web Push: шифрование aes128gcm по RFC 8291, VAPID ES256 JWT по RFC 8292, заголовки RFC 8030, соответствие APNs/FCM и проверку расшифровкой в оба направления.

> Каноническая страница: https://elysiatools.com/ru/tools/web-push-rfc8030-vapid-rfc8291-payload-encrypted-content-encoder

- **Категория:** Format Conversion

- **Ключевые слова:** шифрование web push, rfc 8291 aes128gcm, vapid jwt, rfc 8292, заголовки rfc 8030, p256dh auth secret, ecdh p-256 hkdf, заголовки apns, collapse key fcm, проверка в оба направления

## Обзор

Шифрование строго по RFC 8291: ECDH на P-256 между эфемерным ключом сервера приложения и ключом подписки p256dh, комбинирование ключей HKDF-SHA256 с auth secret (контекст «WebPush: info»), случайная 16-байтовая соль, вывод CEK/nonce через контексты «Content-Encoding» и AES-128-GCM с бинарным заголовком RFC 8188 (соль + размер записи + id ключа). Реализация побайтово воспроизводит примеры RFC 8291 §5 и draft-ietf-webpush-encryption-04.

## Входные данные

- **Полезная нагрузка (открытый текст)** (textarea): Message body sent to the user agent, e.g. {"title":"Order shipped"}
- **Кодирование содержимого** (select)
- **p256dh подписки (base64url)** (text): uncompressed P-256 point from subscription.keys.p256dh
- **Секрет auth подписки (base64url)** (text): 16-byte secret from subscription.keys.auth
- **Приватный ключ приёмника (base64url, опционально — включает проверку)** (text): user-agent P-256 scalar, only if you own the subscription keys
- **Эфемерный приватный ключ сервера (base64url)** (text): 32-byte P-256 scalar; generate fresh per send in production
- **Соль (base64url, 16 байтов)** (text): random 16 bytes per message in production
- **Байты заполнения** (number)
- **TTL в секундах (RFC 8030)** (number)
- **Срочность (RFC 8030)** (select)
- **Тема (RFC 8030, опционально)** (text): coalescing key, e.g. new-message
- **Хост push-сервиса** (text)
- **Путь эндпоинта** (text)
- **Собрать заголовок VAPID Authorization (RFC 8292)** (checkbox)
- **VAPID sub (контакт)** (text)
- **VAPID aud (origin push-сервиса)** (text)
- **VAPID exp (unix-секунды)** (number)
- **Приватный ключ подписи VAPID (base64url)** (text): P-256 scalar, MUST differ from the encryption key

## Когда использовать

- При разработке и отладке серверных библиотек для отправки браузерных Web Push уведомлений.
- Для верификации промежуточных криптографических вычислений ECDH P-256, HKDF-SHA256, CEK и nonce по эталонным векторам.
- При необходимости проверить валидность токена VAPID JWT и соответствие заголовков спецификациям RFC 8030, FCM и APNs.

## Как это работает

- На основе открытого текста, параметров подписки (p256dh, auth) и ключа сервера вычисляется общий секрет ECDH на кривой P-256.
- С помощью HKDF-SHA256 и случайной соли формируются рабочий ключ шифрования (CEK) и одноразовый вектор (nonce) в контексте aes128gcm (RFC 8291) или aesgcm (draft-04).
- Полезная нагрузка шифруется методом AES-128-GCM, параллельно генерируется токен авторизации VAPID (RFC 8292) и формируются заголовки RFC 8030 (TTL, Urgency, Topic).
- Инструмент выводит полный HTTP/2-запрос, пошаговую трассировку промежуточных байтов, таблицу соответствия для FCM/APNs и статус тестовой расшифровки.

## Сценарии использования

- Формирование эталонных тестовых данных и сверка байтов при разработке бэкенд-сервисов push-рассылок.
- Диагностика ошибок 400 Bad Request и 401 Unauthorized от push-серверов Apple, Google и Mozilla.
- Генерация готовых curl-запросов и дампов HTTP/2 для ручного тестирования доставки push-уведомлений на клиентские устройства.

## Частые вопросы

### В чем главное отличие кодирования aes128gcm от aesgcm?

Стандартный aes128gcm (RFC 8291 / RFC 8188) помещает соль и длину записи в бинарный заголовок тела запроса, тогда как устаревший aesgcm (draft-04) передает их через заголовки Encryption и Crypto-Key.

### Зачем указывать приватный ключ приёмника (uaPrivateKey)?

Это поле необязательно и служит для проверки: с его помощью инструмент расшифровывает полученный шифртекст обратно и подтверждает корректность всей цепочки шифрования.

### Как заголовки RFC 8030 соотносятся с FCM и APNs?

Заголовок Urgency сопоставляется с приоритетами доставки APNs и FCM, а заголовок Topic транслируется в идентификаторы схлопывания уведомлений apns-collapse-id и FCM collapse_key.

### Какой алгоритм используется для подписи VAPID JWT?

Используется алгоритм ES256 (ECDSA на кривой P-256 с SHA-256), при этом закрытый ключ VAPID не должен совпадать с эфемерным ключом шифрования полезной нагрузки.

### Отправляются ли закрытые ключи на сторонние серверы?

Нет, все криптографические операции, генерация токенов и сборка запроса выполняются локально в клиенте.

## Связанные инструменты

- [Генератор Data URI](https://elysiatools.com/ru/tools/data-uri-generator): Преобразует файлы в Data URI (Base64 или процентное кодирование) для встраивания изображений, шрифтов и ресурсов прямо в HTML, CSS или Markdown
- [Сравнение хеш-алгоритмов](https://elysiatools.com/ru/tools/hash-algorithm-comparator): Хеширует один и тот же вход с помощью MD5, SHA-1, SHA-256, SHA-512, BLAKE2b и BLAKE3 и сравнивает их: длину, hex/Base64-дайджест, статус безопасности (взломан/современный) и относительный бенчмарк скорости. Полезно для обучения, выбора алгоритма и проверки контрольных сумм.
- [Шифрование / Расшифрование RSA](https://elysiatools.com/ru/tools/rsa-encrypt-decrypt): Шифрует текст открытым ключом RSA или расшифровывает шифртекст соответствующим закрытым ключом, с OAEP-паддингом (SHA-1 или SHA-256). Длинные сообщения бьются на блоки. Ключи и данные обрабатываются локально. PKCS#1 v1.5 не предлагается (Node отключает его для расшифровки из-за атак Bleichenbacher).
- [Валидатор распространения OpenTelemetry W3C traceparent / tracestate / baggage и заголовков OTLP](https://elysiatools.com/ru/tools/opentelemetry-w3c-traceparent-tracestate-baggage-and-otlp-protobuf-headers-propagation-validator): Проверяет traceparent по ABNF W3C Trace Context (версия / 16-байтовый trace-id / 8-байтовый parent-id / 1-байтовый trace-flags; нули и версия ff отклоняются, верхний регистр предупреждает), tracestate (≤32 членов, простые и tenant@system ключи, предупреждение о дублях) и baggage (процентно-кодированные значения с непрозрачными свойствами); проверяет Content-Type экспорта OTLP и 25-байтовый двоичный контекст grpc-trace-context-bin; коррелирует два traceparent в симулированном round-trip (стабильность trace-id и коллизия случайного дочернего span-id) и выдаёт нормализованные заголовки.
- [Base64 Конвертер](https://elysiatools.com/ru/tools/base64-converter): Кодирует и декодирует данные в/из формата Base64 с опциями URL-safe
- [Декодер LTSSM и Lane Margining PCIe](https://elysiatools.com/ru/tools/pcie-link-training-linkstate-and-lane-margining-eye-decode): Разбор журнала обучения канала PCIe (последовательность LTSSM + упорядоченные наборы TS1/TS2): полная шкала Gen1-Gen6, согласованные скорость/ширина, биты идентификатора скорости, инверсия полярности и линий, фазы эквализации и диагностика перезапусков; оценка отчётов lane margining (CSV pcilmr) и тепловая карта глаза.
- [Генератор PKCE Code Verifier и Challenge](https://elysiatools.com/ru/tools/pkce-code-verifier-generator): Создание, проверка и верификация пар code_verifier / code_challenge PKCE (RFC 7636) для OAuth2 / OIDC. Три режима: (1) создать новую пару из криптостойких случайных байт (256/384/512/768 бит), (2) аудит имеющегося verifier по RFC — длина (43–128), набор \[A-Za-z0-9-._~\] и ≥256 бит энтропии, (3) проверить пару, пересчитав BASE64URL(SHA256(verifier)). При желании строит полный URL запроса авторизации и тело обмена токена. Дополняет универсальный nonce-generator (только выдаёт пару) аудитом соответствия RFC и проверкой пар.
- [Конструктор глав подкаста (ID3 / Podcasting 2.0)](https://elysiatools.com/ru/tools/podcast-chapter-marker-builder): Вставьте список глав с таймкодами и получите сразу все форматы: JSON глав Podcasting 2.0 (v1.2.0) и RSS-тег podcast:chapters, опциональное вписывание фреймов ID3v2.4 CHAP+CTOC прямо в загруженный MP3 (миллисекунды — обычный big-endian uint32, смещения 0xFFFFFFFF, подфрейм TIT2 на главу, существующие фреймы сохраняются), пары Vorbis-комментариев CHAPTER001 (OGG/Opus), текст mp4chaps, блок таймкодов для описания YouTube и SRT-сайдкар, плюс реальная матрица поддержки плеерами (Apple читает RSS-JSON с 2025; Pocket Casts/Overcast — только встроенный ID3; Spotify игнорирует и то, и другое).

## Примеры

- [Примеры Обработки Изображений Web Python](https://elysiatools.com/ru/samples/web-image-processing-python): Примеры обработки изображений Web Python используя PIL/Pillow включая чтение, сохранение, изменение размера и преобразование формата
- [Примеры Обработки Изображений Web Rust](https://elysiatools.com/ru/samples/web-image-processing-rust): Примеры обработки изображений Web Rust включая чтение/запись, масштабирование и преобразование форматов
- [Примеры Обработки Изображений Web TypeScript](https://elysiatools.com/ru/samples/web-image-processing-typescript): Примеры обработки изображений Web TypeScript включая чтение/сохранение, масштабирование и конвертацию форматов
- [Примеры Файловых Операций Web Go](https://elysiatools.com/ru/samples/web-file-operations-go): Примеры файловых операций Web Go включая чтение/запись текстовых файлов, копирование/перемещение, обход директорий и валидацию файлов