Не понимаю почему вас заминусили. Вы привели ссылку на хорошую и подробную статью, в которой автор лезет в те самые дебри, о которых размышляют все радикальные ребятки в языках.
Хотел бы вставить свои 3 копейки в споры о скорости Rust. zlib переписали на Rust (насколько я понял, не полностью) и он оказался быстрее эталона на C. Rust может предоставлять ту же скорость, что C и CPP, все зависит от программистов. Возможное (теоретическое) снижение производительности не является существенным.
Лучше в репозитории разработчиков посмотреть актуальную информацию. И оформлено нормально, и в актуальности явно не приходится сомневаться. Для начинающих важны пункты Getting Started и Command line options — по сути, все то же самое, что и здесь.
И все же ваш комментарий не давал мне покоя. Вынес код библиотеки блочного шифрования в отдельный репозиторий — теперь можно спокойно подключать в качестве зависимости.
Скорость не измерял. Честно говоря — я не знаю как корректно измерить скорость шифрования. Можно, конечно, прицепить профилировщик и шифровать какую-то большую нагрузку, например, 100/1000 Мб файл, а затем примерно оценить сколько времени занял весь процесс. Опять же — будет привязка к конкретной модели ЦП и ее условиям.
Думаю несколько нецелесообразно измерять скорость шифрования на неоптимизированной версии — часть расчетов можно выполнить заранее. К тому же — я не применяю многопоточность или SIMD.
Но чисто ради интереса — почему бы и нет. Если подскажете более-менее корректный способ это сделать — буду благодарен.
Про аппаратное шифрование знаю только, что у нас в России есть отдельные блоки, выполненные в виде небольших микросхем, которые могут ускорять необходимые операции: Стрибог, Магма, Кузнечик и так далее. Думаю там, где нужно, такие блоки прикрепить проще, чем в Эльбрусы добавлять аналог AES на данном этапе развития.
Возможно когда (и если) эти процессоры станут массовыми, можно будет говорить о необходимости добавлять другие блоки.
Свои алгоритмы, протоколы и криптографию придумывать можно, никто не запрещает, но всегда будет вероятность ошибиться.
Говоря о том, что именно криптографию свою использовать нельзя, я имею в виду уровень угрозы возможной ошибки.
Что будет, если мой алгоритм сортировки содержит ошибку? Просто будет неверный порядок элементов. Это легко выявляется и легко исправляется. Это все относится к теории информации.
А что будет, если я ошибусь в криптографии? Например, если что-то зашифрованное не будет расшифровываться? Это можно будет легко обнаружить, но непонятно как исправить. Еще пример, допустим все, что нужно, расшифровывается, но сам процесс шифрования содержит математическую ошибку. Тогда и выявить, и исправить ошибку будет сложно. Это относится как к теории информации, так и к теории криптографии.
К моей предыдущей статье оставили несколько комментариев по поводу атаки оракула с заполнением. Совершенно неочевидная ошибка, которая реально была выявлена в распространенном криптографическом пакете.
Поэтому когда вы что-то реализуете, необходимо учитывать какой уровень угрозы несут потенциальные ошибки.
Насколько я знаю, в подобных отраслях используются аппаратные криптографические средства. Тогда задача Rust, C или CPP сводится к тому, чтобы доставлять и получать из определенных регистров байты.
На самом деле не вижу никакой разницы будет здесь работать Rust или CPP.
я иду себе мимо не будучи большим знатоком или поклонником Rust, оценок не ставлю - но осмелюсь предположить что у статьи есть ощутимый недостаток - вы стали писать об алгоритмах шифрования на достаточно высоком уровне, объясняя (довольно поверхностно и поэтому порой мутно) их свойства и принципы - и тут же затаскиваете низкоуровневые потроха кода, которые в общем-то не нужны. когда нам нужно заимплементить тот или иной алгоритм шифрования на том или ином языке, мы обычно находим библиотечный метод и после пары чертыханий его прикручиваем к нашему коду. а учитывая что Rust сейчас не самый популярный язык (несмотря на то что он горячо любим своими поклонниками) вы как бы нарочно обрекаете свой в общем-то неплохой материал.
Моей главной целью было продемонстрировать реализацию режимов шифрования. Я не имею достаточных компетенций для рассмотрения этого материала с точки зрения криптографии, поэтому особо и не пытался привнести чего-то нового. Я анализировал материал Википедии и пытался соотнести с реальностью — где-то я действительно смог увидеть те минусы, о которых говорилось в материале Википедии.
Rust я использую в целях обучения. В наше время, при должном желании, можно перенести код на любой другой язык программирования с использованием всяких больших языковых моделей. Возможно в каких-либо следующих статьях я мог бы использовать Go или Python, но суть все равно будет в другом — не показать как код бы мог выглядеть на данном языке программирования, а как в целом это можно было бы реализовать.
можно было больше внимания уделить качественному объяснению принципов обсуждаемых алгоритмов
Полностью согласен, допустил пару обидных ошибок в материале.
и меньше озадачиваться реализацией (хоть вообще вынести её на гитхаб и сказать "вот ссылка для любопытных")
А вот здесь не соглашусь. Главной целью было продемонстрировать реализацию.
напомню что важный принцип в криптографии - не старайся писать криптографию сам по крайней мере для продуктового кода :)
В предыдущих статьях по алгоритмам "Streebog" и "SHA" я об этом упоминал. Эти реализации не для использования на "боевых" серверах, что отражено даже в названии каждого модуля, оно начинается на "hand-made".
Тем не менее кто-то все равно должен будет писать ответственные алгоритмы.
Добрый день, спасибо за комментарий. Попытаюсь на него ответить.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к 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 можно перегрузить операторы да еще и просто псевдоним сделать для типа [u8; 64]! В следующий раз постараюсь об этом не забывать. Спасибо!
Мои навыки программирования на Rust и в целом не находятся на высоком уровне - я не знаю как применить SIMD.
Не хочется уводить пример реализации Стрибог в направлении безудержной оптимизации. Моей целью было максимально доступно и просто пояснить шаги алгоритма. Оптимизировать я хотел только те моменты, где я явно делаю странные вещи, например, копирую кучу данных, хотя цели можно добиться передавая ссылку.
У них разве нет подключаемого модуля ? Видел файловый сервер в промо материалах.
Не понимаю почему вас заминусили. Вы привели ссылку на хорошую и подробную статью, в которой автор лезет в те самые дебри, о которых размышляют все радикальные ребятки в языках.
Хотел бы вставить свои 3 копейки в споры о скорости Rust. zlib переписали на Rust (насколько я понял, не полностью) и он оказался быстрее эталона на C. Rust может предоставлять ту же скорость, что C и CPP, все зависит от программистов. Возможное (теоретическое) снижение производительности не является существенным.
Конкретно в FreeIPA стоит этот код пересмотреть.
Снова пробив 😅
А мне тоже пришел подарок из солнечного города Сочи! Две книги по Rust и открытки (фотокарточки). Очень приятно 😄
Что в оригинале, что в переводе выглядит ужасно.
Лучше в репозитории разработчиков посмотреть актуальную информацию. И оформлено нормально, и в актуальности явно не приходится сомневаться. Для начинающих важны пункты Getting Started и Command line options — по сути, все то же самое, что и здесь.
И все же ваш комментарий не давал мне покоя. Вынес код библиотеки блочного шифрования в отдельный репозиторий — теперь можно спокойно подключать в качестве зависимости.
На crates.io не публиковал, по крайней мере пока.
Репозиторий: https://gitverse.ru/digit4lsh4d0w/block-encryption
Скорость не измерял. Честно говоря — я не знаю как корректно измерить скорость шифрования. Можно, конечно, прицепить профилировщик и шифровать какую-то большую нагрузку, например, 100/1000 Мб файл, а затем примерно оценить сколько времени занял весь процесс. Опять же — будет привязка к конкретной модели ЦП и ее условиям.
Думаю несколько нецелесообразно измерять скорость шифрования на неоптимизированной версии — часть расчетов можно выполнить заранее. К тому же — я не применяю многопоточность или SIMD.
Но чисто ради интереса — почему бы и нет. Если подскажете более-менее корректный способ это сделать — буду благодарен.
Про аппаратное шифрование знаю только, что у нас в России есть отдельные блоки, выполненные в виде небольших микросхем, которые могут ускорять необходимые операции: Стрибог, Магма, Кузнечик и так далее. Думаю там, где нужно, такие блоки прикрепить проще, чем в Эльбрусы добавлять аналог AES на данном этапе развития.
Возможно когда (и если) эти процессоры станут массовыми, можно будет говорить о необходимости добавлять другие блоки.
Я не оформлял библиотеку блочного шифрования как отдельный крейт - код находится в общем репозитории с остальным кодом.
Вот более точная ссылка: https://gitverse.ru/digit4lsh4d0w/cryptography/content/main/7-semester/hand-made-block-encryption
Способ генерации констант выходит за рамки алгоритма шифра.
И вы тоже правы! Сейчас исправлю.
Да, вы правы! Спасибо за бдительность!
Свои алгоритмы, протоколы и криптографию придумывать можно, никто не запрещает, но всегда будет вероятность ошибиться.
Говоря о том, что именно криптографию свою использовать нельзя, я имею в виду уровень угрозы возможной ошибки.
Что будет, если мой алгоритм сортировки содержит ошибку? Просто будет неверный порядок элементов. Это легко выявляется и легко исправляется. Это все относится к теории информации.
А что будет, если я ошибусь в криптографии? Например, если что-то зашифрованное не будет расшифровываться? Это можно будет легко обнаружить, но непонятно как исправить. Еще пример, допустим все, что нужно, расшифровывается, но сам процесс шифрования содержит математическую ошибку. Тогда и выявить, и исправить ошибку будет сложно. Это относится как к теории информации, так и к теории криптографии.
К моей предыдущей статье оставили несколько комментариев по поводу атаки оракула с заполнением. Совершенно неочевидная ошибка, которая реально была выявлена в распространенном криптографическом пакете.
Поэтому когда вы что-то реализуете, необходимо учитывать какой уровень угрозы несут потенциальные ошибки.
Правки внес, спасибо за исправление!
Да, вы правы. Почему-то после Стрибог немного не то запомнил.
Насколько я знаю, в подобных отраслях используются аппаратные криптографические средства. Тогда задача Rust, C или CPP сводится к тому, чтобы доставлять и получать из определенных регистров байты.
На самом деле не вижу никакой разницы будет здесь работать Rust или CPP.
В чем вы видите проблему для себя ?
Моей главной целью было продемонстрировать реализацию режимов шифрования. Я не имею достаточных компетенций для рассмотрения этого материала с точки зрения криптографии, поэтому особо и не пытался привнести чего-то нового. Я анализировал материал Википедии и пытался соотнести с реальностью — где-то я действительно смог увидеть те минусы, о которых говорилось в материале Википедии.
Rust я использую в целях обучения. В наше время, при должном желании, можно перенести код на любой другой язык программирования с использованием всяких больших языковых моделей. Возможно в каких-либо следующих статьях я мог бы использовать Go или Python, но суть все равно будет в другом — не показать как код бы мог выглядеть на данном языке программирования, а как в целом это можно было бы реализовать.
Полностью согласен, допустил пару обидных ошибок в материале.
А вот здесь не соглашусь. Главной целью было продемонстрировать реализацию.
В предыдущих статьях по алгоритмам "Streebog" и "SHA" я об этом упоминал. Эти реализации не для использования на "боевых" серверах, что отражено даже в названии каждого модуля, оно начинается на "hand-made".
Тем не менее кто-то все равно должен будет писать ответственные алгоритмы.
Добрый день, спасибо за комментарий. Попытаюсь на него ответить.
Да, понимаю, что упустил описание вектора инициализации. Когда я писал о том, что мы можем косвенно узнать с какого блока начинаются изменения, то не уточнил, что это возможно при зафиксированном векторе инициализации. Моя ошибка, согласен.
При изучении этой темы было много недосказанностей — я несколько растерялся. В этом, похоже, моя реализация неверна.
Я об этой атаке слышал только краем уха, спасибо что поделились, прочту. Свои ошибки я объясню в конце.
Об этом мне тоже было неизвестно до вашего комментария.
Здесь я преследовал несколько иные цели. Мне важно было не найти что-то похожее на режим шифрования CBC, а сравнить CTR с чем-нибудь. Он мне показался несколько отличным от других, поэтому я упомянул интересное сходство. Возможно только мне кажется, что оно там есть.
И вот здесь тоже моя ошибка. Я не знал об этом разделении вектора инициализации на части.
Попробую объяснить почему были допущены такие ошибки. Дело в том, что я рассматривал именно реализацию режимов шифрования. Да, несколько не справился, но заходить на территорию криптографии тем более не рискнул — я совершенно не имею достаточных навыков для объяснения предостережений, поэтому рассмотрение оказалось весьма поверхностным. Спасибо за ваш комментарий, из него можно взять полезные советы.
Эх если бы люди, ставящие отрицательную оценку писали в чем дело, проблему можно было бы решить. На публикацию и последующие можно повлиять, оставляя осмысленные комментарии. Исправления вносятся, а советы принимаются 😄
Точно! Совсем не подумал, что в Rust можно перегрузить операторы да еще и просто псевдоним сделать для типа [u8; 64]! В следующий раз постараюсь об этом не забывать. Спасибо!
Есть всего две причины:
Мои навыки программирования на Rust и в целом не находятся на высоком уровне - я не знаю как применить SIMD.
Не хочется уводить пример реализации Стрибог в направлении безудержной оптимизации. Моей целью было максимально доступно и просто пояснить шаги алгоритма. Оптимизировать я хотел только те моменты, где я явно делаю странные вещи, например, копирую кучу данных, хотя цели можно добиться передавая ссылку.