SHA-1 vs SHA-256 vs SHA-512: как выбрать алгоритм хеширования в 2026 году

Откройте TLS-сертификат, базу объектов Git, заголовок блока Bitcoin, менеджер пакетов Linux или манифест образа Docker — в каждом из них вы найдёте SHA-хеш. Но не один и тот же. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: семейство охватывает три десятилетия, две конструктивные линии и переломную атаку коллизий, которая сломала старейший из алгоритмов в боевых условиях.

Это руководство охватывает всё семейство, чтобы вы могли выбрать нужный алгоритм для своей задачи без лишних сомнений.

Краткое дерево выбора

Прежде чем погружаться в детали — таблица, которая на практике нужна большинству разработчиков:

Ваша ситуация	Лучший выбор	Причина
TLS/HTTPS-сертификат	SHA-256 (минимум), SHA-384 для высокой безопасности	Требование CA/Browser Forum Baseline Requirements
Подпись JWT (HMAC или RSA)	SHA-256 (HS256/RS256)	Универсальная поддержка; SHA-384/512 для режимов соответствия
Контрольная сумма целостности ПО	SHA-256	Отраслевой стандарт; широко понятен
Архивная или долгосрочная целостность	SHA-512	Больший вывод, достаточный запас на десятилетия вперёд
Адресация по содержимому (IPFS, OCI)	SHA-256	Де-факто стандарт для content-addressed хранилища
Git (чтение/запись существующих репозиториев)	SHA-1 для существующих; SHA-256 для новых через `--object-format=sha256`	Git в процессе миграции; SHA-1 всё ещё доминирует
Взаимодействие с Ethereum	Keccak-256 (не NIST SHA-3)	Ethereum использует вариант Keccak до стандартизации
Эшелонированная защита или засекреченные системы	SHA-384 или SHA-512	NSA Suite B; сочетается с AES-256-GCM
Новый код, нет ограничений по совместимости	SHA-3 (SHA3-256)	Другая конструктивная линия; нет уязвимости расширения длины
Хранение паролей	Ничего из вышеперечисленного	Используйте bcrypt, Argon2id или scrypt — SHA слишком быстр

Семейство SHA в кратком обзоре

Алгоритм	Стандарт	Бит вывода	Hex-символов	Год	Статус NIST	Основное применение сегодня
SHA-1	FIPS 180-4	160	40	1995	Устарел (2011), запрещён для цифровых подписей	Git (legacy), отпечатки
SHA-256	FIPS 180-4	256	64	2001	Актуален	TLS, JWT, Bitcoin, контрольные суммы
SHA-384	FIPS 180-4	384	96	2001	Актуален	Suite B, высокобезопасный TLS
SHA-512	FIPS 180-4	512	128	2001	Актуален	Архив, LUKS, HMAC-SHA-512
SHA-3 (любой вариант)	FIPS 202	224/256/384/512	varies	2015	Актуален	Альтернативная линия, аппаратное ускорение

SHA-1 и SHA-2 (группа 256/384/512) используют конструкцию Меркла–Дамгора. SHA-3 использует губчатую конструкцию — различие, которое важнее, чем кажется на первый взгляд, и о котором рассказано ниже.

SHA-1: сломан, но не умер

SHA-1 был рабочей лошадкой 2000-х. SSL-сертификаты, S/MIME-почта, PGP-отпечатки и Git — всё сошлось на нём. Затем в феврале 2017 года Google и CWI Amsterdam опубликовали SHAttered: атаку с выбранным префиксом, которая породила два различных PDF-файла с одинаковыми SHA-1-хешами. Атака потребовала приблизительно 6,5 × 10^19 вычислений SHA-1 — в 2017 году это было дорого, сегодня это доступно с облачными вычислениями.

NIST уже объявил SHA-1 устаревшим для цифровых подписей в 2011 году (NIST Special Publication 800-131A). Демонстрация SHAttered ускорила зачистку: к 2017 году браузеры перестали доверять TLS-сертификатам с SHA-1, а CA/Browser Forum сделал SHA-256 обязательным для новых выпусков.

Где SHA-1 ещё применяется:

База объектов Git: Git проектировался вокруг SHA-1 как быстрой хеш-функции для содержимого, а не как примитива безопасности. Формат репозитория жёстко кодирует 40-hex идентификаторы объектов. Путь миграции на SHA-256 (git init --object-format=sha256) существует, но принят медленно, потому что каждая хостинговая платформа, каждый CI-инструмент и каждый существующий клон потребуют синхронной миграции.
Отпечатки legacy-систем: Старые отпечатки SSH host-ключей, отпечатки PGP-ключей и схемы серийных номеров сертификатов всё ещё выдают SHA-1-значения. В большинстве контекстов они информационные, а не критически важные для безопасности.

Что делать: не используйте SHA-1 ни для чего нового. Для Git риск коллизий невысок при типичных рабочих процессах разработки (злоумышленнику нужно контролировать оба файла в коллизии), однако новые проекты с --object-format=sha256 — верное долгосрочное направление.

Сгенерируйте SHA-1-хеш в браузере: Генератор SHA-1.

SHA-256: рабочая лошадка

SHA-256 — алгоритм, на котором держится интернет в 2026 году. Каждый TLS-сертификат, выданный публичным удостоверяющим центром, использует SHA-256 для хеша подписи. Каждый JWT, подписанный с HS256, RS256 или ES256, использует SHA-256 внутри. Доказательство работы Bitcoin — это двойной SHA-256. Хеширование содержимого Docker — SHA-256. Проверка целостности пакетов npm использует SHA-256.

Причины практические:

Запас безопасности: 256 бит вывода означают 2^128 операций для атаки грубой силой на прообраз — за пределами любого мыслимого оборудования в обозримом будущем. Фактический уровень безопасности чуть ниже из-за атак на коллизии на основе «дня рождения» (2^128 операций), но всё равно неодолим.
Аппаратное ускорение: SHA-256 реализован в кремнии на каждом процессоре Intel Goldmont+ (расширение SHA-NI), каждом чипе Apple silicon, каждом процессоре ARMv8 и выделенных ASIC в сетевых устройствах и контроллерах хранилищ. Если аппаратный путь доступен, пропускная способность SHA-256 превосходит многие программные альтернативы, кажущиеся более быстрыми.
Вездесущая поддержка библиотек: Каждая TLS-библиотека, каждая JWT-библиотека, каждая стандартная библиотека языков реализует SHA-256. Проблем с совместимостью не будет.

Для адресации по содержимому, проверки целостности и большинства рабочих процессов подписи SHA-256 — правильный стандарт, если только конкретный стандарт не требует иного.

Сгенерируйте SHA-256-хеш в браузере: Генератор SHA-256.

SHA-384: специализация для TLS

SHA-384 — это SHA-512, усечённый до 384 бит. Он создан для обеспечения 192-битного уровня безопасности (половина размера вывода — нижняя граница устойчивости к коллизиям) и включён в криптографию NSA Suite B вместе с AES-256-GCM и ключами на эллиптической кривой P-384.

Два свойства делают SHA-384 особенно привлекательным для TLS:

Иммунитет к расширению длины при данном размере вывода: SHA-256 и SHA-512 уязвимы к атакам расширения длины — злоумышленник, знающий H(secret || message), может вычислить H(secret || message || extension), не зная секрета. SHA-384 и SHA-512/256 усечены от полного внутреннего состояния, поэтому расширение длины к ним неприменимо. Если вы используете сырые SHA-хеши как MAC (вместо HMAC), SHA-384 безопаснее.
Соответствие Suite B: Организации, обязанные соответствовать требованиям NSA/CNSA (Commercial National Security Algorithm), должны использовать SHA-384 или SHA-512 вместе с RSA-3072+, ECDH P-384 и AES-256. Если ваш клиент — федеральное агентство США или подрядчик, работающий по требованиям FIPS 140-3, SHA-384 может быть обязательным.

SHA-384 не является существенно более безопасным, чем SHA-256, для большинства сценариев — практическая разница между 128-битной и 192-битной устойчивостью к коллизиям теоретична при нынешних вычислительных мощностях. Выбирайте его, когда соответствие требованиям или сочетание Suite B этого требует, а не для общего использования.

Сгенерируйте SHA-384-хеш в браузере: Генератор SHA-384.

SHA-512: когда нужно больше бит

SHA-512 производит 512-битный (128-hex-символьный) дайджест. На 64-битном оборудовании он нередко быстрее SHA-256, потому что алгоритм оперирует 64-битными словами, а не 32-битными — внутреннее расписание SHA-256 использует 32-битную арифметику, тогда как SHA-512 использует 64-битную, которая эффективнее отображается на современные процессоры.

Ориентировочные тесты на 64-битном оборудовании (Web Crypto API браузера):

Алгоритм	Приблизительная пропускная способность
SHA-1	~600 МБ/с
SHA-256	~500 МБ/с
SHA-384	~700 МБ/с
SHA-512	~700 МБ/с
SHA-3-256	~300 МБ/с

Примечание: SHA-384 и SHA-512 используют одну и ту же внутреннюю функцию сжатия, поэтому работают с одинаковой скоростью. SHA-256 медленнее на 64-битных системах, потому что 32-битный размер слова означает больше итераций для обработки каждого 512-битного блока сообщения. На 32-битном или ограниченном по ресурсам оборудовании SHA-256 быстрее.

SHA-512 хорошо подходит для:

Архивной целостности: Контрольные суммы, призванные пережить десятилетия, выигрывают от большего запаса вывода.
Полнодискового шифрования: Linux LUKS использует SHA-512 в качестве стандартного PBKDF-хеша для получения ключей (как компонент PBKDF2, а не самостоятельный хеш).
HMAC-SHA-512: Применяется в некоторых схемах подписи JWT (HS512) и аутентификации API, где предпочтительны большие MAC.
Генерации больших объёмов псевдослучайных данных: Приложения, хеширующие начальное значение и нуждающиеся во многих выходных битах, могут использовать SHA-512, чтобы сократить число вызовов хеша.

Сгенерируйте SHA-512-хеш в браузере: Генератор SHA-512.

SHA-3: иная философия проектирования

SHA-3 — это не SHA-2 с увеличенным выводом. Это принципиально другой алгоритм, основанный на губчатой конструкции Keccak, разработанной Гвидо Бертони, Джоан Дэмен, Микаэлем Питерсом и Жилем Ван Аше. NIST выбрал его победителем семилетнего открытого конкурса (2007–2012), призванного создать семейство хешей, которое могло бы служить резервом в случае обнаружения слабостей в конструкции Меркла–Дамгора в SHA-2.

Губчатая конструкция работает иначе, чем конструкция Меркла–Дамгора:

Входные данные дополняются и разбиваются на блоки.
Каждый блок складывается по XOR с первой частью большого внутреннего состояния («скоростью»), после чего всё состояние переставляется перестановкой Keccak-f.
После поглощения всех входных данных вывод «выжимается» из скоростной части состояния.

Поскольку вывод извлекается лишь из части состояния, а ёмкостная часть никогда не раскрывается напрямую, губчатые конструкции по своей природе невосприимчивы к атакам расширения длины без усечения.

Стандартные варианты SHA-3 (FIPS 202):

Вариант	Бит вывода	Уровень безопасности
SHA3-224	224	112-bit
SHA3-256	256	128-bit
SHA3-384	384	192-bit
SHA3-512	512	256-bit
SHAKE128	переменный	128-bit
SHAKE256	переменный	256-bit

SHA-3 vs SHA-2 на практике:

SHA-3 пока не широко распространён в протоколах, разработанных до 2015 года — TLS, JWT и большая часть интернет-инфраструктуры по-прежнему используют SHA-2. SHA-3 появляется в постквантовых схемах подписи (CRYSTALS-Dilithium, SPHINCS+ используют SHA-3 внутри), в новых проектах протоколов, которым нужна резервная линия иной конструкции, и в оборудовании, где перестановка Keccak хорошо ускоряется. В чистом программном коде SHA-3 примерно на 40% медленнее SHA-256 на x86.

Сгенерируйте SHA-3-хеш в браузере: Генератор SHA-3.

Отличие Keccak-256 в Ethereum

Критически важный нюанс: Ethereum не использует NIST SHA-3. Ethereum проектировался, пока конкурс Keccak ещё продолжался, до того как NIST финализировал FIPS 202. Виртуальная машина Ethereum использует оригинальную заявку Keccak-256, которая применяет иное дополнение, чем финализированный стандарт NIST SHA-3.

Конкретно:

NIST SHA3-256 добавляет дополнение 0x06 перед финальным блоком.
Оригинальный Keccak-256 (как используется в Ethereum) добавляет дополнение 0x01.

Один и тот же ввод даёт разные хеши. Вызов NIST SHA3-256 и вызов keccak256 Ethereum — не взаимозаменяемы. В большинстве языков есть оба варианта: в Python hashlib.sha3_256() — это NIST SHA-3; для Keccak-256 по стандарту Ethereum нужна библиотека вроде pysha3 (реализует keccak_256). В JavaScript библиотека js-sha3 предоставляет оба варианта. Генератор SHA-3 реализует NIST SHA3-256 — если вам нужны хеши Ethereum Keccak-256, используйте специализированный инструмент для Ethereum.

Тесты производительности

Приведённые ниже цифры ориентировочны для Web Crypto API браузера на современном 64-битном ноутбуке x86. Реальная пропускная способность варьируется в зависимости от оборудования, размера сообщения и наличия аппаратного пути ускорения.

Алгоритм	Потоковая пропускная способность (64-bit)
SHA-1	~600 МБ/с
SHA-256	~500 МБ/с
SHA-384	~700 МБ/с
SHA-512	~700 МБ/с
SHA-3-256	~300 МБ/с

Для коротких сообщений (API-токены, контрольные суммы объёмом до нескольких КБ) все алгоритмы завершаются менее чем за 2 мкс — разница незаметна. Для больших данных (tar-архивы, образы дисков) SHA-384/512 обгоняют SHA-256 на 64-битных системах, поскольку оперируют 64-битными словами. SHA-3 медленнее в чистом программном коде; предпочитайте SHA-2 в коде, критичном к пропускной способности, если только аппаратное ускорение Keccak не доступно. Пропускная способность SHA-1 — никогда не повод его использовать.

Типичные ловушки

Несоответствие кодировки

SHA оперирует байтами. Если вы хешируете строку "hello" в браузере, где JavaScript кодирует её как UTF-16, а не UTF-8, вы получаете другой дайджест, чем скрипт Python, использующий str.encode("utf-8"). Всегда нормализуйте текст в UTF-8 перед хешированием.

Устойчивый паттерн:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

Отсутствие соли для MAC

Использование сырого SHA-хеша в качестве кода аутентификации сообщения (H(secret || message)) уязвимо к атакам расширения длины для SHA-256 и SHA-512. Используйте HMAC (RFC 2104) вместо этого: HMAC-SHA256(key, message). HMAC оборачивает хеш внутренней и внешней дополненной ключом прокладкой, которая предотвращает атаки расширения.

Расширение длины в SHA-256

Если вы строите подпись API как SHA256(secret + payload), злоумышленник, знающий результирующий хеш, может вычислить SHA256(secret + payload + attacker_extension), не зная секрета. Исправление: используйте HMAC, или SHA-3 (невосприимчив по конструкции), или SHA-384/SHA-512/256 (невосприимчивы из-за усечения).

Путаница Keccak-256 с NIST SHA-3

Как описано выше: Ethereum использует Keccak-256 с дополнением 0x01; NIST SHA3-256 использует дополнение 0x06. Они дают разные выводы для одного ввода. Убедитесь, какой вариант реализует ваша библиотека, прежде чем интегрироваться с контрактами Ethereum или ABI-кодированием Solidity.

Использование SHA для паролей

Алгоритмы SHA разработаны для быстроты. Это ровно неверное свойство для хранения паролей: GPU-кластер может вычислять миллиарды SHA-256-хешей в секунду, что делает атаку по словарю на базу паролей с SHA-хешами практической. Для паролей используйте медленную KDF с затратами по памяти: Argon2id (рекомендуется), bcrypt или scrypt. Никогда не храните пароли как сырые SHA-хеши, даже с солью.

Часто задаваемые вопросы

В чём разница между SHA-1 и SHA-256?

SHA-1 и SHA-256 — обе хеш-функции Меркла–Дамгора, стандартизованные в FIPS 180-4, однако SHA-256 производит 256-битный дайджест против 160-битного у SHA-1. Важнее то, что SHA-1 сломан: реальная атака коллизий (SHAttered, 2017) продемонстрировала два различных PDF-файла с одинаковым SHA-1-хешем. SHA-256 не имеет известных атак коллизий и обеспечивает 128-битный уровень устойчивости к коллизиям. Используйте SHA-256 для всего, что требует гарантий целостности; не используйте SHA-1 для новых разработок.

Быстрее ли SHA-512, чем SHA-256?

На 64-битном оборудовании — да, нередко на 30–40% для больших входных данных. SHA-512 использует 64-битную арифметику слов, которую современные процессоры обрабатывают нативно. SHA-256 использует 32-битную арифметику слов, требуя вдвое больше операций на блок сообщения на том же оборудовании. На 32-битных платформах или ограниченных микроконтроллерах SHA-256 быстрее. Для коротких сообщений (до нескольких КБ) разница неощутима.

Стоит ли мигрировать с SHA-1 на SHA-256?

Для цифровых подписей, TLS-сертификатов и подписи кода: да, однозначно — SHA-1 устарел и активно сломан. Для репозиториев Git: путь миграции существует (git init --object-format=sha256), но принят медленно из-за требований к координации экосистемы; риск коллизий при типичном использовании репозитория низок. Для информационных отпечатков (отображение SSH host-key): риск безопасности минимален, но миграция на SHA-256 — хорошая гигиена.

Можно ли обратить SHA-256?

Нет. SHA-256 — односторонняя функция по замыслу. Имея хеш, нельзя математически восстановить исходный ввод. Злоумышленники могут проводить атаку по словарю или грубой силой: хешировать миллионы кандидатов и сравнивать. Для низкоэнтропийных вводов (короткие строки, часто встречающиеся пароли, последовательные числа) предвычисленные радужные таблицы делают это практичным. Для высокоэнтропийных вводов (случайные UUID, большие файлы) обращение нереализуемо вычислительно. Именно поэтому SHA в одиночку непригоден для паролей — нужна медленная KDF с солью.

Когда использовать SHA-3 вместо SHA-2?

SHA-3 уместен, когда: (а) вы хотите хеш из другой конструктивной линии как страховку от будущих слабостей SHA-2; (б) ваш протокол требует иммунитета к расширению длины без HMAC; (в) вы реализуете постквантовые схемы подписи, которые внутренне используют SHA-3; или (г) у вас есть аппаратное ускорение для Keccak и нужна пропускная способность. Для большинства повседневных сценариев (TLS, JWT, контрольные суммы) SHA-256 имеет более широкую поддержку экосистемы и является прагматичным стандартом. SHA-3 не более безопасен, чем SHA-2, при эквивалентных размерах вывода — это иная ставка на долгосрочную безопасность.

Почему Ethereum использует Keccak-256 вместо NIST SHA-3?

Ethereum проектировался в 2013–2014 годах, до того как NIST опубликовал FIPS 202 (август 2015 года), финализировав стандарт SHA-3. В то время заявка Keccak считалась вероятным победителем, и авторы Ethereum использовали её напрямую. Когда NIST финализировал стандарт, они изменили разделительное дополнение с 0x01 (оригинальный Keccak) на 0x06, что даёт разный вывод для одного ввода. Ethereum уже был развёрнут с оригинальным дополнением Keccak и не мог это изменить. Таким образом, «Ethereum keccak256» и «NIST SHA3-256» — разные алгоритмы, несмотря на то что оба основаны на одной перестановке Keccak-f.

Попробуйте инструменты: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — все работают в браузере, данные не покидают устройство.

SHA-1 vs SHA-256 vs SHA-512: гид по хешированию 2026