Какой симметричный шифр использовать для шифрования сообщений?

Question

Я понятия не имею о шифровании. Но мне это нужно. Как?

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

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

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

Итак, вот что я хотел бы сделать:

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

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

Какой шифр я должен использовать для этого шифрования? Какую длину ключа?

Я бы предпочел использовать что-то, поддерживаемое ezPyCrypto .

Предполагая, как большинство отмечают, я иду с AES. Какие режимы мне следует использовать?

Я не мог понять, как это сделать с помощью ezPyCrypto, PyCrypto , кажется, зависает при обмене модератором и гуглит keyczar не объясняет, как это настроить - я боюсь, если я не просто получу это, тогда я рискую ввести небезопасность. Так что босоножки были бы лучше. Этот парень утверждает, что у него есть хороший модуль для AES в python, но он также утверждает, что это его первый проект на Python - хотя он, вероятно, загружен умнее меня, может быть, его споткнули?

РЕДАКТИРОВАТЬ: Я переместил поиск реализации Python в другой вопрос , чтобы остановить clobber ...

Answer 1

Я понятия не имею о шифровании. Но мне это нужно. Как?

ОПАСНОСТЬ! Если вы мало знаете о криптографии, не пытайтесь реализовать ее самостоятельно. Криптография трудно понять . Существует множество способов нарушить безопасность криптографической системы, кроме того, что вы не взломаете ключ (что обычно очень сложно).

Если вы просто добавите шифр к своим потоковым данным, без тщательного управления ключами и другого понимания тонкостей криптографических систем, вы, вероятно, откроете себя для всех видов уязвимостей. Например, описанная вами схема будет уязвима для атак «человек посередине» без какого-либо конкретного плана распределения ключей между узлами и может быть уязвима для selected-openintext и / или атака по известному тексту в зависимости от того, как ваша распределенная система взаимодействует с внешним миром, а также от точного выбора шифра и режима работы .

Итак ... прежде чем вы сможете безопасно использовать его, вам придется читать крипто в целом.

Answer 2

Ваша первая мысль должна быть о безопасности канала - либо SSL / TLS, либо IPSec.
По общему признанию, они оба имеют определенное количество накладных расходов на установку, IPSec больше, чем SSL / TLS, особенно когда речь идет о PKI и т. Д., - но это более чем окупается за простоту разработки, надежность, безопасность и многое другое. Просто убедитесь, что вы используете надежные наборы шифров, соответствующие протоколу.

Если ни SSL / TLS, ни IPSec не соответствуют вашему сценарию / среде, ваш следующий выбор должен быть AES (он же Rijndael).
Используйте ключи длиной не менее 256 бит, если хотите, можете идти дольше.
Ключи должны генерироваться случайным образом с помощью криптографически безопасного генератора случайных чисел (а не простого вызова rnd ()).
Установите режим шифрования на CBC .
Используйте заполнение PKCS7.
Создайте уникальный криптослучайный вектор инициализации (IV). Не забывайте должным образом защищать и управлять своими ключами, и, возможно, подумайте о периодической смене ключей.

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

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

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

Answer 3

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

Был длинный и сложный конкурс по отбору AES, и победитель был тщательно выбран. Даже Брюс Шнайер, бог крипто, сказал, что победитель AES - лучший выбор, чем алгоритм (TwoFish), который он представил на соревнование.

Answer 4

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

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

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

Answer 5

Почему бы не создать VPN среди узлов, которые должны безопасно общаться?

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

Answer 6

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

Answer 7

Я бы, наверное, пошел на AES .