Безопасна ли следующая реализация AES 128 CTR шифрования?

Question

[Никита]

Реализую AES 128 CTR шифрование. Реализовал, работает, блоки совпадают. Но все-таки есть некоторые сомнения на счет надежности моей реализации, поэтому, прошу знающих людей помочь.

Берется оригинальный файл и берется ключ. Файл разбивается на блоки по 16 байт (128 бит). Файл не всегда разбивается нацело, поэтому, если длина файла в байтах не кратна 16, то в конец последнего блока пишется байт 0x01, а оставшееся место в блоке (при наличии) забивается байтами 0x00. Если же длина файла в байтах кратна 16, то создается еще один блок в начале которого стоит байт 0x01, а все остальные байты - 0x00. Далее все эти блоки шифруются при помощи AES 128 CTR. CTR режим использует для шифрования счетчик и без него расшифровать файл нельзя. Счетчик, который занимает 16 байт пишется сразу после зашифрованных блоков, причем счетчик не шифруется. Далее, после счетчика, записывается блок с KCV ключа (первые 6 байтов блока - KCV, остальные десять - 0x00). KCV тоже не шифруется.

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


P.S. KCV считаю согласно определению из Википедии. Беру блок состоящий исключительно из байтов 0x01, шифрую его при помощи ключа и первые 6 байт блока беру как KCV ключа. Подобная операция нужна для проверки правильности ключа при дешифровании.

Answer 1

[Армянское Радио]

Первый ответ, который приходит ко мне в голову, когда я вижу криптографический велосипед - он опасен, и безопасен одновременно. Опасен, потому что про него никто не знает - а значит, никто не пользуется и эксперты в нем не ищут дыры. Ну и безопасен он по этой же причине.

Как минимум, возможность проверки правильности ключа при дешифровании должна быть опциональной - потому что это прекрасное подспорье для брутфорса. Если усер очепятался при наборе пароля - ССЗБ.

Comments

[Никита]

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

[Армянское Радио]

gth-other, для этого есть тупой, стандартный, и аппаратно ускорееный на Интеле способ - считать CRC32 каждого файла и класть рядом. Хотите быть злее - считайте SHA256 (причем раз так 10000, чтобы брутфорсеру было весело).

Первый ответ, который приходит ко мне в голову, когда я вижу криптографический велосипед - он опасен, и безопасен одновременно. Опасен, потому что про него никто не знает - а значит, никто не пользуется и эксперты в нем не ищут дыры. Ну и безопасен он по этой же причине.

[Никита]

Армянское Радио, спасибо, поищу информацию. Но если не считать проблему довольно быстрого брутфорса через KCV, есть ли в реализации какие-то уж слишком заметные дыры? Меня, лично, особо интересует возможно ли узнать ключ шифрования, если известен оригинальный блок и зашифрованный блок (такая ситуация возникает с блоком дополнения в случаях, когда длина оригинального текста в байтах делится на 16). Я реализую этот велосипед не для продакшена, а для более детального понимания принципа работы шифрования.