Язык: Русский

tools / aes

aes/

Симметричное шифрование и расшифровка AES. Режим, дополнение, форматы ключа и IV и кодировка настраиваются, результаты совпадают с Java и CryptoJS, а ключ не покидает браузер.

Открытый текст

Шифртекст

История

После каждого успешного шифрования или расшифровки запись сохраняется автоматически. Хранятся последние 20 записей, только в браузере этого устройства. Ключи не сохраняются, но IV и расшифрованный открытый текст сохраняются, поэтому на общем компьютере очищайте историю после работы.

Что такое AES, DES и RSA и чем они отличаются

AES и DES — симметричные шифры: шифрование и расшифровка выполняются одним и тем же ключом, как будто один ключ и запирает дверь, и отпирает. Они быстрые и подходят для больших объемов данных; сложность в том, как безопасно передать этот ключ другой стороне.

DES — старый стандарт 1970-х с эффективным ключом всего 56 бит: его уже можно подобрать перебором на специальном оборудовании или в кластере компьютеров, поэтому он нужен только для связи со старыми системами, которые его все еще используют. AES заменил DES как стандарт. Он использует ключи 128, 192 или 256 бит, практических атак на него сегодня нет, и это выбор по умолчанию для шифрования данных.

RSA — асимметричный шифр: используется пара ключей. Открытый ключ можно давать кому угодно, им шифруют; закрытый хранится у вас, им расшифровывают. Это как почтовый ящик, в который может бросить письмо кто угодно, а открыть его можете только вы. Не нужно заранее договариваться об общем ключе, но RSA медленный и за раз шифрует лишь несколько сотен байт. Реальные системы часто сочетают оба подхода: RSA шифрует случайно сгенерированный ключ AES для другой стороны, а AES шифрует сами данные.

Что такое режим шифрования и какой выбрать?

AES шифрует по 16 байт за раз; режим определяет, как длинные данные делятся на блоки и как блоки связаны друг с другом. ECB шифрует каждый блок отдельно, поэтому одинаковые данные дают одинаковый шифртекст и выдают закономерности; его лучше не использовать. CBC перед шифрованием смешивает каждый блок с предыдущим блоком шифртекста, а первый блок — с IV; это самый распространенный выбор. CFB, OFB и CTR превращают AES в поток ключа, который побайтово накладывается на данные через XOR, поэтому дополнение не нужно. GCM добавляет к CTR тег аутентификации, так что измененный шифртекст не расшифруется; сегодня это рекомендуемый режим.

Для чего нужны IV и дополнение

IV (вектор инициализации) делает так, что одни и те же данные каждый раз шифруются по-разному. Его не нужно держать в секрете, его можно передавать вместе с шифртекстом, но с одним и тем же ключом IV нельзя использовать повторно, особенно в GCM. IV нужен во всех режимах, кроме ECB: для GCM рекомендуется 12 байт, а для остальных режимов нужно ровно 16 байт.

ECB и CBC требуют, чтобы длина данных была кратна 16 байтам, поэтому короткие данные добиваются до нужной длины выбранным способом дополнения. PKCS5Padding и PKCS7Padding для AES полностью одинаковы и используются чаще всего. ZeroPadding добавляет нули и при расшифровке отбрасывает все нулевые байты в конце, так что открытый текст, который сам заканчивается нулевыми байтами, их теряет. NoPadding ничего не добавляет, поэтому длину нужно обеспечить самостоятельно. GCM дополнение не использует.

Как это соответствует Java и CryptoJS

Java: Cipher.getInstance("AES/CBC/PKCS5Padding") означает CBC с PKCS5Padding; если указать просто "AES", по умолчанию берется ECB с PKCS5Padding. В Java режимы CTR и GCM работают только с NoPadding, а тег GCM должен быть длиной от 96 до 128 бит. CryptoJS.pad.Pkcs7 в CryptoJS — это PKCS7Padding, а ZeroPadding, AnsiX923, Iso10126 и Iso97971 совпадают по названию. Если передать в CryptoJS.AES.encrypt строку-пароль, библиотека сама получает ключ и выдает результат, который начинается с U2FsdGVkX1; здесь такой вариант не поддерживается, поэтому передавайте ключ длиной 16, 24 или 32 байта и IV.

Что такое тег и AAD в GCM

Тег — это контрольное значение, которое вычисляет GCM; он занимает последние байты шифртекста (для 128-битного тега это 16 байт). AAD — дополнительные аутентифицируемые данные, например заголовок сообщения. Они не шифруются, но участвуют в проверке, поэтому при расшифровке нужно ввести те же AAD, иначе проверка не пройдет.

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

Что делать, если появляется сообщение «Длина ключа — N байт» или «Длина IV — N байт»?

Сначала проверьте, правильно ли выбран формат: те же 32 символа в формате string дают 32 байта, а в hex — только 16. Ключ AES должен быть длиной 16, 24 или 32 байта, а IV, кроме ECB и GCM, — ровно 16 байт; ничего не дополняется нулями и не обрезается автоматически, а текущая длина в байтах показана рядом с заголовками полей «Ключ» и «IV». В формате string длина считается по выбранной кодировке, поэтому одна кириллическая буква в UTF-8 занимает 2 байта. Если ваш бэкенд сначала обрабатывает пароль, например дополняет нулями или хеширует его, сначала получите итоговые байты и введите их в формате hex или base64.

Что делать, если при расшифровке пишет «неверное дополнение»?

Это значит, что последний расшифрованный блок не соответствует выбранному правилу дополнения. Обычно один из параметров — ключ, IV, режим или дополнение — отличается от использованного при шифровании, либо шифртекст скопирован не полностью. Сверьте каждый параметр с тем, что применялось при шифровании; та же ошибка возникает, если неверно выбран формат ключа или шифртекста (hex вместо base64 и наоборот). ZeroPadding и NoPadding дополнение не проверяют, поэтому с ними эта ошибка не появится, но при неверных параметрах результат будет мусором.

Начало расшифрованного текста — мусор, или пишет, что результат не является корректным текстом UTF-8

Сначала проверьте IV. Если шифртекст длиннее одного блока, неверный IV в режимах CBC и CFB портит только первый 16-байтовый блок: остальное расшифровывается правильно и ошибки дополнения нет, поэтому в начале виден мусор, а дальше нормальный текст. Если появилось сообщение, что результат не является корректным текстом, возможно, кодировка не совпадает с той, что использовалась при шифровании, например другая сторона применяла GBK. Если выбрать формат вывода hex, можно сначала проверить сами расшифрованные байты.

Что делать, если при расшифровке GCM пишет «проверка тега не пройдена»?

Это значит, что ключ, IV, AAD или длина тега не совпадают с использованными при шифровании, либо шифртекст был изменен. Последние байты ввода воспринимаются как тег, а его длина задается параметром «Длина тега» (по умолчанию 128 бит, то есть 16 байт), поэтому шифртекст и тег нужно вводить вместе; если другая сторона передала тег отдельно, сначала допишите его к шифртексту. Формат AAD по умолчанию hex, поэтому при вводе строки измените формат; если при шифровании AAD не использовались, при расшифровке оставьте поле пустым.

Результат не совпадает с Java, Python или другим бэкендом. Как найти причину?

Проверяйте в таком порядке: режим и дополнение, формат и длина в байтах ключа и IV, кодировка, форматы ввода и вывода. Открытый текст в формате string не обрезается по краям, поэтому один лишний перевод строки в конце — это уже другие данные. Режимы CTR, CFB и OFB здесь тоже дополняются выбранным способом, поэтому с PKCS5Padding шифртекст получается длиннее открытого текста; если бэкенд использует NoPadding, выберите NoPadding и здесь. CFB здесь работает с полным 128-битным блоком, поэтому с бэкендом на CFB8 результат не совпадет.

Какой формат шифртекста выбрать, hex или base64, и что будет, если ошибиться?

Ориентируйтесь на то, что выдает другая сторона: если текст состоит только из 0-9 и a-f, это hex, а если в нем есть буквы разного регистра, +, / или = в конце, это base64. При расшифровке неверный выбор не всегда сразу приводит к ошибке, потому что все символы hex допустимы и в base64; просто получаются неверные байты, и позже это проявляется как «не кратно 16» или неверное дополнение. Base64 с - и _ (URL-безопасный вариант) или без завершающих = принимается, а пробелы, двоеточия и префикс 0x в hex игнорируются.

Что хранится в истории и отправляется ли она куда-то?

Она хранится только в localStorage браузера на этом устройстве и никуда не отправляется; в коде страницы нет сетевых запросов. После каждого успешного шифрования или расшифровки добавляется одна запись, хранится не более 20 записей, а если ввод или результат длиннее 20 000 символов, запись не создается. В записи есть параметры, IV, AAD, ввод и результат, а также 8-символьный отпечаток ключа (символы после # в каждой записи, по ним можно понять, тот же это ключ или нет), но самого ключа нет, поэтому после нажатия «Загрузить» ключ нужно ввести заново. Каждую запись можно удалить отдельно, а на общем компьютере после работы нажмите «Очистить историю».

Можно ли автоматически сгенерировать случайный ключ или IV?

Нет. Кнопки генерации здесь нет, ключ и IV нужно вводить самостоятельно. Одинаковые открытый текст, ключ, IV и параметры всегда дают один и тот же результат; только дополнение ISO10126 подмешивает случайные байты, из-за чего результат меняется. Если нужны случайные значения, сгенерируйте их сами: например, команда openssl rand -hex 16 в командной строке выведет 16 байт, и их можно ввести, выбрав формат hex.