Сочетание более одного криптоалгоритма - PullRequest
4 голосов
/ 23 сентября 2008

Я рассматриваю следующее: у меня есть некоторый поток данных, который я хотел бы защитить как можно безопаснее - имеет ли смысл применять, скажем, AES с некоторым IV, затем Blowfish с некоторым IV и, наконец, снова AES с какой-то IV?

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

У меня есть для этого возможности компьютера (объем данных не такой большой), поэтому вопрос только в том, стоит ли его реализовывать. Например, TripleDES работал очень похожим образом, используя три IV и схему шифрования / дешифрования / шифрования, так что, вероятно, это не полная чепуха. Другой вопрос: насколько я уменьшу безопасность, когда использую один и тот же IV для 1-й и 3-й части или даже один и тот же IV для всех трех частей?

Я приветствую любые подсказки на эту тему

Ответы [ 14 ]

11 голосов
/ 23 сентября 2008

Я не уверен насчет этой конкретной комбинации, но вообще плохая идея смешивать подобные вещи, если эта конкретная комбинация не была тщательно исследована. Вполне возможно, что математические преобразования будут фактически противодействовать друг другу, и конечный результат будет легче взломать. Одного прохода AES или Blowfish должно быть более чем достаточно.

ОБНОВЛЕНИЕ: Из моего комментария ниже ...

Используя TripleDES в качестве примера: подумайте, сколько времени и усилий потратили лучшие криптографы мира на создание этой комбинации (обратите внимание, что DoubleDES имела уязвимость), и лучшее, что они могли сделать, - это 112 бит безопасности, несмотря на 192 бит ключ.

ОБНОВЛЕНИЕ 2: Я должен согласиться с Диомидисом, что AES чрезвычайно вряд ли будет слабым звеном в вашей системе. Практически любой другой аспект вашей системы с большей вероятностью будет скомпрометирован, чем AES.

ОБНОВЛЕНИЕ 3: В зависимости от того, что вы делаете с потоком, вы можете просто использовать TLS (преемник SSL). Я рекомендую Практическая криптография для более подробной информации - она ​​довольно неплохо справляется со многими проблемами, которые вам нужно решить. Среди прочего, здесь обсуждаются потоковые шифры , которые могут быть или не быть более подходящими, чем AES (поскольку AES является блочным шифром , и вы специально упомянули, что у вас есть поток данных для шифрования ).

4 голосов
/ 23 сентября 2008

Хакер всегда атакует самый слабый элемент в цепочке. Так что это помогает немного сделать сильный элемент еще сильнее. Взломать шифрование AES уже невозможно с длиной ключа 128 бит. То же самое касается Blowfish. Выбор еще большей длины ключа делает его еще сложнее, но на самом деле 128-битный код до сих пор не был взломан (и, вероятно, не будет в течение следующих 10 или 20 лет). Так что это шифрование, вероятно, не самый слабый элемент, поэтому зачем его укреплять? Это уже сильно.

Подумайте, что еще может быть самым слабым элементом? IV? На самом деле я бы не стал тратить слишком много времени на то, чтобы выбрать отличный IV или скрыть его. Самым слабым ключом обычно является ключ шифрования. Например. если вы шифруете данные, хранящиеся на диске, но ваше приложение должно прочитать эти данные, ваше приложение должно знать IV и ключ шифрования, следовательно, оба они должны быть в пределах бинарный Это на самом деле самый слабый элемент. Даже если вы берете 20 методов шифрования и связываете их в своих данных, IV и ключи шифрования всех 20 должны быть в двоичном виде, и если хакер может извлечь их, тот факт, что вы использовали 20 вместо 1 метода шифрования, обеспечил ноль дополнительных безопасность.

Поскольку я до сих пор не знаю, что такое весь процесс (кто шифрует данные, кто расшифровывает данные, где хранятся данные, как они транспортируются, кому нужно знать ключи шифрования и т. Д.), Трудно сказать, что на самом деле является самым слабым элементом, но я сомневаюсь, что само шифрование AES или Blowfish является вашим самым слабым элементом.

4 голосов
/ 23 сентября 2008

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

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

1 голос
/ 24 сентября 2008

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

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

например. Я начинаю с открытого текста A и шифрую его ключом K1 , чтобы получить B . Затем я шифрую B ключом K2 , чтобы получить C .

Интуитивно кажется разумным предположить, что вполне может существовать ключ K3 , который я мог бы использовать для шифрования A и получения C напрямую. Если это так, то злоумышленник, использующий грубую силу, в итоге наткнется на K3 и сможет расшифровать C , в результате чего дополнительный этап шифрования не повысит безопасность.

Однако вряд ли такой ключ существует (для любой современной схемы шифрования). (Когда я говорю здесь «крайне маловероятно», я имею в виду то, что нормальный человек выразил бы словом «невозможно»).

Почему?
Рассматривайте ключи как функции, которые обеспечивают отображение от простого текста к зашифрованному тексту.
Если все наши ключи имеют длину KL битов, то существует 2 ^ KL таких отображений.
Однако, если я использую 2 ключа KL бит каждый, это дает мне (2 ^ KL) ^ 2 сопоставления.
Не все из них могут быть эквивалентны одноэтапному шифрованию.

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

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

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

... Не стесняйтесь исправлять мою математику!

1 голос
/ 23 сентября 2008

От кого вы пытаетесь защитить свои данные? Ваш брат, ваш конкурент, ваше правительство или инопланетяне?

Каждый из них имеет разные уровни, на которых вы можете считать данные «максимально безопасными» в рамках значимого бюджета (времени / денег)

0 голосов
/ 28 сентября 2008

Я согласен с тем, что было сказано выше. Несколько этапов шифрования не принесут вам много пользы. Если вы используете «безопасный» алгоритм, то его практически невозможно сломать. Использование AES в каком-то стандартном потоковом режиме. См. http://csrc.nist.gov/groups/ST/toolkit/index.html для принятых шифров и режимов. Все, что рекомендуется на этом сайте, должно быть достаточно безопасным при правильном использовании. Если вы хотите быть более безопасным, используйте AES 256, хотя 128 все равно должно быть достаточно. Наибольшие риски связаны не с атаками на сам алгоритм, а с атаками на управление ключами или атаками по сторонним каналам (которые могут быть или не быть риском в зависимости от приложения и использования). Если ваше приложение уязвимо к атакам управления ключами или атакам по сторонним каналам, тогда действительно не имеет значения, сколько уровней шифрования вы применяете. Вот где я бы сосредоточил ваши усилия.

0 голосов
/ 24 сентября 2008

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

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

Если данные имеют значение real , им лучше не атаковать данные, а держатель ключа ...

0 голосов
/ 24 сентября 2008

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

TrueCrypt предоставляет ряд алгоритмов комбинированного шифрования, таких как AES-Twofish-Serpent. Конечно, при их использовании снижается производительность.

0 голосов
/ 23 сентября 2008

На самом деле вы не можете сделать вещи менее безопасными, если вы шифруете более одного раза с помощью различных IV и ключей, но выигрыш в безопасности может быть намного меньше, чем вы ожидаете: в примере 2DES Атака «встречайся посередине» означает, что преодолеть ее вдвое сложнее, чем придать квадрат сложности.

В целом, однако, гораздо безопаснее придерживаться одного известного алгоритма и увеличить длину ключа, если вам нужна дополнительная безопасность. Оставьте составление криптосистем экспертам (и я не считаю себя одним из них).

0 голосов
/ 23 сентября 2008

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

Полагаю, именно он (она?) Предложил также повысить безопасность за счет защиты от отладки ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...