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

Это - коротенькая статья, в которой я хочу подвести итоги касательно этой затеи. Изначально я хотел полностью снести ту статью и никогда больше не вспоминать об этом алгоритме, но не нашёл кнопки удаления подумал, что на своих ошибках нужно не только учиться самому, но и учить других. Так что для новичков в информационной безопасности - эти две статьи могут обладать интересной и полезной информацией.

Начнём с главной проблемы алгоритма, о которой писали вообще все, кто оставлял комментарии на прошлую статью: у алгоритма нет защиты от XOR зашифрованных данных. Признаюсь - я раньше не знал о такого рода уязвимости, хотя мог бы и догадаться, ведь это простейшая бинарная логика. (Если быть совсем откровенным - у меня совсем другое мышление, поэтому какие-то моменты я могу продумывать в самых точных деталях, а какие-то пропускать. Сложно описать как это работает, но так уж устроены люди)

В чём соль: представьте, что у вас есть один ключ шифрования и несколько файлов/сообщений. Если вы зашифруете их одним и тем же ключом шифрования, "проXORив" их - то подвергнете данные огромному риску. Ведь согласно бинарной логике:

(data1 XOR key) XOR (data2 XOR key) = data1 + data2

Да, получаются не совсем исходные данные, но что-то очень близкое к ним (их сумма), явно проявляется структура данных. Если у злоумышленника будет сотня таких файлов/сообщений, зашифрованных одним и тем же ключом - ему не составит трудности по структуре данных определить исходные данные и ключ.

Поэтому - НИКОГДА не шифруйте данные одним и тем же ключом шифрования или хэшем.

Но что тогда делать, если я хочу шифровать данные одной и той же парольной фразой? Просто добавь соль - она колоссально изменяет итоговый ключ шифрования, даже если используется та же парольная фраза. Получается - у вас может быть бесконечно много разных ключей шифрования из одной парольной фразы. Эту соль нужно сгенерировать случайным образом, и использовать вместе с парольной фразой. Чтобы её не терять - можно добавлять её к зашифрованным данным, например в начало. Да, её никак прятать не нужно, можно хоть злоумышленнику в лицо кинуть - суть в том, что она уже свою работу выполнила, защитив данные от уязвимости с XOR, и теперь нужна только для расшифровки, для которой ещё и ключ шифрования надо знать.

Я решил внести изменения в свой алгоритм шифрования, чтобы защитить его от уязвимости с XOR, а заодно и усложнив поиск "Main Key" - пускай "Main Key" генерируется при помощи, например, PBKDF2, соль генерируется случайно, и записывается в начало зашифрованного файла - первые 16 байт. Ещё 4 байта на количество итераций. Конечно, немножко обидно, что теперь размер файла будет увеличиваться на 20 байт при шифровании, но это не так уж и страшно.

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

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

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

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

Предыдущую реализацию на чистом Си я снёс от греха подальше, новую почти дописал, но возникли небольшие проблемы с segmentation fault, так что если когда-нибудь допишу - то выложу. Ну или кто-нибудь обгонит меня и напишет всё на Python. Зато на Python алгоритм будет работать очень медленно, а на Си быстро, ухахахаха.

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