Комментарии 5
Эх если бы люди, ставящие отрицательную оценку писали в чем дело, проблему можно было бы решить. На публикацию и последующие можно повлиять, оставляя осмысленные комментарии. Исправления вносятся, а советы принимаются 😄
Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
1.
Если мы шифруем, например JSON документ, отправляем на обработку, где вносятся минимальные изменения где-нибудь в конце или середине — мы это узнаем.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к CBC, CFB, OFB, по поводу малого изменения данных в середине или конце открытого текста, просто исчезает.
2.
В определении "шифратора", алгоритм дополнения кажется излишним. И действительно, в поточных режимах по типу OFB, CTR, а также "полу-поточном" CFB - алгоритма дополнения нет вовсе.
Плюс к этому, режимы шифрования, базируемые на дополнении (как пример, CBC), могут обладать также интересным вектором атак с оракулом. Было бы неплохо этот пункт внести как минус или предупреждение.
3.
Следуя спецификациям режима CTR мы XOR'им значение счетчика с блоком открытого текста, а затем шифруем. Алгоритм похож на CBC, по крайней мере визуально, но лишен его недостатков.
Ничего также не сказано о минусах поточных режимов шифрования по типу CTR, OFB, а именно - что если мы будем использовать один и тот же ключ шифрования с идентичным вектором инициализации / счётчиком? В таком случае, мы сможем вообще удалить ключ шифрования: (m1 xor k) xor (m2 xor k) = m1 xor m2, что является серьёзной уязвимостью, если не противодействовать повторениям.
UPD. Визуально всё же OFB больше похож на CBC, чем CTR.
UPD. Также почему-то в CTR счётчик стал просто вектором инициализации, хотя это уже не инициализация, раз таковая применяется в каждом блоке шифрования. Плюс к этому у счётчика в CTR - два параметра: константное (сеанс связи) и переменное (сам счётчик) значения. В статье об этом также ничего не сказано.
Добрый день, спасибо за комментарий. Попытаюсь на него ответить.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к CBC, CFB, OFB, по поводу малого изменения данных в середине или конце открытого текста, просто исчезает.
Да, понимаю, что упустил описание вектора инициализации. Когда я писал о том, что мы можем косвенно узнать с какого блока начинаются изменения, то не уточнил, что это возможно при зафиксированном векторе инициализации. Моя ошибка, согласен.
В определении "шифратора", алгоритм дополнения кажется излишним. И действительно, в поточных режимах по типу OFB, CTR, а также "полу-поточном" CFB - алгоритма дополнения нет вовсе.
При изучении этой темы было много недосказанностей — я несколько растерялся. В этом, похоже, моя реализация неверна.
Плюс к этому, режимы шифрования, базируемые на дополнении (как пример, CBC), могут обладать также интересным вектором атак с оракулом. Было бы неплохо этот пункт внести как минус или предупреждение.
Я об этой атаке слышал только краем уха, спасибо что поделились, прочту. Свои ошибки я объясню в конце.
Ничего также не сказано о минусах поточных режимов шифрования по типу CTR, OFB, а именно - что если мы будем использовать один и тот же ключ шифрования с идентичным вектором инициализации / счётчиком? В таком случае, мы сможем вообще удалить ключ шифрования: (m1 xor k) xor (m2 xor k) = m1 xor m2, что является серьёзной уязвимостью, если не противодействовать повторениям.
Об этом мне тоже было неизвестно до вашего комментария.
UPD. Визуально всё же OFB больше похож на CBC, чем CTR.
Здесь я преследовал несколько иные цели. Мне важно было не найти что-то похожее на режим шифрования CBC, а сравнить CTR с чем-нибудь. Он мне показался несколько отличным от других, поэтому я упомянул интересное сходство. Возможно только мне кажется, что оно там есть.
UPD. Также почему-то в CTR счётчик стал просто вектором инициализации, хотя это уже не инициализация, раз таковая применяется в каждом блоке шифрования. Плюс к этому у счётчика в CTR - два параметра: константное (сеанс связи) и переменное (сам счётчик) значения. В статье об этом также ничего не сказано.
И вот здесь тоже моя ошибка. Я не знал об этом разделении вектора инициализации на части.
Попробую объяснить почему были допущены такие ошибки. Дело в том, что я рассматривал именно реализацию режимов шифрования. Да, несколько не справился, но заходить на территорию криптографии тем более не рискнул — я совершенно не имею достаточных навыков для объяснения предостережений, поэтому рассмотрение оказалось весьма поверхностным. Спасибо за ваш комментарий, из него можно взять полезные советы.
я иду себе мимо не будучи большим знатоком или поклонником Rust, оценок не ставлю - но осмелюсь предположить что у статьи есть ощутимый недостаток - вы стали писать об алгоритмах шифрования на достаточно высоком уровне, объясняя (довольно поверхностно и поэтому порой мутно) их свойства и принципы - и тут же затаскиваете низкоуровневые потроха кода, которые в общем-то не нужны. когда нам нужно заимплементить тот или иной алгоритм шифрования на том или ином языке, мы обычно находим библиотечный метод и после пары чертыханий его прикручиваем к нашему коду. а учитывая что Rust сейчас не самый популярный язык (несмотря на то что он горячо любим своими поклонниками) вы как бы нарочно обрекаете свой в общем-то неплохой материал.
резюмируя, скажем так:
можно было больше внимания уделить качественному объяснению принципов обсуждаемых алгоритмов
и меньше озадачиваться реализацией (хоть вообще вынести её на гитхаб и сказать "вот ссылка для любопытных")
напомню что важный принцип в криптографии - не старайся писать криптографию сам по крайней мере для продуктового кода :)
я иду себе мимо не будучи большим знатоком или поклонником Rust, оценок не ставлю - но осмелюсь предположить что у статьи есть ощутимый недостаток - вы стали писать об алгоритмах шифрования на достаточно высоком уровне, объясняя (довольно поверхностно и поэтому порой мутно) их свойства и принципы - и тут же затаскиваете низкоуровневые потроха кода, которые в общем-то не нужны. когда нам нужно заимплементить тот или иной алгоритм шифрования на том или ином языке, мы обычно находим библиотечный метод и после пары чертыханий его прикручиваем к нашему коду. а учитывая что Rust сейчас не самый популярный язык (несмотря на то что он горячо любим своими поклонниками) вы как бы нарочно обрекаете свой в общем-то неплохой материал.
Моей главной целью было продемонстрировать реализацию режимов шифрования. Я не имею достаточных компетенций для рассмотрения этого материала с точки зрения криптографии, поэтому особо и не пытался привнести чего-то нового. Я анализировал материал Википедии и пытался соотнести с реальностью — где-то я действительно смог увидеть те минусы, о которых говорилось в материале Википедии.
Rust я использую в целях обучения. В наше время, при должном желании, можно перенести код на любой другой язык программирования с использованием всяких больших языковых моделей. Возможно в каких-либо следующих статьях я мог бы использовать Go или Python, но суть все равно будет в другом — не показать как код бы мог выглядеть на данном языке программирования, а как в целом это можно было бы реализовать.
можно было больше внимания уделить качественному объяснению принципов обсуждаемых алгоритмов
Полностью согласен, допустил пару обидных ошибок в материале.
и меньше озадачиваться реализацией (хоть вообще вынести её на гитхаб и сказать "вот ссылка для любопытных")
А вот здесь не соглашусь. Главной целью было продемонстрировать реализацию.
напомню что важный принцип в криптографии - не старайся писать криптографию сам по крайней мере для продуктового кода :)
В предыдущих статьях по алгоритмам "Streebog" и "SHA" я об этом упоминал. Эти реализации не для использования на "боевых" серверах, что отражено даже в названии каждого модуля, оно начинается на "hand-made".
Тем не менее кто-то все равно должен будет писать ответственные алгоритмы.
Реализация режимов шифрования на языке RUST