Зачем вам нужно много случайности для эффективного шифрования?

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

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

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

чтобы расшифровать сообщение, нужно знать правильный ключ.

чем больше ключей вы должны попробовать, тем сложнее расшифровать сообщение.

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

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

поэтому нам нужна некоторая случайность, чтобы сделать непредсказуемым, какой ключ вы используете. Как упоминает Дэвид Шмитт, Debian имел ошибку, которая заставила его генерировать только небольшое количество уникальных ключей, что означает, что для расшифровки сообщения, зашифрованного реализацией OpenSSL по умолчанию в Debian, мне просто нужно попробовать это меньшее количество возможных ключей. Я могу игнорировать огромное количество других допустимых ключей, потому что реализация SSL Debian никогда не будет генерировать их.

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

Это связано с некоторыми основными причинами криптографии:

• убедитесь, что сообщение не изменяется в пути (неизменяемый)
• убедитесь, что сообщение не читается в пути (безопасно)
• убедитесь, что сообщение от того, кто он говорит, что это от (подлинный)
• убедитесь, что сообщение не совпадает с ранее отправленным (без повтора)
• etc

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

например, если я зашифрую" слишком много секретов "с помощью ключа, он может выйти с" dWua3hTOeVzO2d9w"

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

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

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

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

Адам

общий шаблон в криптографии следующий (отправка текста от Алисы Бобу):

Take plaintext p
Generate random k
Encrypt p with k using symmetric encryption, producing crypttext c
Encrypt k with bob's private key, using asymmetric encryption, producing x
Send c+x to bob
Bob reverses the processes, decrypting x using his private key to obtain k

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

вот аналогия "карточной игры": Предположим, мы играем несколько раундов игры с одной колодой карт. Перетасовка колоды между раундами является основным источником случайности. Если бы мы не тасовали должным образом, вы могли бы победить в игре, предсказывая карты.

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

получилось этой проблема от Project Euler, и это действительно приведет к тому, что "много случайности" сделает для вас. Когда я увидел этот вопрос, это было первое, что пришло в голову.

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

довольно хороший документ, который описывает, почему не быть осторожным со случайностью может привести к неуверенности:

• http://www.cs.berkeley.edu / ~daw/papers/ddj-netscape.html

это описывает, как еще в 1995 году реализация SSL ключа браузера Netscape была уязвима для угадывания ключей SSL из-за проблемы заполнения PRNG.