Эфемерный ключ RSA против эфемерного ключа DH?

Question

Эфемерный ключ RSA против эфемерного ключа DH?

1

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

В современных системах используется SSL для передачи ключей и данных, которые не хранятся загадочно. В дизайне SSL/TLS ключ сеанса создается двумя способами;

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

Когда дело доходит до моего случая, есть два варианта.

Первый случай;

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

Второй случай;

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

Какой вариант подходит для моего сценария? Каковы плюсы и минусы каждого случая?

Спасибо за ответы.

ersan 26 май 2014, в 23:48

Источник

Теги:

java

encryption

security

ssl

applet

1 ответ

Ещё вопросы

Remi Gacogne · Answer 1 · 2014-05-27T10-08-00.000Z

Оба решения уязвимы для активного злоумышленника, в положении "человек в середине", потому что обмен ключами не аутентифицирован. Эта проблема решается в протоколе SSL/TLS с использованием PKI X.509. Это также можно решить, предоставив вашему клиенту предварительное знание открытого ключа сервера, например. При этом, между двумя вашими вариантами, переходите к (EC) DHE, потому что генерация нового ключа DH из предварительно вычисленной группы DH (также известной как параметры DH) выполняется быстро, тогда как генерация нового ключа RSA происходит очень медленно.

Во-первых, спасибо за ответ. Я хочу контролировать (знать), кто подключается к серверу, чтобы я создал сертификат X.509 и импортировал его в апплеты. Если я использую (EC), DHE-сервер и клиент должны создать пару ключей, а сервер должен создать шифрованный и зашифрованный сеансовый ключ. Это очень дорого?
Да, использование DHE очень сильно загружает процессор, но все же меньше, чем генерация нового RSA для каждого соединения. Вы хотите избежать этого, несмотря ни на что. ECDHE действительно быстро. Вы можете увидеть тесты, выполненные Винсентом Бернатом здесь: vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html