Справочник

Глоссарий

302 термина по цифровым подписям, сертификатам, токенам, протоколам и постквантовой криптографии: каждый определён в нескольких предложениях и связан со стандартами, которые его описывают.

Показано: 302 из 302

По алфавиту

А

Адрес Bitcoin: Человекочитаемая кодировка скрипта выхода Bitcoin: устаревшие P2PKH (1…) и P2SH (3…) в Base58Check, SegWit v0 (bc1q…) в bech32 и Taproot (bc1p…) в bech32m.
Адрес Ethereum: 20-байтный идентификатор аккаунта: для внешних аккаунтов это последние 20 байт хеша Keccak-256 от 64-байтного несжатого открытого ключа secp256k1 без префикса 0x04, записанные как 0x и 40 шестнадцатеричных цифр.
Алгоритм Гровера: Квантовый алгоритм поиска, предложенный Ловом Гровером в 1996 году: он находит помеченный элемент среди N примерно за √N шагов и поэтому не более чем вдвое сокращает эффективную стойкость в битах для симметричных ключей и прообразов хешей.
Алгоритм Шора: Квантовый алгоритм, предложенный Питером Шором в 1994 году: он за полиномиальное время раскладывает целые числа на множители и вычисляет дискретные логарифмы, поэтому на большом отказоустойчивом квантовом компьютере взломал бы RSA, протокол Диффи — Хеллмана, ECDSA, EdDSA и ECDH.
Альтернативное имя субъекта (SAN): Расширение X.509 (OID 2.5.29.17), в котором перечислены DNS-имена, IP-адреса, адреса электронной почты или URI, для которых действителен сертификат; это единственное поле, по которому браузеры сверяют имя хоста сервера.
Аппаратный кошелёк: Отдельное устройство, которое хранит ключи кошелька в защищённом элементе (secure element) или изолированном микроконтроллере, показывает детали транзакции на собственном экране и подписывает только после физического подтверждения.
Атака по побочным каналам: Атака, которая извлекает секреты не из входных и выходных данных вычисления, а из его физического и временного поведения — времени выполнения, обращений к кешу, энергопотребления, электромагнитного излучения или реакции на внесённые сбои.
Атака с недопустимой кривой (invalid curve): Атака, при которой другая сторона присылает точку, не лежащую на согласованной кривой, и реализация, пропускающая проверку точки, выполняет вычисления на более слабой кривой и по частям раскрывает свой закрытый ключ.
Атака удлинения сообщения: Атака на хеш-функции со структурой Меркла — Дамгора, например MD5, SHA-1, SHA-256 и SHA-512, которая вычисляет H(секрет ‖ m ‖ дополнение ‖ m′) по H(секрет ‖ m) и длине строки секрет ‖ m, не зная секрета.
Аттестация (WebAuthn): Заявление, которое аутентификатор при регистрации подписывает ключом аттестации; оно сообщает доверяющей стороне, аутентификатор какого типа создал учётные данные, чтобы она могла применять политики в отношении устройств.
Аутентификатор (FIDO/WebAuthn): Компонент, который хранит учётные данные WebAuthn и создаёт подписи: платформенный аутентификатор, встроенный в устройство, переносной ключ безопасности или менеджер учётных данных, синхронизирующий ключи доступа.

В

Возобновление сессии TLS: Повторное установление сессии TLS по секретам предыдущего соединения, при котором не нужна аутентификация по сертификату и экономятся вычисления, а в TLS 1.3 можно сразу передать данные 0-RTT.
Восстановление открытого ключа ECDSA: Вычисление открытого ключа подписанта по подписи ECDSA и хешу сообщения (SEC 1, § 4.1.6): так подпись сообщений в Ethereum и Bitcoin обходится без передачи самого ключа.
Выравнивание идентификаторов DMARC: Требование DMARC: домен, прошедший аутентификацию SPF (отправитель конверта) или DKIM (домен d=), должен совпадать с доменом в заголовке From — точно (режим strict) или в пределах одного организационного домена (режим relaxed).

Г

Гибридный обмен ключами: Обмен ключами, который сочетает классический алгоритм, например X25519, с постквантовым KEM, например ML-KEM, так что сессия остаётся секретной, пока стойким остаётся хотя бы один из компонентов.

Д

Дайджест (хеш сообщения): Результат фиксированной длины, который криптографическая хеш-функция вычисляет по данным; он служит компактным, стойким к коллизиям идентификатором этих данных и теми входными данными, которые на самом деле подписывает большинство схем подписи.
Данные аутентификатора: Двоичная структура, которая есть в каждом ответе WebAuthn: 32-байтный хеш SHA-256 от RP ID, байт флагов, 4-байтный счётчик подписей, а также, если они есть, сведения об аттестованных учётных данных и выходные данные расширений в CBOR.
Дерево Меркла: Двоичное дерево хешей, в котором каждый внутренний узел содержит хеш двух своих потомков, поэтому один корневой хеш фиксирует все листья, а включение элемента или то, что дерево только дополнялось, можно подтвердить доказательством логарифмического размера.
Доверенная публикация (trusted publishing): Публикация пакетов в реестр из CI с краткосрочными учётными данными на основе OIDC вместо долгоживущего API-токена; её ввёл PyPI в апреле 2023 года, она есть также в npm (общедоступна с июля 2025 года), RubyGems, crates.io и других реестрах.
Доверенные метки времени (RFC 3161): Получение от службы меток времени (TSA) подписанного токена, который связывает хеш данных с доверенным временем, чтобы можно было показать, что подпись создана до истечения срока действия или отзыва сертификата.

З

Заголовок DKIM-Signature: Поле заголовка (RFC 6376, § 3.5), где подпись DKIM записана парами «тег=значение», в том числе тегами v, a, c, d, s, h, bh, b и необязательными i, l, t и x.
Задача о скрытом числе (HNP): Задача на решётках: восстановить секрет по множеству зашумлённых линейных соотношений, раскрывающих несколько его битов; она превращает небольшие смещения или утечки в nonce ECDSA и DSA в полное восстановление закрытого ключа.
Закрепление сертификатов или открытых ключей: Ограничение сертификатов или открытых ключей, которые клиент принимает для хоста, фиксированным набором в дополнение к обычной проверке цепочки: клиент сверяет хеш ключа CA, промежуточного CA или собственного ключа сервера.
Закрытый ключ: Секретная половина асимметричной пары ключей, которая служит для подписи, расшифрования или согласования ключей; любой, у кого есть этот ключ, может действовать от имени владельца, поэтому ключ никогда не должен покидать свою границу доверия без защиты.
Защита от понижения версии: Механизмы (например, сигнальное значение TLS 1.3 в ServerHello.random), которые не дают атакующему вынудить две стороны, поддерживающие стойкую версию протокола или алгоритм, перейти на более слабый вариант.

К

Канонизация: Приведение данных к одному согласованному байтовому представлению перед хешированием или подписью, чтобы семантически равнозначные входные данные (с разными пробелами, порядком ключей, префиксами пространств имён или переносом строк в заголовках) давали одни и те же данные для подписи.
Канонизация DKIM: Два алгоритма, simple и relaxed (RFC 6376, § 3.4), которые нормализуют заголовки и тело письма перед хешированием DKIM; для заголовков и для тела их выбирают независимо друг от друга тегом c=.
Ключ доступа (passkey): Обнаруживаемые учётные данные FIDO2/WebAuthn (пара ключей, привязанная к одному сайту или приложению и разблокируемая биометрией, PIN-кодом или паролем устройства), которые заменяют пароль подписью, устойчивой к фишингу.
Ключ хоста SSH: Долговременная пара ключей, которой SSH-сервер подписывает каждый обмен ключами, подтверждая свою подлинность клиентам, которые записали открытый ключ в known_hosts или доверяют CA, подписавшему этот ключ.
Ключ OpenPGP v6: Формат ключей, введённый в RFC 9580, с 32-байтными отпечатками SHA-256, встроенными алгоритмами Ed25519/X25519/Ed448/X448 и подписями v6 с солью; он заменяет ключи v4 из RFC 4880, основанные на SHA-1.
Корневой CA (корневой сертификат): Самоподписанный сертификат CA, которому доверяют напрямую, потому что он есть в хранилище корневых сертификатов; им должен завершаться любой путь сертификации.
Кофактор: Отношение h = #E / n числа точек эллиптической кривой к простому порядку n подгруппы, используемой в криптографии: 1 для P-кривых NIST и secp256k1, 8 для Curve25519, 4 для Curve448.
Краткосрочный сертификат: Сертификат с настолько коротким сроком действия (не более 7 дней для публичных TLS-сертификатов, выпущенных с 15 марта 2026 года), что он просто истекает и не зависит от проверки отзыва.
Кривые Brainpool: Семейство эллиптических кривых с проверяемо псевдослучайными параметрами (RFC 5639, 2010), которое предпочитают государственные профили Германии и других европейских стран как альтернативу кривым NIST.
Криптографическая гибкость (crypto-agility): Способность системы менять криптографические алгоритмы, размеры ключей и параметры без перепроектирования (за счёт согласования, конфигурации и инвентаризации); переход на постквантовую криптографию превращает её из рекомендуемой практики в необходимость.
Криптографическая хеш-функция: Функция, которая отображает входные данные любой длины в дайджест фиксированной длины так, что найти прообраз, второй прообраз или любую коллизию вычислительно невозможно.
Криптография на решётках: Криптография, основанная на трудных задачах в многомерных решётках, таких как обучение с ошибками (Learning With Errors) и задача поиска короткого целочисленного решения (Short Integer Solution); на ней построены ML-KEM, ML-DSA и FN-DSA.

М

Мультисиг Safe (смарт-аккаунт Safe): Самый распространённый кошелёк Ethereum на смарт-контракте: он выполняет транзакцию, только когда пороговое число владельцев подписало её хеш SafeTx по EIP-712; подписи могут быть подписями ECDSA, подписями контрактов (ERC-1271) или одобрениями в блокчейне.

Н

Набор шифров (cipher suite): Именованное сочетание криптографических алгоритмов, которое использует TLS-соединение; в TLS 1.3 его название задаёт только AEAD и хеш-функцию рукопожатия (например, TLS_AES_128_GCM_SHA256), а в TLS 1.2 название фиксировало ещё обмен ключами и аутентификацию.
Нормализация low-S: Правило, по которому значение s подписи ECDSA должно лежать в нижней половине диапазона (s ≤ n/2); Bitcoin и Ethereum приняли его, чтобы устранить встроенную в ECDSA пластичность подписи.
Нотаризация Apple: Автоматическая проверка программ для Mac с подписью Developer ID на вредоносное ПО, которую выполняет Apple: разработчики загружают сборки через notarytool, Apple возвращает билет (ticket), его проверяет Gatekeeper, а сам билет можно прикрепить к приложению или установщику (stapling).

О

Обёртывание подписи XML (XSW): Класс атак на сообщения с подписью XML, в которых атакующий перемещает подписанный элемент и вставляет поддельный, так что подпись по-прежнему проходит проверку по оригиналу, а приложение обрабатывает подделку.
Обмен ключами (установление ключей): Этап протокола, на котором две стороны получают общий секрет по незащищённому каналу с помощью согласования ключей по протоколу Диффи — Хеллмана или инкапсуляции ключа; из этого секрета выводятся сеансовые ключи.
Обнаруживаемые учётные данные (resident key): Учётные данные WebAuthn, у которых закрытый ключ и идентификатор пользователя (user handle) хранятся в аутентификаторе, поэтому их можно найти, даже если сервер заранее не прислал идентификатор учётных данных; так становится возможным вход с ключом доступа без ввода имени пользователя.
Ограничение SPF в 10 DNS-запросов: Правило RFC 7208, по которому при обработке SPF-записи может сработать не более 10 механизмов и модификаторов, выполняющих DNS-запросы (include, a, mx, ptr, exists, redirect); при превышении результат — permerror.
Ограничения имён (nameConstraints): Расширение X.509 (OID 2.5.29.30), допустимое только в сертификатах CA, которое ограничивает имена в подчинённых сертификатах с помощью разрешённых и исключённых поддеревьев: DNS-имён, диапазонов IP-адресов, почтовых доменов и имён каталога (directory names).
Основные ограничения (basicConstraints): Расширение X.509 (OID 2.5.29.19), флаг cA которого указывает, принадлежит ли сертификат центру сертификации, которому разрешено подписывать другие сертификаты; необязательное поле pathLenConstraint ограничивает число CA, которые могут следовать за ним в цепочке.
Открытый ключ: Половина асимметричной пары ключей, которую можно свободно передавать другим; с её помощью проверяют подписи, шифруют данные для владельца соответствующего закрытого ключа или согласуют с ним ключи.
Отличительное имя (DN): Иерархическое имя X.500 для субъекта и издателя сертификата, составленное из пар «атрибут — значение» с атрибутами вроде CN, O, OU, L, ST и C.
Отпечаток ключа или сертификата: Короткий хеш открытого ключа или сертификата, по которому их идентифицируют и сравнивают визуально или в конфигурации, например SHA256:… для ключей SSH или SHA-256 от байтов DER сертификата.
Отпечаток JWK (JWK thumbprint): Хеш обязательных полей JWK в канонической форме JSON (RFC 7638), обычно SHA-256 в кодировке base64url; служит стабильным идентификатором ключа в значениях kid, привязках DPoP и ACME.
Отсоединённая подпись: Подпись, которая хранится отдельно от подписанных данных (например, файл .sig или .asc в OpenPGP, файл SSHSIG или подпись CMS без инкапсулированного содержимого), так что исходный файл остаётся неизменным.

П

Пара ключей: Закрытый ключ и математически связанный открытый ключ, созданные вместе для одного алгоритма и в идеале одной цели, например подписи или согласования ключей.
Пароль: Секретная строка, которую пользователь запоминает, а сервер проверяет; самый распространённый и самый уязвимый для фишинга аутентификатор, для которого NIST SP 800-63B-4 устанавливает требования к длине, списки запрещённых паролей и правила хранения, а не требования к сложности.
Пластичность подписи: Свойство схемы подписи или её кодирования, которое позволяет любому, не зная закрытого ключа, превратить верную подпись в другую верную подпись того же сообщения тем же ключом.
Подмена алгоритма (путаница ключей): Ошибка проверки, при которой библиотека позволяет заголовку alg токена выбирать алгоритм, и ключ, предназначенный для одного алгоритма, используется с другим; классический пример — открытый ключ RSA в роли секрета HS256.
Подписи на основе хеш-функций: Схемы подписи, стойкость которых зависит только от свойств хеш-функции; они строятся из одноразовых подписей и деревьев Меркла: LMS и XMSS с состоянием (SP 800-208) и SLH-DSA без состояния (FIPS 205).
Подписи с подмешанной случайностью (hedged): Подписание, при котором nonce для каждой подписи выводится из закрытого ключа и сообщения вместе со свежими случайными данными, поэтому схема остаётся безопасной, даже если атакован либо генератор случайных чисел, либо детерминированное вычисление nonce.
Подписи BLS: Подписи на основе спариваний (Боне, Линн и Шахам, 2001): короткие, детерминированные и изначально поддерживающие агрегацию; самый известный пример применения — консенсус proof-of-stake в Ethereum на кривой BLS12-381.
Подписи HTTP-сообщений: Стандарт IETF (RFC 9421, февраль 2024 года) для подписи выбранных компонентов HTTP-запроса или HTTP-ответа; подпись передаётся в полях заголовка Signature-Input и Signature.
Подпись без ключа (keyless signing): Модель подписи Sigstore, в которой подписант проходит аутентификацию с удостоверением OIDC, получает сертификат сроком действия в несколько минут для эфемерного ключа и вместо защиты долгоживущего закрытого ключа полагается на журнал прозрачности.
Подпись кода: Подписание исполняемых файлов, пакетов, скриптов или прошивок сертификатами X.509, ключами платформы, OpenPGP или Sigstore, чтобы операционные системы, магазины приложений и пользователи могли проверить издателя и обнаружить подделку.
Подпись коммитов Git: Подписание коммитов и тегов Git ключами OpenPGP, SSH (начиная с Git 2.34) или X.509, чтобы хостинг-платформы и рецензенты могли проверить, кто их создал; настраивается параметрами gpg.format и user.signingkey.
Подпись PDF: Цифровая подпись, встроенная в PDF-файл (ISO 32000-2), у которой /ByteRange охватывает всё, кроме значения подписи; обычно это отсоединённая подпись CMS или CAdES с цепочкой сертификатов и меткой времени.
Подпись Schnorr: Схема подписи на основе задачи дискретного логарифмирования (Claus Schnorr, 1989), в которой ответ s = r + e·x линеен по ключу; это даёт простые доказательства стойкости, пакетную проверку и встроенные мультиподписи.
Подпись XML (XML-DSig): Стандарт W3C для подписи XML (XML Signature Syntax and Processing 1.1, 2013 год), в котором элемент ds:Signature ссылается на подписываемые данные по URI, канонизирует их и подписывает блок SignedInfo с дайджестами.
Пороговые подписи: Схемы, в которых закрытый ключ разделён между n участниками так, что любые t из них могут совместно создать одну подпись обычного вида, а любая группа меньшего размера ничего не узнаёт о ключе.
Постквантовая категория стойкости NIST: Один из пяти уровней стойкости, которые NIST задаёт для постквантовых наборов параметров, соотнося их со сложностью взлома AES или SHA-2/SHA-3: категория 1 ≈ перебор ключей AES-128, 3 ≈ AES-192, 5 ≈ AES-256, а категории 2 и 4 привязаны к поиску коллизий SHA-256 и SHA3-384.
Постквантовая криптография (PQC): Алгоритмы с открытым ключом, разработанные так, чтобы оставаться стойкими к большим квантовым компьютерам, например ML-KEM, ML-DSA и SLH-DSA (FIPS 203–205, 2024); они приходят на смену RSA, схеме Диффи — Хеллмана и схемам на эллиптических кривых.
Предварительное хеширование (HashML-DSA): Подпись дайджеста сообщения, а не самого сообщения: неявно (ECDSA, RSA) или с помощью явно выделенных вариантов с разделением доменов, например Ed25519ph и HashML-DSA.
Привязка к ключу (привязка к владельцу): Доказательство того, что сторона, предъявляющая удостоверение, контролирует указанный в нём закрытый ключ, так что никто другой не сможет повторно предъявить скопированное удостоверение; в SD-JWT его реализует JWT привязки к ключу, в mdoc — аутентификация устройства.
Проверка владения доменом (DV): Уровень проверки при выпуске сертификата, при котором CA убеждается только в том, что заявитель контролирует доменные имена в сертификате (через проверки DNS, HTTP или TLS-ALPN), и не проверяет никаких сведений об организации.
Проверка организации (OV): Уровень проверки при выпуске сертификата, при котором CA, помимо контроля над доменом, проверяет юридическое существование, название и адрес организации-заявителя и вносит эти сведения в субъект сертификата.
Проверка подписи: Проверка по открытому ключу того, что подпись создана именно для этого сообщения закрытым ключом, парным заданному открытому ключу, по алгоритму, который проверяющая сторона выбрала заранее.
Проверка пользователя (UV): Локальная проверка, с помощью которой аутентификатор убеждается, что присутствует и опознан его законный пользователь (по биометрии, PIN-коду или паролю устройства); о ней сообщает флаг UV в данных аутентификатора WebAuthn.
Проверка пути сертификации: Алгоритм из RFC 5280, § 6, который определяет, действительна ли цепочка от якоря доверия до сертификата конечного субъекта, и проверяет подписи, сроки действия, имена, ограничения, политики и отзыв.
Проверка ACME dns-01: Способ проверки владения доменом в ACME: клиент публикует в _acme-challenge.domain TXT-запись со значением base64url(SHA-256(авторизация ключа)); это единственный способ ACME, которым можно подтвердить wildcard-имена.
Проверка ACME http-01: Способ проверки владения доменом в ACME: клиент отдаёт авторизацию ключа по адресу http://domain/.well-known/acme-challenge/token на порту 80, а CA загружает её из нескольких точек сети.
Проверяемое удостоверение (VC): Набор утверждений о субъекте, любое изменение которого можно обнаружить: его подписывает издатель, хранит в кошельке сам субъект, а проверяющая сторона может проверить его, не обращаясь к издателю; стандартизован в нескольких форматах (W3C VC, SD-JWT VC, mdoc).
Происхождение сборки (build provenance): Подписанные проверяемые сведения о том, как создан артефакт (исходный репозиторий и коммит, платформа сборки, рабочий процесс и входные данные), по которым потребители могут убедиться, что пакет получен из ожидаемого источника и пайплайна.
Промежуточный центр сертификации (CA): Сертификат CA, подписанный корневым или другим промежуточным CA; его ключом выпускают сертификаты конечных субъектов, и корневой ключ может оставаться офлайн.
Прямая секретность (forward secrecy): Свойство, при котором компрометация долговременных ключей, например ключа сертификата сервера, не раскрывает прошлые сессии; оно достигается тем, что ключи каждой сессии выводятся при обмене ключами из эфемерных ключей, которые затем уничтожаются.

Р

Расширение key_share: Расширение TLS 1.3 (51), в котором клиент передаёт эфемерные открытые значения для одной или нескольких групп, а сервер — свой единственный ответ, так что обмен ключами завершается за первый цикл приёма-передачи.
Расширение keyUsage (использование ключа): Расширение X.509 (OID 2.5.29.15), биты которого ограничивают, для чего можно использовать ключ из сертификата: digitalSignature, contentCommitment, keyEncipherment, keyAgreement, keyCertSign, cRLSign и другие.
Расширение signature_algorithms: Расширение TLS (13), в котором клиент или сервер перечисляет принимаемые схемы подписи, например ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256 и ed25519, а расширение signature_algorithms_cert (50) отдельно охватывает подписи сертификатов.
Расширенная проверка (EV): Самый строгий уровень проверки при выпуске TLS-сертификата, определённый в EV Guidelines CA/Browser Forum: CA проверяет юридическое, физическое и операционное существование организации и записывает в сертификат подробности о её регистрации.
Расширенное использование ключа (EKU): Расширение X.509 (OID 2.5.29.37) со списком прикладных назначений, для которых можно использовать ключ сертификата, например id-kp-serverAuth, id-kp-clientAuth, id-kp-codeSigning или id-kp-emailProtection.
Ротация ключей: Замена криптографического ключа новым по графику или после инцидента, при которой проверка продолжает работать во время перехода; обычно для этого старый и новый ключи публикуют одновременно.

С

Самоподписанный сертификат: Сертификат, у которого издатель и субъект совпадают, а подпись создана его собственным закрытым ключом, поэтому ему доверяют только там, где его установили как якорь доверия.
Сведения о продлении ACME (ARI): Расширение ACME из RFC 9773 (июнь 2025 года), через которое CA сообщает клиентам, в каком временном окне следует продлить каждый сертификат: так CA распределяет нагрузку и может запросить досрочное продление перед массовым отзывом.
Серийный номер сертификата: Положительное целое число не длиннее 20 октетов, уникальное в пределах издателя, идентифицирующее сертификат в CRL, запросах OCSP и отчётах об инцидентах.
Сертификат (сертификат открытого ключа): Подписанное издателем заявление о том, что данный открытый ключ принадлежит указанному субъекту; оно действует ограниченное время и для оговорённых целей и чаще всего имеет формат X.509.
Сертификаты на основе деревьев Меркла (MTC): Схема сертификатов, которую стандартизирует IETF: CA записывает каждый выпущенный сертификат в дерево Меркла, а клиенты проверяют короткое доказательство включения вместо больших постквантовых подписей.
Сеть доверия (web of trust): Децентрализованная модель доверия OpenPGP, в которой пользователи сертифицируют ключи друг друга и каждый сам решает, насколько доверять тем, кто сертифицирует, вместо того чтобы полагаться на центры сертификации.
Сжатие сертификатов TLS: Расширение TLS 1.3 из RFC 8879 (compress_certificate, 27), которое позволяет серверу сжимать свою цепочку сертификатов алгоритмом zlib, brotli или zstd; обычно она уменьшается на треть и больше.
Сжатие точек: Кодирование точки эллиптической кривой координатой x и одним битом y вместо обеих координат: размер открытого ключа уменьшается примерно вдвое, но при декодировании приходится извлекать квадратный корень.
Слабый ключ: Ключ, который взломать проще, чем обещает его длина: из-за дефектного генератора, нехватки энтропии, структурного изъяна или повтора на разных устройствах.
Слепое подписание (blind signing): Подтверждение транзакции или сообщения, смысл которых подписывающее устройство не может показать (обычно на экране только хеш или необработанные calldata), из-за чего подписанту приходится доверять компьютеру, который их подготовил и может быть скомпрометирован.
Служба метаданных FIDO (MDS): Подписанный набор заявлений о метаданных сертифицированных аутентификаторов от FIDO Alliance (AAGUID, корневые сертификаты аттестации, возможности и статус сертификации), по которому проверяют аттестацию.
Собери сейчас, расшифруй потом: Стратегия, при которой зашифрованный трафик записывают сегодня, чтобы расшифровать его, когда квантовый компьютер сможет взломать использованный в нём обмен ключами; именно поэтому постквантовый обмен ключами внедряют ещё до появления квантовых компьютеров.
Составные подписи: Подписи, объединяющие постквантовый и классический алгоритмы под одним ключом и одним идентификатором алгоритма (например, ML-DSA-65 с ECDSA P-256), так что подпись проходит проверку, только если её проходят оба компонента.
Срок действия сертификата: Промежуток от notBefore до notAfter сертификата включительно; для публично доверенных TLS-сертификатов с 15 марта 2026 года он не может превышать 200 дней, в 2027 году предел снизится до 100 дней, а в 2029 году — до 47 дней.
Схема разделения секрета Шамира: Схема Ади Шамира (1979): секрет делится на n долей с помощью случайного многочлена, и любые k долей восстанавливают его, а любые k − 1 не раскрывают ничего.
Схемы подписи APK (v1–v4): Форматы подписи приложений Android: v1 — подпись JAR, v2 (Android 7.0) и v3 (Android 9, ротация ключей) — подписи всего файла в блоке подписи APK (APK Signing Block), v3.1 (Android 13) — ротация только для выбранных версий платформы, v4 (Android 11) — для инкрементальной установки.

Т

Токен доступа: Учётные данные, которые клиент OAuth предъявляет серверу ресурсов, чтобы вызвать API от имени пользователя или от своего имени: либо непрозрачная строка, которую проверяют через интроспекцию, либо самодостаточный JWT.
Требования к массовым отправителям: Правила, которые Gmail и Yahoo (с февраля 2024 года) и Microsoft (с мая 2025 года) применяют к отправителям, рассылающим примерно от 5 000 писем в день: SPF, DKIM, запись DMARC с выравниванием доменов и отписка в один клик.

У

Уровень стойкости (биты стойкости): Мера криптографической стойкости: s бит означает, что лучшей известной атаке нужно около 2ˢ операций; по этой мере сравнивают размеры ключей разных алгоритмов, например AES-128, P-256 и RSA-3072.
Устойчивость к фишингу: Свойство метода аутентификации, при котором сайт-двойник не может перехватить и повторно использовать учётные данные; оно достигается, когда аутентификатор криптографически привязывает свой ответ к настоящему источнику (origin), как в WebAuthn и TLS с клиентскими сертификатами.

Ф

Флаги SIGHASH: Байт, который добавляется к подписи Bitcoin и определяет, какие части транзакции она охватывает: ALL (0x01), NONE (0x02), SINGLE (0x03), при необходимости в сочетании с ANYONECANPAY (0x80), а также 0x00, значение по умолчанию в Taproot.
Формат закрытых ключей OpenSSH: Контейнер openssh-key-v1 для закрытых ключей, который ssh-keygen по умолчанию создаёт начиная с OpenSSH 7.8 (2018); он хранится в блоке -----BEGIN OPENSSH PRIVATE KEY----- и, если задана парольная фраза, шифруется ключом, который выводит KDF на основе bcrypt.
Формат ключей PKCS #1: Структуры ASN.1 RSAPublicKey и RSAPrivateKey только для RSA из приложения A к RFC 8017; в PEM они хранятся как -----BEGIN RSA PUBLIC KEY----- и -----BEGIN RSA PRIVATE KEY-----.
Формат подписи raw r‖s (IEEE P1363): Кодирование подписи ECDSA или DSA фиксированной длины: r и s записываются подряд, каждое дополнено слева до длины порядка группы в байтах; его используют JOSE, COSE, WebCrypto и API многих HSM.

Х

Хеширование паролей: Хранение пароля в виде результата намеренно медленной функции с солью, желательно требовательной к памяти (memory-hard), например Argon2id, scrypt, bcrypt или PBKDF2, чтобы украденная база данных была устойчива к офлайн-подбору.
Хранилище корневых сертификатов (trust store): Набор корневых сертификатов CA, которым операционная система, браузер или среда выполнения доверяет как якорям при проверке пути сертификации; его ведёт программа корневых сертификатов по своей политике.

Ц

Цепочка сертификатов: Упорядоченная последовательность сертификатов от сертификата конечного субъекта (конечного сертификата) через один или несколько сертификатов промежуточных CA до доверенного корневого сертификата; каждый сертификат подписан следующим.
Цифровая подпись: Значение, вычисленное по сообщению с помощью закрытого ключа; любой, у кого есть соответствующий открытый ключ, может его проверить и убедиться, что сообщение не изменено и подписано владельцем ключа.

Э

Эллиптическая кривая: Множество точек над конечным полем, удовлетворяющих кубическому уравнению, например y² = x³ + ax + b, вместе с законом сложения точек; эти точки образуют группу, на которой построены ECDSA, EdDSA и ECDH.

A

AAGUID (GUID аттестации аутентификатора): 16-байтный идентификатор в сведениях об аттестованных учётных данных WebAuthn, который обозначает модель аутентификатора, например конкретный ключ безопасности или менеджер паролей, и служит для поиска метаданных и значков.
ACME (среда автоматического управления сертификатами): Протокол из RFC 8555, созданный для Let's Encrypt: клиент доказывает контроль над идентификаторами, проходя проверки (challenges), и получает сертификаты от CA без участия человека.
AEAD (аутентифицированное шифрование): Режим симметричного шифрования, определённый в общем виде в RFC 5116: за одну операцию он обеспечивает конфиденциальность и целостность и дополнительно аутентифицирует незашифрованные присоединённые данные, например заголовки.
AES-GCM: AES в режиме Галуа/счётчика (Galois/Counter Mode, NIST SP 800-38D) — самый распространённый AEAD: шифрование в режиме счётчика плюс аутентификатор GHASH, обычно с 96-битным nonce и 128-битным тегом.
age (шифрование файлов): Небольшой современный инструмент и формат шифрования файлов (age-encryption.org/v1), созданный Филиппо Вальсордой: шифрует для получателей X25519, SSH или гибридных постквантовых получателей либо по парольной фразе, без подписей и без настроек.
alg (заголовок алгоритма JOSE): Параметр заголовка JOSE, который указывает алгоритм подписи или MAC для JWS (например, ES256) либо алгоритм управления ключами для JWE (например, RSA-OAEP-256); он зарегистрирован в RFC 7518 и более поздних RFC.
alg none (незащищённый JWS): Значение алгоритма JWS none (RFC 7518, § 3.6), которое обозначает неподписанный токен с пустой частью подписи; проверяющая сторона никогда не должна принимать такой токен, если явно не ожидает незащищённого содержимого.
ALPN (согласование протокола прикладного уровня): Расширение TLS из RFC 7301: клиент предлагает протоколы прикладного уровня, например h2 и http/1.1, а сервер выбирает один из них прямо в рукопожатии, без дополнительного обмена сообщениями.
ARC (Authenticated Received Chain): Экспериментальный протокол из RFC 8617 (2019): каждый посредник, через который проходит письмо, записывает увиденные результаты аутентификации и запечатывает их, чтобы конечный получатель мог доверять этим результатам, даже если после пересылки или списка рассылки проверка уже не проходит.
ASCII armor: Текстовое кодирование двоичных пакетов OpenPGP в base64 между строками вида -----BEGIN PGP PUBLIC KEY BLOCK----- и -----END PGP PUBLIC KEY BLOCK----- (RFC 9580, § 6.2).
ASN.1 (абстрактная синтаксическая нотация версии один): Язык ITU-T X.680 для описания структур данных независимо от их кодирования; на нём определены сертификаты X.509, CMS, ключи PKCS #8, OCSP, LDAP и телекоммуникационные протоколы.
aud (утверждение об аудитории): Зарегистрированное утверждение JWT (RFC 7519, § 4.1.3), которое называет получателей, для которых предназначен токен, — строка или массив строк; каждый получатель обязан проверить, что там есть его собственный идентификатор.
Authenticode: Формат подписи кода Microsoft для исполняемых файлов, драйверов, установщиков и скриптов Windows: структура PKCS #7 SignedData над хешем файла, которая встраивается в таблицу сертификатов PE и обычно снабжается меткой времени.

B

Base64url: Безопасный для URL и имён файлов алфавит base64 из RFC 4648, § 5: он заменяет + и / на - и _, а в JOSE ещё и отбрасывает дополнение =; каждая часть JWT закодирована в base64url.
Baseline Requirements (базовые требования, BR): Правила CA/Browser Forum для выпуска и обслуживания публично доверенных серверных TLS-сертификатов: методы проверки, профили сертификатов, сроки действия, отзыв и работа центров сертификации.
Bearer-токен: Токен доступа, который даёт доступ любому, кто его предъявит, без доказательства владения каким-либо ключом (RFC 6750); обычно его передают в заголовке Authorization: Bearer, после которого идёт сам токен.
BIMI (индикаторы бренда в письмах): Схема из DNS-записи и сертификата, пока что черновик IETF (Internet-Draft), которая позволяет домену с принудительной политикой DMARC показывать свой логотип рядом с письмами в почтовых сервисах с поддержкой BIMI, например Gmail, Yahoo и Apple Mail.
BIP-32 (HD-кошельки): Стандарт Bitcoin, по которому из одного seed с помощью HMAC-SHA512 и цепных кодов (chain code) выводится дерево ключей: одна резервная копия охватывает все адреса, а из расширенных открытых ключей можно выводить адреса для получения средств без закрытых ключей.
BIP-39 (мнемонические seed-фразы): Стандарт, который кодирует энтропию кошелька в 12–24 слова из списка в 2 048 слов и растягивает фразу с помощью PBKDF2-HMAC-SHA512 (2 048 итераций) в 64-байтный seed, который использует BIP-32.
BIP-137 (формат подписанных сообщений): Формат подписи сообщений в Bitcoin с 65-байтной подписью ECDSA, из которой можно восстановить открытый ключ; байт заголовка этой подписи кодирует и идентификатор восстановления, и тип адреса: 27–30 — P2PKH с несжатым ключом, 31–34 — со сжатым, 35–38 — P2SH-P2WPKH, 39–42 — P2WPKH.
BIP-322 (универсальная подпись сообщений): Стандарт подписи сообщений в Bitcoin, который доказывает контроль над адресом любого типа, включая SegWit, Taproot и мультиподпись, с помощью подписи виртуальной транзакции, которая тратит средства с этого адреса.
BIP-340 (подписи Schnorr для secp256k1): Спецификация Bitcoin: 64-байтные подписи Schnorr на secp256k1 с 32-байтными открытыми ключами x-only и тегированными хешами; её используют Taproot и Nostr.
BLAKE2: Семейство быстрых хеш-функций (BLAKE2b для 64-битных платформ с дайджестом до 64 байт, BLAKE2s для 32-битных с дайджестом до 32 байт), описанное в RFC 7693 и используемое в Argon2, WireGuard, PASETO и libsodium.

C

C2PA (Content Credentials): Стандарт Коалиции за происхождение и подлинность контента (C2PA) для подписанных манифестов происхождения, которые встраиваются в изображения, видео, аудио и документы и фиксируют, кто и какими инструментами создал или отредактировал контент, в том числе с помощью генеративного ИИ.
CA (центр сертификации): Организация или служба, которая выпускает и подписывает сертификаты, убедившись, что заявитель контролирует указанные в них имена или идентификационные данные.
CA/Browser Forum: Добровольное объединение центров сертификации и разработчиков браузеров и операционных систем, которое составляет Baseline Requirements и другие правила для публично доверенных сертификатов TLS, S/MIME и подписи кода.
CAA (авторизация центров сертификации): Тип DNS-записей (RFC 8659), с помощью которых владелец домена перечисляет CA, имеющие право выпускать сертификаты для его имён; каждый публичный CA обязан проверять эти записи перед выпуском.
CBOM (перечень криптографических компонентов): Машиночитаемый перечень криптографических активов системы (алгоритмов, ключей, сертификатов, протоколов и библиотек с их параметрами), по которому планируют и отслеживают миграции, например переход на постквантовую криптографию.
Certificate Transparency (CT): Система публичных журналов на основе дерева Меркла, в которые записи можно только добавлять (RFC 6962); CA отправляют в них каждый публично доверенный TLS-сертификат, чтобы владельцы доменов и системы мониторинга могли обнаружить ошибочно выпущенные сертификаты.
ChaCha20-Poly1305: AEAD, сочетающий потоковый шифр ChaCha20 с аутентификатором Poly1305 (RFC 8439): 256-битные ключи, 96-битные nonce и 128-битные теги; быстро работает программно, без аппаратной поддержки AES.
ClientHello: Первое сообщение TLS-рукопожатия, которое передаётся в открытом виде; в нём клиент перечисляет поддерживаемые версии, наборы шифров, группы, алгоритмы подписи, key share и расширения, например имя сервера.
CMS (синтаксис криптографических сообщений): Преемник PKCS #7 от IETF (RFC 5652) для подписанных данных, данных в цифровом конверте (enveloped) и аутентифицированных данных; его используют S/MIME, Authenticode, подписи PDF, метки времени RFC 3161 и многие форматы прошивок.
CNSA 2.0: Commercial National Security Algorithm Suite 2.0 — набор алгоритмов NSA (сентябрь 2022 года), который требует использовать ML-KEM-1024, ML-DSA-87, LMS или XMSS, AES-256 и SHA-384 или SHA-512 в системах национальной безопасности США к 2030–2035 годам.
COSE (подпись и шифрование объектов CBOR): Аналог JOSE на основе CBOR (RFC 9052 и RFC 9053) для подписей, MAC, шифрования и ключей; его используют WebAuthn, водительские удостоверения mdoc, CWT и C2PA.
cosign: Инструмент командной строки Sigstore для подписи и проверки образов контейнеров, произвольных файлов (blob) и аттестаций: с ключами либо в режиме без ключа, где используются удостоверения OIDC и краткосрочные сертификаты.
CRL (список отзыва сертификатов): Список серийных номеров отозванных сертификатов, подписанный и периодически публикуемый CA (RFC 5280, § 5); проверяющие стороны скачивают его, чтобы проверять отзыв, не запрашивая CA по каждому сертификату.
CRLite: Механизм проверки отзыва в Firefox: статус отзыва каждого сертификата, записанного в журналы Certificate Transparency, сжимается в компактные фильтры, которые браузер скачивает и опрашивает локально.
CSPRNG (криптографически стойкий ГСЧ): Генератор случайных чисел, выход которого нельзя предсказать или отличить от истинной случайности, даже если атакующий видел предыдущие значения; такой генератор необходим для ключей, nonce, солей и токенов.
CSR (запрос на подпись сертификата): Сообщение PKCS #10 (RFC 2986) с именем субъекта, открытым ключом и запрошенными атрибутами, подписанное соответствующим закрытым ключом в доказательство владения им; на его основе CA выпускает сертификат.
CTAP (протокол клиента и аутентификатора): Протокол альянса FIDO для связи клиента (браузера или операционной системы) с внешним аутентификатором через USB HID, NFC, Bluetooth или гибридный транспорт через телефон; команды, например authenticatorMakeCredential, кодируются в CBOR.
Curve25519: Кривая Монтгомери y² = x³ + 486662x² + x над простым полем по модулю 2²⁵⁵ − 19, предложенная Дэниелом Дж. Бернстайном в 2005 году; основа обмена ключами X25519, а в форме Эдвардса — подписей Ed25519.
CWT (веб-токен на основе CBOR): Аналог JWT на основе CBOR (RFC 8392): набор утверждений в виде словаря CBOR (map) с целочисленными ключами, защищённый подписью, MAC или шифрованием COSE.

D

DANE (аутентификация сущностей через DNS): Использование записей TLSA, подписанных DNSSEC (RFC 6698, RFC 7671), чтобы указать, какой сертификат или открытый ключ TLS-сервис должен предъявить, — вместе с публичными CA или вместо них.
DER (отличительные правила кодирования): Каноническое двоичное кодирование ASN.1 из ITU-T X.690, при котором у каждого значения ровно одно байтовое представление; поэтому сертификаты, CSR, CRL, ключи и многие подписи кодируются в DER.
DID (децентрализованный идентификатор): URI вида did:method:identifier (спецификация W3C DID Core 1.0, 2022), который разрешается в документ DID со списком открытых ключей и эндпоинтов сервисов; им управляет его субъект, а не центральный реестр.
DKIM (DomainKeys Identified Mail): Стандарт аутентификации электронной почты из RFC 6376: домен отправителя подписывает выбранные заголовки и тело письма и публикует открытый ключ в DNS, чтобы получатели могли проверить, что письмо пришло с этого домена без изменений.
DKIM replay (повторная рассылка письма): Повторная отправка письма с подлинной подписью DKIM, без изменений, множеству новых получателей, чтобы письмо пользовалось репутацией подписавшего домена; DKIM не может этому помешать, потому что подпись не охватывает SMTP-конверт.
DMARC: Domain-based Message Authentication, Reporting and Conformance (RFC 9989, май 2026 года): политика в DNS, которая требует, чтобы SPF или DKIM проходили проверку с выравниванием по видимому домену From, и сообщает получателям, что делать с письмами, которые её не прошли.
DNSSEC: Расширения безопасности DNS (DNS Security Extensions, RFC 4033–4035): они подписывают наборы DNS-записей, чтобы проверяющие резолверы могли убедиться, что ответы пришли от владельца зоны без изменений, по цепочке доверия от ключа корневой зоны.
DoH (DNS поверх HTTPS): Протокол из RFC 8484, который передаёт DNS-запросы и ответы внутри HTTPS-запросов (тип содержимого application/dns-message), скрывает их от наблюдателей на пути трафика и позволяет веб-приложениям разрешать имена напрямую.
DPoP (доказательство владения ключом): Механизм OAuth из RFC 9449, который привязывает токены доступа и токены обновления к ключу, хранящемуся у клиента: каждый запрос несёт новое подписанное доказательство DPoP в виде JWT, поэтому украденный токен сам по себе бесполезен.
DSA (алгоритм цифровой подписи): Алгоритм подписи из FIPS 186 (1994), основанный на задаче дискретного логарифма в конечном поле; FIPS 186-5 в 2023 году исключил его для новых подписей и оставил только для проверки уже существующих.

E

ECDH (протокол DH на эллиптических кривых): Согласование ключей, при котором каждая сторона комбинирует свой закрытый ключ на эллиптической кривой с открытым ключом другой стороны и получает один и тот же общий секрет — координату x точки d_A·d_B·G.
ECDH-ES (согласование ключей в JWE): Семейство алгоритмов управления ключами JWE из RFC 7518, § 4.6: отправитель генерирует эфемерный EC-ключ, согласует секрет со статическим ключом получателя и выводит из него ключ шифрования содержимого с помощью Concat KDF.
ECDHE (эфемерный DH на эллиптических кривых): Обмен ключами Диффи — Хеллмана на эллиптических кривых, при котором для каждого рукопожатия создаются новые пары ключей; именно этот обмен ключами даёт TLS прямую секретность, а в TLS 1.3 он выполняется на группах x25519, secp256r1 и подобных.
ECDLP (дискретный логарифм на эллиптической кривой): Задача нахождения скаляра d по точкам G и Q = d·G на эллиптической кривой; её вычислительная сложность — допущение, на котором держится стойкость ECDSA, EdDSA, ECDH и подписей Schnorr.
ECDSA (алгоритм подписи на эллиптических кривых): Вариант DSA на эллиптических кривых, описанный в FIPS 186-5 и SEC 1: подпись — пара целых чисел (r, s), которую вычисляют с помощью закрытого скаляра и нового секретного nonce (одноразового числа).
ECH (Encrypted Client Hello): Расширение TLS 1.3 из RFC 9849, которое шифрует настоящий ClientHello, включая имя сервера, ключом, опубликованным в DNS, так что в сети видно только общее публичное имя (public name).
ecrecover: Предкомпилированный контракт Ethereum по адресу 0x01 (и функция ecrecover в Solidity), который восстанавливает адрес подписанта по 32-байтному хешу и подписи ECDSA (v, r, s) на secp256k1.
Ed448: EdDSA на кривой Edwards448 («Goldilocks») с SHAKE256 (RFC 8032, § 5.2): уровень стойкости около 224 бит, 57-байтные открытые ключи и 114-байтные подписи.
Ed25519: EdDSA на Curve25519 в форме Эдвардса с SHA-512 (RFC 8032, § 5.1): 32-байтные открытые ключи, 64-байтные детерминированные подписи и стойкость около 128 бит.
EdDSA (алгоритм подписи на кривых Эдвардса): Схема подписи типа Schnorr на скрученных кривых Эдвардса, описанная в RFC 8032 и одобренная в FIPS 186-5; два её стандартных варианта — Ed25519 и Ed448.
eIDAS: Регламент ЕС об электронной идентификации и доверительных услугах (№ 910/2014 с изменениями, внесёнными регламентом 2024/1183), по которому квалифицированная электронная подпись имеет такую же юридическую силу, как собственноручная.
EIP-155 (защита от повторного использования): Изменение Ethereum 2016 года (Spurious Dragon, блок 2 675 000), которое включает chain ID в хеш транзакции для подписи и в значение v (v = chainId × 2 + 35 или 36), поэтому транзакция, предназначенная для одной сети, недействительна в других.
EIP-191 (стандарт подписанных данных): Соглашение Ethereum, по которому подписанные сообщения начинаются с байта 0x19 и байта версии, поэтому никогда не могут оказаться корректными транзакциями; версия 0x45 — формат personal_sign, которым пользуется большинство кошельков.
EIP-712 (подпись типизированных данных): Стандарт Ethereum для хеширования и подписи типизированных структурированных данных с разделителем домена: кошельки могут показывать пользователям поля, а подписи нельзя повторно использовать в других контрактах или сетях.
EIP-7702 (установка кода для EOA): Обновление Ethereum, действующее с хардфорка Pectra 7 мая 2025 года: оно позволяет внешнему аккаунту (EOA) делегировать свой код контракту с помощью подписанной авторизации в транзакции типа 0x04.
ERC-1271 (проверка подписей в контрактах): Стандарт Ethereum, по которому аккаунты на смарт-контрактах проверяют подписи: проверяющая сторона вызывает isValidSignature(bytes32 hash, bytes signature) и считает подпись действительной, если вернулось значение 0x1626ba7e.
ES256: Алгоритм JWS для ECDSA на кривой P-256 с SHA-256 (RFC 7518, § 3.4): подпись — ровно 64 байта в формате raw r‖s, а не DER; он же алгоритм COSE −7.
EUDI Wallet (кошелёк цифровых удостоверений): Кошелёк цифровых удостоверений, который каждое государство-член ЕС обязано предоставить гражданам по Регламенту (ЕС) 2024/1183 (eIDAS 2); в нём хранятся данные идентификации личности и аттестации в форматах SD-JWT VC и mdoc.
exp (утверждение о времени истечения): Зарегистрированное утверждение JWT (RFC 7519, § 4.1.4), которое задаёт время в секундах от начала эпохи Unix, начиная с которого токен не должен приниматься.

F

Falcon (FN-DSA): Компактная схема подписи на решётках NTRU, которую NIST выбрал в 2022 году и стандартизирует под названием FN-DSA в FIPS 206; в октябре 2026 года этот стандарт ещё оставался черновиком.
FIDO2: Принятое в альянсе FIDO общее название беспарольной аутентификации с открытым ключом, которая состоит из API WebAuthn консорциума W3C и протокола клиента и аутентификатора FIDO (CTAP 2.x).
FIPS 140-3: Стандарт США и Канады для криптографических модулей (2019 год, согласован с ISO/IEC 19790), по которому программа CMVP сертифицирует аппаратные и программные модули по уровням безопасности от 1 до 4.

H

HKDF: Функция формирования ключа на основе HMAC по схеме «извлечение и расширение» (extract-and-expand) из RFC 5869, которая превращает общий секрет, например результат ECDH, в один или несколько равномерно случайных ключей, привязанных к строке контекста.
HMAC: Код аутентификации сообщения на основе хеш-функции с ключом из RFC 2104 и FIPS 198-1, вычисляемый как H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)); он подтверждает целостность и источник сообщения любому, у кого есть тот же секретный ключ.
HQC (Hamming Quasi-Cyclic): Механизм инкапсуляции ключа на основе кодов, который NIST 11 марта 2025 года выбрал в качестве резервного к ML-KEM; его планируется стандартизировать как FIPS 207, но к октябрю 2026 года черновик стандарта ещё не был опубликован.
HS256: Алгоритм JWS HMAC с SHA-256 (RFC 7518, § 3.2), в котором издатель и проверяющая сторона используют один общий секретный ключ длиной не менее 256 бит, поэтому любой, кто может проверить токен, может и выпустить его.
HSM (аппаратный модуль безопасности): Стойкое к вскрытию устройство или облачный сервис, который генерирует и хранит ключи и выполняет криптографические операции внутри своей границы, поэтому закрытые ключи нельзя экспортировать в открытом виде.
HSTS (строгая транспортная безопасность HTTP): Заголовок HTTP-ответа из RFC 6797, который предписывает браузерам в течение заданного времени обращаться к хосту только по HTTPS, не давать пропустить ошибку сертификата и автоматически переводить любые ссылки http:// на HTTPS.

I

ID-токен: JWT, который поставщик OpenID Connect выдаёт клиенту в подтверждение того, что пользователь прошёл аутентификацию; содержит как минимум утверждения iss, sub, aud, exp и iat и подписан поставщиком.
in-toto: Фреймворк, получивший в CNCF статус Graduated, для подписанных утверждений о цепочке поставок; его формат аттестаций (Statement — утверждение, которое связывает дайджесты артефактов с типизированным предикатом) переносит сведения о происхождении SLSA и аттестации SBOM.
iss (утверждение об издателе): Зарегистрированное утверждение JWT (RFC 7519, § 4.1.1), которое указывает, кто выпустил токен; проверяющая сторона обязана точно сравнить его с издателем, чьими ключами она проверила подпись.

J

JA4 (отпечаток TLS-клиента): Метод FoxIO 2023 года для получения отпечатков TLS-клиентов по их ClientHello (протокол, версия, SNI, число наборов шифров и расширений и хеши их отсортированных списков), рассчитанный на то, чтобы оставаться стабильным, когда браузеры перемешивают порядок расширений.
JOSE (подпись и шифрование объектов JSON): Семейство форматов IETF на основе JSON для подписи, шифрования и представления ключей (JWS, JWE, JWK, JWA и JWT, RFC 7515–7519), а также рабочая группа, которая их развивает.
JWA (JSON Web Algorithms): RFC 7518, который определяет идентификаторы и параметры алгоритмов для JWS, JWE и JWK, например HS256, RS256, ES256, PS256, RSA-OAEP, ECDH-ES и A256GCM.
JWE (JSON Web Encryption): Формат JOSE из RFC 7516 для зашифрованного содержимого: его компактная форма состоит из пяти частей (заголовок, зашифрованный ключ, IV, шифртекст и тег), а управление ключами (alg) отделено от шифрования содержимого (enc).
JWK (JSON Web Key): Представление криптографического ключа в JSON, определённое в RFC 7517, с такими полями, как kty, crv, x, y, n и e для открытых ключей и d для закрытой части.
JWKS (набор ключей JSON Web Key Set): JSON-объект с массивом keys из открытых JWK; издатель обычно отдаёт его по jwks_uri, чтобы доверяющие стороны проверяли токены и следили за ротацией ключей.
JWS (JSON Web Signature): Формат JOSE из RFC 7515 для содержимого с подписью или MAC, параметры которых описаны в JSON; сериализуется компактно как header.payload.signature или в виде JSON с несколькими подписями.
JWT (JSON Web Token): Компактный токен, безопасный для URL (RFC 7519), который несёт JSON-объект с утверждениями и подписывается как JWS или шифруется как JWE; используется в ID-токенах, токенах доступа и многих API-сессиях.

K

Keccak-256: Исходная хеш-функция Keccak с 256-битным выходом и дополнением в предстандартном виде; Ethereum использует её для адресов, селекторов функций и хешей для подписи, и это не та же функция, что SHA3-256 из FIPS 202.
KEM (механизм инкапсуляции ключа): Примитив с открытым ключом, в котором операция Encaps по открытому ключу выдаёт случайный общий секрет и шифртекст, а Decaps восстанавливает секрет с помощью закрытого ключа; в постквантовом обмене ключами он заменяет протокол Диффи — Хеллмана.
kid (идентификатор ключа): Параметр заголовка JOSE и поле JWK, указывающие, каким ключом подписан или зашифрован токен, чтобы при ротации проверяющая сторона выбрала нужный ключ из JWKS.
Kyber (CRYSTALS-Kyber): Кандидат 3-го раунда конкурса NIST, из которого вырос ML-KEM; его рано внедрили в гибридном TLS (X25519Kyber768Draft00), и он несовместим со стандартным ML-KEM.

L

LibrePGP: Спецификация OpenPGP, которую ведёт автор GnuPG (draft-koch-librepgp); она продолжает линию RFC 4880bis с ключами версии 5 и собственным составным шифрованием на основе Kyber и несовместима с ключами версии 6 из RFC 9580.
LMS и HSS (подписи Лейтона — Микали): Схема подписи с состоянием на основе хеш-функций из RFC 8554 и NIST SP 800-208, в которой дерево Меркла из одноразовых ключей Винтерница подписывает фиксированное число сообщений, а HSS выстраивает деревья в иерархию, чтобы подписывать больше.

M

MD5: 128-битная хеш-функция Рона Ривеста 1991 года (RFC 1321), для которой с 2004 года находят коллизии, а с 2007-го — коллизии с выбранным префиксом; она небезопасна для любых задач защиты, где атакующий может влиять на входные данные.
mDL (мобильное водительское удостоверение): Водительское удостоверение или удостоверение личности штата, которое хранится в телефоне в виде mdoc по ISO/IEC 18013-5 и предъявляется лично по NFC или Bluetooth либо онлайн; каждый элемент данных раскрывается отдельно и подписан органом, который выдал документ.
mdoc (мобильный документ ISO/IEC 18013-5): Формат удостоверений на основе CBOR из ISO/IEC 18013-5, созданный для мобильных водительских прав: издатель подписывает дайджесты отдельных элементов данных в объекте Mobile Security Object, а устройство доказывает владение документом собственным ключом.
ML-DSA (FIPS 204): Алгоритм цифровой подписи на основе модульных решёток из FIPS 204 (август 2024 года), разработанный на базе CRYSTALS-Dilithium; основная постквантовая подпись NIST с наборами параметров ML-DSA-44, ML-DSA-65 и ML-DSA-87.
ML-KEM (FIPS 203): Механизм инкапсуляции ключа на основе модульных решёток из FIPS 203 (август 2024 года), разработанный на базе CRYSTALS-Kyber; стандартный постквантовый обмен ключами с наборами параметров ML-KEM-512, ML-KEM-768 и ML-KEM-1024.
mlkem768x25519-sha256: Гибридный обмен ключами SSH на основе ML-KEM-768, X25519 и SHA-256, стандартизированный в RFC 10042; в OpenSSH по умолчанию с версии 10.0 (апрель 2025 года).
MTA-STS (строгая транспортная защита SMTP): Механизм из RFC 8461, с помощью которого почтовый домен публикует по HTTPS политику, требующую от отправителей доставлять почту на перечисленные MX-хосты только по TLS с действительным сертификатом.
mTLS (взаимная TLS-аутентификация): TLS, в котором клиент тоже проходит аутентификацию — сертификатом и подписью CertificateVerify, поэтому обе стороны доказывают владение закрытыми ключами; применяется для трафика между сервисами, для устройств и для токенов с привязкой к отправителю в OAuth.
MuSig2: Двухраундовая схема мультиподписи из BIP-327, в которой n подписантов совместно создают одну подпись Schnorr по BIP-340, действительную для единого агрегированного открытого ключа; в блокчейне она неотличима от траты с одним подписантом.

N

NIST IR 8547: Документ NIST «Transition to Post-Quantum Cryptography Standards» (переход на стандарты постквантовой криптографии), первоначальный публичный черновик от ноября 2024 года, который предлагает после 2030 года признать устаревшими уязвимые для квантовых атак алгоритмы со стойкостью 112 бит, а после 2035 года запретить такие алгоритмы при любой стойкости.
Nonce (k в ECDSA): Число, используемое один раз; в подписях ECDSA, DSA и Schnorr — секрет k каждой подписи, который также должен быть непредсказуемым и равномерно распределённым.
Nostr: Децентрализованный протокол для социальных сетей и обмена сообщениями, в котором пользователи — это пары ключей secp256k1, а каждое событие — JSON-объект, который идентифицируется своим хешем SHA-256 и подписан подписью Schnorr по BIP-340.
npm provenance (происхождение пакетов): Подписанные сведения о происхождении SLSA, которые прикрепляются к пакетам npm, опубликованным из поддерживаемых CI-систем (функция общедоступна с 26 сентября 2023 года), и связывают каждую версию пакета с исходным репозиторием, коммитом и рабочим процессом сборки.

O

OAuth 2.0: Фреймворк авторизации из RFC 6749 (2012), в котором сервер авторизации выдаёт клиентам токены доступа, чтобы те вызывали API с делегированными правами в пределах заданных областей доступа, а не с паролями пользователей.
OCSP (онлайн-проверка статуса сертификатов): Протокол из RFC 6960, по которому клиент спрашивает у OCSP-ответчика CA, отозван ли конкретный сертификат, и получает подписанный ответ «действителен» (good), «отозван» (revoked) или «неизвестен» (unknown) с интервалом действия.
OCSP stapling: Механизм TLS, при котором сервер сам получает свежий ответ OCSP для своего сертификата и передаёт его в рукопожатии, избавляя клиентов от запроса к CA, который нарушает их конфиденциальность.
OID (идентификатор объекта): Глобально уникальная последовательность целых чисел через точку, например 1.2.840.10045.2.1, которую назначают через дерево делегированной регистрации; в ASN.1 такие идентификаторы служат именами алгоритмов, кривых, расширений и политик.
OIDC (OpenID Connect): Уровень идентификации поверх OAuth 2.0 (OpenID Connect Core 1.0, 2014), который позволяет клиенту проверить личность пользователя по подписанному ID-токену и получить утверждения профиля из эндпоинта UserInfo.
OpenID4VP (OpenID для проверяемых предъявлений): Протокол OpenID Foundation (окончательная версия 1.0, июль 2025 года), по которому проверяющая сторона запрашивает у кошелька удостоверения и получает их предъявление (presentation); он построен на OAuth 2.0 и используется в европейском кошельке цифровых удостоверений (EU Digital Identity Wallet).
OpenPGP: Стандарт IETF для шифрования и подписи сообщений и файлов по схеме с открытым ключом, где ключами управляют сами пользователи (RFC 9580, июль 2024 года); его реализуют GnuPG, Sequoia, OpenPGP.js и другие.

P

P-256 (secp256r1): Эллиптическая кривая NIST над 256-битным простым полем, также известная как secp256r1 и prime256v1; она даёт стойкость около 128 бит и шире всех других кривых применяется для ECDSA и ECDH.
P-384 (secp384r1): Эллиптическая кривая NIST над простым полем с 384-битным порядком и стойкостью около 192 бит; её требует набор CNSA 1.0 от NSA, и она распространена в иерархиях государственных PKI и CA.
P-521 (secp521r1): Самая большая кривая NIST над простым полем, определённая по модулю простого числа Мерсенна 2⁵²¹ − 1, со стойкостью около 256 бит; ES512 в JOSE означает ECDSA на P-521 с SHA-512, а не 512-битную кривую.
PAdES: Профиль ETSI для подписей PDF (EN 319 142), предназначенный для усовершенствованных электронных подписей по eIDAS, с базовыми уровнями B-B, B-T (с меткой времени), B-LT (со встроенными данными для проверки) и B-LTA (с архивными метками времени).
PASETO (платформонезависимые токены безопасности): Формат токенов, задуманный как более простая альтернатива JOSE: вместо согласуемых алгоритмов в нём версионированные протоколы. Токены v4.public подписываются Ed25519, а токены v4.local шифруются XChaCha20 и аутентифицируются с помощью BLAKE2b с ключом.
PEM: Текстовая обёртка данных DER в виде base64 между строками -----BEGIN метка----- и -----END метка-----, стандартизированная для объектов PKIX в RFC 7468; в этом формате большинство инструментов хранит сертификаты и ключи.
permit (EIP-2612 и Permit2): Одобрение токенов по подписи: подпись EIP-712 вне блокчейна даёт spender право переводить токены и заменяет транзакцию approve в блокчейне — отдельно для каждого токена (EIP-2612) или через общий контракт Permit2 от Uniswap.
personal_sign: Метод кошелька в JSON-RPC Ethereum, который подписывает сообщение с префиксом EIP-191 версии 0x45 и возвращает 65-байтную подпись r‖s‖v; стандартный выбор для входа и простой подписи сообщений.
PIV (проверка личности): Федеральный стандарт США для смарт-карт (FIPS 201-3, 2022) и интерфейс карты к нему (SP 800-73): в слотах ключей 9A, 9C, 9D и 9E хранятся ключи аутентификации, подписи, управления ключами и аутентификации карты; стандарт реализуют YubiKey и другие токены.
PKCE (ключ подтверждения для обмена кода): Расширение OAuth из RFC 7636: клиент отправляет хеш случайного code_verifier в запросе авторизации, а сам code_verifier — в запросе токена, поэтому перехваченный код авторизации бесполезен.
PKCS #8: Независимый от алгоритма контейнер закрытого ключа (PrivateKeyInfo, RFC 5208; OneAsymmetricKey, RFC 5958), который хранится в PEM как -----BEGIN PRIVATE KEY----- или, если он защищён паролем, как -----BEGIN ENCRYPTED PRIVATE KEY-----.
PKCS #12 (PFX): Защищённый паролем формат архива из RFC 7292, обычно в файлах .p12 или .pfx, который объединяет закрытый ключ с его цепочкой сертификатов для импорта в браузеры, Windows, macOS, Java и Android.
PS256: Алгоритм JWS RSASSA-PSS с SHA-256 и MGF1-SHA-256 (RFC 7518, § 3.5): он использует те же ключи RSA, что и RS256, но с рандомизированным дополнением PSS, стойкость которого доказуема.
PSBT (частично подписанная транзакция): Формат обмена из BIP-174 (версия 0) и BIP-370 (версия 2), который переносит неподписанную транзакцию вместе со всеми данными, нужными подписантам, чтобы кошельки, аппаратные устройства и координаторы могли подписывать её поэтапно.

Q

QUIC: Транспортный протокол поверх UDP из RFC 9000 со встроенным рукопожатием TLS 1.3 (RFC 9001): он шифрует почти все транспортные метаданные и переносит HTTP/3.

R

RFC 6979 (детерминированный ECDSA): Спецификация Томаса Порнина (2013), которая выводит nonce k для DSA или ECDSA из закрытого ключа и хеша сообщения с помощью HMAC-DRBG, так что для подписи не нужен генератор случайных чисел.
RS256: Алгоритм JWS RSASSA-PKCS1-v1_5 с SHA-256 (RFC 7518, § 3.3), исторически алгоритм по умолчанию у поставщиков OpenID Connect; длина подписи равна длине модуля RSA (256 байт для 2048-битных ключей).
RSA: Криптосистема с открытым ключом Ривеста, Шамира и Адлемана (1977), стойкость которой основана на сложности разложения на множители большого модуля n = p·q; она применяется для подписей и исторически — для транспорта ключей.
RSA-OAEP: Шифрование RSA с оптимальным асимметричным дополнением (Optimal Asymmetric Encryption Padding, RFC 8017, § 7.1); в JWE оно применяется как RSA-OAEP (SHA-1) и RSA-OAEP-256 (SHA-256) для обёртывания ключей содержимого и заменяет уязвимое к атакам шифрование PKCS #1 v1.5.
RSASSA-PKCS1-v1_5: Детерминированная схема дополнения для подписи RSA из PKCS #1 v1.5 (RFC 8017, § 8.2): хеш упаковывается в структуру ASN.1 DigestInfo, дополненную байтами 0xFF; это RS256 в JWT и самый распространённый вид подписи RSA в X.509.
RSASSA-PSS: Рандомизированная схема подписи RSA из PKCS #1 v2.1 и более поздних версий (RFC 8017, § 8.1): она кодирует хеш со случайной солью и функцией маскирования MGF1 и имеет точное (tight) доказательство стойкости, которого нет у PKCS #1 v1.5.

S

S/MIME: Стандарт подписи и шифрования электронной почты с помощью сертификатов X.509 и CMS (RFC 8551, S/MIME 4.0), встроенный в Outlook, Apple Mail и Thunderbird; требования к его публичным сертификатам задаёт документ CA/Browser Forum S/MIME Baseline Requirements.
SAML 2.0: XML-стандарт OASIS (март 2005 года) для обмена подписанными утверждениями об аутентификации и атрибутах между поставщиком удостоверений и поставщиками услуг; по-прежнему основа корпоративного единого входа.
SBOM (перечень программных компонентов): Машиночитаемый перечень компонентов программного обеспечения, их версий, лицензий и зависимостей между ними, обычно в формате SPDX или CycloneDX; его используют для управления уязвимостями и соблюдения требований.
SCT (подписанная метка времени сертификата): Подписанное обещание журнала CT включить сертификат или предсертификат в свой публичный журнал; клиенты получают его встроенным в сертификат, в расширении TLS или в ответе OCSP, переданном через OCSP stapling.
SD-JWT (выборочное раскрытие для JWT): Формат из RFC 9901 (ноябрь 2025 года), в котором издатель подписывает хеши утверждений с солью, а владелец раскрывает только выбранные утверждения, отправляя соответствующие им раскрытия, при необходимости вместе с JWT привязки к ключу.
SD-JWT VC: Черновик IETF (Internet-Draft), который задаёт профиль SD-JWT для цифровых проверяемых удостоверений: typ dc+sd-jwt, утверждение о типе удостоверения vct, статус и обнаружение ключей издателя; один из двух форматов удостоверений для кошелька ЕС.
SEC 1 ECPrivateKey: Структура закрытого ключа на эллиптической кривой из SEC 1 и RFC 5915, которую OpenSSL записывает как -----BEGIN EC PRIVATE KEY-----; она хранит скаляр, а также необязательные параметры кривой и открытую точку.
secp256k1: 256-битная эллиптическая кривая Коблица y² = x³ + 7 из SEC 2, которую выбрал Bitcoin и также используют Ethereum и Nostr; её стойкость — около 128 бит.
Secure Enclave: Изолированный сопроцессор безопасности Apple в чипах iPhone, iPad, Mac и Apple Watch: он создаёт неэкспортируемые ключи и подписывает или расшифровывает данные внутри чипа, при необходимости запрашивая Face ID, Touch ID или код-пароль.
security.txt: Текстовый файл по адресу /.well-known/security.txt (RFC 9116), из которого исследователи безопасности узнают, как сообщить владельцу сайта об уязвимостях.
SHA-1: 160-битная хеш-функция из FIPS 180-1 (1995), для которой на практике находят коллизии; NIST выводит её из употребления для любой криптографической защиты до 31 декабря 2030 года.
SHA-2: Семейство хеш-функций из FIPS 180-4 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 и SHA-512/256), разработанное NSA и опубликованное в 2001 году; сегодня это хеши по умолчанию почти везде.
SHA-3: Семейство хеш-функций на основе Keccak из FIPS 202 (2015 год), построенное на криптографической губке (sponge), а не на конструкции Меркла — Дамгора: SHA3-224, SHA3-256, SHA3-384, SHA3-512 и функции с расширяемым выходом SHAKE128 и SHAKE256.
SHA-256: 256-битная хеш-функция семейства SHA-2 (FIPS 180-4), хеш по умолчанию в TLS, JWT, X.509, Bitcoin и большинстве инструментов проверки целостности файлов; её стойкость к коллизиям — 128 бит, к нахождению прообраза — 256 бит.
SHAKE128 и SHAKE256: Функции с расширяемым выходом (XOF) из FIPS 202, которые выдают из губки Keccak выход любой запрошенной длины; при достаточно длинном выходе их стойкость составляет 128 и 256 бит соответственно.
Sigstore: Сервис подписи с открытым исходным кодом, который выпускает сертификаты на эфемерные ключи для удостоверений OIDC (Fulcio) и публично записывает подписи в журнал (Rekor), так что артефакты можно подписывать и проверять без долговременных ключей.
SIWE (Sign-In with Ethereum): Формат сообщений ERC-4361 для входа с аккаунтом Ethereum: понятный человеку текст с доменом, адресом, URI, версией, chain ID, nonce и временем выдачи, подписанный через personal_sign.
SLH-DSA (FIPS 205): Алгоритм цифровой подписи на основе хеш-функций без состояния из FIPS 205 (август 2024 года), созданный на базе SPHINCS+; его стойкость опирается только на хеш-функции, а платой за это служат подписи размером 7,8–50 КБ и медленное подписание.
SLSA (уровни цепочки поставок артефактов ПО): Фреймворк OpenSSF из последовательных уровней целостности сборки и исходного кода (например, Build L3 означает, что сведения о происхождении создаёт защищённая изолированная платформа сборки); актуальная спецификация — v1.2 (ноябрь 2025 года).
SNI (Server Name Indication): Расширение TLS (RFC 6066, § 3, расширение 0), в котором клиент указывает нужный ему хост, чтобы на одном IP-адресе можно было обслуживать много сертификатов; если не используется Encrypted Client Hello, оно передаётся в открытом виде.
sntrup761x25519-sha512: Обмен ключами в SSH, который сочетает Streamlined NTRU Prime sntrup761 с X25519 и хеширует результат с помощью SHA-512; метод по умолчанию в OpenSSH с версии 9.0 (2022 год), пока в версии 10.0 его не заменил mlkem768x25519-sha256.
SPF (Sender Policy Framework): Опубликованная в DNS политика из RFC 7208 со списком хостов, которые могут отправлять почту с доменом в SMTP-конверте (MAIL FROM или HELO); получатели сверяют её с IP-адресом подключившегося сервера.
SSH (Secure Shell): Протокол из RFC 4251–4254 для аутентифицированного зашифрованного удалённого входа, выполнения команд, передачи файлов и перенаправления портов, в котором сервер подтверждает свою подлинность ключом хоста, а пользователи проходят аутентификацию с помощью ключей, сертификатов или паролей.
SSH-сертификат: Подписанный документ в собственном формате OpenSSH (не X.509), в котором ключ центра сертификации привязывает открытый ключ пользователя или хоста к принципалам, сроку действия и опциям, так что отдельные ключи больше не нужно распространять.
SSHSIG (SSH-подписи): Формат OpenSSH для подписи произвольных данных ключами SSH (ssh-keygen -Y sign), который привязывает к каждой подписи пространство имён; на нём основаны подписанные SSH-ключами коммиты Git и проверка по списку allowed signers.
STARTTLS: Команда протокола, которая переводит уже установленное незашифрованное соединение на TLS (в SMTP по RFC 3207, IMAP, POP3, LDAP и XMPP) и уязвима к откату на незашифрованное соединение, если политика не требует TLS.
SubjectPublicKeyInfo (SPKI): Структура ASN.1 из RFC 5280, которая объединяет идентификатор алгоритма с битами открытого ключа; используется в каждом сертификате X.509 и как стандартный формат файла открытого ключа (-----BEGIN PUBLIC KEY-----).

T

Taproot: Софтфорк Bitcoin из BIP 340, 341 и 342, активированный 14 ноября 2021 года на блоке 709 632: он добавил подписи Schnorr и выходы P2TR, привязанные к ключу и необязательному дереву скриптов.
TLS (протокол защиты транспортного уровня): Протокол IETF, который аутентифицирует сервер (и при необходимости клиента) и шифрует поток байтов между ними; его используют HTTPS, почта, API и большинство других интернет-протоколов, текущая версия — 1.3.
TLS 1.2: Версия TLS 2008 года (RFC 5246), которую до сих пор широко поддерживают: в ней появились наборы шифров AEAD и SHA-256, но ей нужны два цикла приёма-передачи и она допускает слабые параметры, которые убрали в TLS 1.3.
TLS 1.3: Текущая версия TLS, опубликованная как RFC 8446 в 2018 году и пересмотренная как RFC 9846 в 2026 году: рукопожатие за один цикл приёма-передачи, обязательная прямая секретность, только наборы шифров AEAD и зашифрованное рукопожатие.
TLS-рукопожатие: Начальный обмен сообщениями в TLS-соединении, в ходе которого клиент и сервер согласуют параметры, выполняют обмен ключами, проводят аутентификацию (обычно аутентифицируется сервер с помощью своего сертификата) и выводят ключи трафика.
TUF (The Update Framework): Спецификация безопасного обновления ПО (проект CNCF со статусом graduated с 2019 года): подписание в ней разделено между ролями root, targets, snapshot и timestamp с порогами и сроками действия, чтобы система выдерживала компрометацию ключей.
typ (заголовок типа JOSE): Параметр заголовка JOSE, который объявляет медиатип всего токена, например JWT, at+jwt, dpop+jwt или kb+jwt; служит для явной типизации, чтобы токен одного вида нельзя было подменить токеном другого.

V

VMC (сертификат подтверждённого знака): Сертификат X.509, который для BIMI связывает домен с логотипом, зарегистрированным как товарный знак; его выпускают после проверки товарного знака и идентификационных данных, а логотип в формате SVG хранится в расширении logotype.

W

Web Bot Auth: Инициатива IETF на основе подписей HTTP-сообщений (HTTP Message Signatures), в рамках которой автоматические клиенты, например поисковые роботы и ИИ-агенты, подписывают запросы опубликованным ключом, чтобы сайты могли надёжно их опознавать, а не доверять строкам user-agent или диапазонам IP-адресов.
WebAuthn (Web Authentication): Браузерный API консорциума W3C (navigator.credentials.create и get с параметрами publicKey), через который сайты регистрируют и используют учётные данные с открытым ключом на аутентификаторах; версия Level 3 стала рекомендацией W3C 25 августа 2026 года.
Wildcard-сертификат: Сертификат с альтернативным именем субъекта (SAN) вида *.example.com, которое соответствует любой одной метке на этой позиции, например www.example.com, но не example.com и не a.b.example.com.
WKD (Web Key Directory): Способ публиковать ключи OpenPGP на собственном домене в каталоге /.well-known/openpgpkey/, чтобы почтовые клиенты могли получить ключ для адреса электронной почты по HTTPS (draft-koch-openpgp-webkey-service).

X

X.509: Формат сертификатов ITU-T с интернет-профилем RFC 5280, в котором открытый ключ связан с именем субъекта и расширениями и всё это заверено подписью выпускающего центра сертификации.
x5c (заголовок цепочки сертификатов X.509): Заголовок JOSE и поле JWK, которые передают цепочку сертификатов X.509 в виде массива сертификатов DER в кодировке base64 (не base64url); первый сертификат содержит ключ подписи.
X25519: Функция Диффи — Хеллмана на Curve25519, определённая в RFC 7748, с 32-байтовыми ключами и 32-байтовым общим секретом; её используют для обмена ключами в TLS 1.3, SSH, WireGuard, Signal и age.
X25519MLKEM768: Группа гибридного обмена ключами в TLS 1.3 (0x11EC, RFC 10024): ML-KEM-768 и X25519; постквантовый вариант по умолчанию в современных браузерах, OpenSSL и Go.
XAdES: Формат ETSI для усовершенствованных электронных подписей в XML (EN 319 132), который дополняет XML-DSig подписанными свойствами, например временем подписания и дайджестом сертификата, а также долгосрочными уровнями B-T, B-LT и B-LTA.
XMSS и XMSS^MT: Расширенная схема подписи Меркла (eXtended Merkle Signature Scheme) из RFC 8391 и NIST SP 800-208: подпись с состоянием на основе хеш-функций, построенная на одноразовых ключах WOTS+, с многодеревным вариантом для большего числа подписей.
xpub (расширенный открытый ключ): Расширенный открытый ключ BIP-32 (открытый ключ и цепной код), из которого можно вывести все неусиленные дочерние открытые ключи и адреса ниже него; его используют кошельки только для просмотра и платёжные серверы.

#

0-RTT (ранние данные TLS): Механизм TLS 1.3, позволяющий клиенту, который возобновляет сессию, отправить данные приложения в первой же серии сообщений, зашифровав их ключом из предыдущей сессии; платой за это становится отсутствие защиты от повторного воспроизведения и прямой секретности для этих данных.

По алфавиту

А

В

Г

Д

З

К

М

Н

О

П

Р

С

Т

У

Ф

Х

Ц

Э

A

B

C

D

E

F

H

I

J

K

L

M

N

O

P

Q

R

S

T

V

W

X

#

По темам

Подписи · 52 термина

JOSE и JWT · 39 терминов

PKI и сертификаты · 69 терминов

TLS · 65 терминов

Электронная почта · 18 терминов

Web3 · 33 термина

Постквантовая криптография · 34 термина

Удостоверения и WebAuthn · 53 термина

Цепочка поставок ПО · 30 терминов

OpenPGP · 9 терминов

Математика · 48 терминов