Проверка правильности ключа для расшифровки AES'ом

Question

[yurtaev]

Мне кажется я горожу велосипеды и что-то пропустил, но как реализовать проверку ключа для AES что он верный прежде чем расшифровывать данные, например пользователь указал неверный пароль. Пока что как идея хранить:

password_crypt = AES.encrypt("True Secret Passphrase", "True Secret Passphrase")

а потом делать проверку на стороне клиента которому будет передаваться password_crypt:

"User Secret Passphrase" === AES.decrypt(password_crypt, "User Secret Passphrase") ? "мастер пароль правильный" : "мастер пароль введен некорректно"

Мне кажется я где-то что-то упустил очень важное и всё давно без меня придумали и стандартизовали.

P.S весь алгоритм будет виден пользователю т.к будет еще работа на клиенте в браузере, как сделать проверку так что бы гарантировать пользователю надежность шифрования (снижение стойкости) от взлома в первую очередь с нашей стороны.

Comments

[ntkt]

Отделите, пожалуйста, в Вашем вопросе Key Derivation Function от проверки правильности ввода простого пароля относительно мастера. С первым Вам надо разобраться отдельно, вот тут-то все действительно стандартизировано (подсказка — ключ на вход алгоритма симм. шифрования боевых данных — это определенная функция от надежного хэша от пароля).

[yurtaev]

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

Answer 1

[zed91]

Хранение любых magic number's которые расшифровываются и сравниваются — существенное снижение криптостойкости. Хорошее решение — хранения crc блока. Шифруется весь блок данных + crc. Для проверки происходит полная расшифровка предоставленным ключом, снятие crc и сравнение его. Если crc совпадают — ключ был верным.

Comments

[ntkt]

CRC — это хорошая идея, если условия задачи позволяют его хранить вместе с блоками шифруемых данных, то я обеими руками за.

[yurtaev]

Только я не понимаю почему безопаснее хранить crc c данными, чем тот же мастер пароль шифрованный, и почему второе снижает криптостойкость а первое нет. Ведь при подборе ключа мы в обоих случаях знаем что примерно ожидать от расшифровки, точнее как проверить корректность расшифрованных данных.

[zed91]

Снятие crc с большого блока данных — довольно долгая операция, соот-но злоумышленнику потребуется больше времени для подбора. При малых размерах данных это на самом деле тоже самое. Я бы на вашем месте, если у вас будут храниться большие блоки, за одно и crc побольше взял, это увеличит время проверки пароля для всех (у пользователя больше вероятность ввода правильного пароля, соот-но раздражать это его не должно), но опять же повысит криптостойкость. При маленьких размерах данных, обычно используют несколько итераций шифрования.

Answer 2

[ntkt]

Тогда это вполне легитимный метод. Нам придется-таки получить ключ и хоть что-то, да расшифровать. Посмотрите, как делает TrueCrypt — перед тем, как расшифровать весь диск, он проверяет, что расшифровался заголовок тома, а он известного формата. Если условия задачи не позволяют добавлять известную проверочную строку в заголовок к plaintext-данным на входе, то ее придется хранить отдельно.

Еще можно хранить key check value, но это те же яйца — KCV это усеченный ключевой хэш от ключа на ключе :)

Comments

[ntkt]

*ключевой хэш от нуля на ключе, конечно же, но суть от этого не меняется, так тоже можно :)

Answer 3

[vsespb]

Чем меньше magic number, тем меньше снижение криптостойкости, используйте 2-4 байта.