Подтвердить что ты не робот

Рекомендации по шифрованию непрерывных/небольших данных UDP

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

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

В настоящее время я использую 128-битный ключ, полученный от кодовой фразы от пользователя, и AES в режиме CBC (PBE с использованием AES-CBC). Я решил использовать случайную соль с кодовой фразой для вывода 128-битного ключа (запретить атаку словаря на кодовую фразу) и, конечно же, использовать IVs (чтобы предотвратить статистический анализ пакетов).

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

Итак, мой вопрос: каковы наилучшие методы для отправки/шифрования непрерывных небольших данных с использованием протокола без установления соединения (UDP)? Мой способ - лучший способ сделать это?... потекла?... Overkill?

Обратите внимание, что я не прошу о 100% -ом безопасном решении, так как такой вещи нет.

4b9b3361

Ответ 1

У вас есть несколько вариантов. Вы можете использовать DTLS, который является версией TLS, адаптированной для дейтаграмм. Он указан в RFC и реализован в библиотеке openssl. Вы также можете использовать протокол IKE/IPsec и использовать инкапсуляцию UDP части IPsec. Обычно IPsec доступен на уровне ОС. Вы также можете использовать OpenVPN, который выглядит как гибрид TLS для обмена ключами и проприетарный протокол шифрования пакетов на основе UDP.

Ответ 2

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

Ответ 3

Этот вопрос немного стар, но как насчет использования подхода One Time Pad? Вы можете использовать безопасный надежный механизм транспорта (например, HTTPS) для передачи одноразовых ключей с сервера на ваш клиент. Могут быть два набора ключей - один для клиента для разрыва и один для сервера для клиента. Каждая датаграмма будет включать в себя порядковый номер (используемый для идентификации ключа времени), а затем зашифрованное сообщение. Поскольку каждый ключ используется только для одной дейтаграммы, вы не должны подвергаться небольшой проблеме с данными. Тем не менее, я не эксперт в этом, так что обязательно проверьте эту идею, прежде чем использовать ее...

Ответ 4

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

Aes cbc вам не поможет; сообщения слишком короткие, и вы хотите предотвратить повторные атаки. Поместите свое 64-битное сообщение (два целых числа) с помощью счетчика (начиная с 0). 64 бита означают, что можно отправить 2 ^ 64 сообщения. Зашифруйте блок дважды (aes ecb) и отправьте e (k; m | count) | e (k; e (k; m | count)). Приемник принимает только монотонно увеличивающиеся подсчеты, когда вторым блоком является шифрование первого. Это 32-байтовые сообщения, которые отлично вписываются в пакет udp.

если 2 ^ 64 сообщения слишком малы; посмотрите, может ли ваше сообщение быть меньше (3 байтовых целых числа означает, что счетчик может составлять 80 бит); или вернитесь к шагу 1 (новые закрытые ключи для хотя бы одной стороны), как только вы приблизитесь (скажем 2 ^ 64-2 ^ 32) до предела.