Защитить открытый ключ RSA во время транспортировки

* Уточнение: Мой вопрос связан с настройкой «безопасного» канала связи между двумя сторонами, где ключ (считывание кодовой фразы) был согласован в реальном мире. Только использование RSA допускает MITM-атаки (если я не ошибаюсь), поэтому я думал об шифровании открытых ключей с AES (ключ, который был согласован), прежде чем отправлять их соответствующим сторонам *Защитить открытый ключ RSA во время транспортировки

I ' m в настоящее время пытается построить два приложения, которые говорят с eachother. Чтобы обеспечить обменянные сообщения, я думал об использовании RSA, где каждое приложение имеет собственный набор ключей.

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

Я знаю, что означает слово public (как в открытом ключе), но я думал, что это увидит, что правильное приложение/компьютер получает ключ и никто другой.

Поэтому я хочу обменять ключи и защитить их от атак MITM.

Если кто-нибудь может дать лучшее предложение (я использую библиотеку LibCrypto btw), я все уши.

спасибо.

С наилучшими пожеланиями /Tomas Густавссон

источник

2011-12-29 tomplast

Почему вы идете на асимметричное шифрование, если у вас уже есть предустановленный симметричный секретный ключ? Для этого вам понадобится способ создания ключей сеанса AES, предпочтительно тот, который не уязвим для атак MITM и не подвергает ваш главный ключ опасности. Но я думаю, что это неправильный форум для этого, попробуйте crypto.stackexchange.com –

О, и кодовая фраза не является ключом. Он может быть преобразован * в * ключ, например. используя функцию вывода на основе пароля, такую как PBKDF2, но это не то же самое. Например, использование вашего пароля в качестве ключа может привести к связанным с ним ключевым атакам. –

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

Этот вопрос показывает много неправильных представлений со своей стороны.

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

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

Эта проблема решается при типичной установке сертификатами, подписанными доверенным органом и выданной конкретному объекту, то есть IP или DNS-имя.

В вашем случае вы не указали никаких сведений о своих сертификатах.

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

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

источник

2011-12-29 11:48:32 Cratylus

В Интернете нет уверенности, что я знаю. Но если обе стороны согласились на AES-ключ (возможно, в баре, в торговом центре или в некоторых других местах реальной жизни), они используют этот ключ шифрования для шифрования и дешифрования открытого ключа eachothers, который они отправляют друг другу. Если злоумышленник не знает ключа AES, он, возможно, не может отправить мне открытый ключ, который я буду принимать (поскольку он не может быть расшифрован и проверен как действительный открытый ключ). Разве это не так? – tomplast

@ tomplast: В этом случае они могли бы легко обменять свои открытые ключи, а также избежать чрезмерных затрат на шифрование AES. Обратите внимание, что приведенный ниже пример относится к моему более универсальному: «manuall pre-installation», упомянутый в моем ответе – Cratylus

Извините, я думаю, мне нужно быть более конкретным. Эти два приложения на самом деле являются двумя людьми, обменивающимися текстовыми сообщениями. Они не могут доверять третьей стороне, и их единственным средством доверия является AES-ключ, который они согласовали в реальном мире. Каждый сеанс, начинающийся между двумя сторонами, должен каждый раз использовать новые сгенерированные ключи, и это включает их согласованный ключ AES (возможно, LaDo34MooMooTakida $ или еще более сложный способ угадать пароль). Поэтому обе стороны должны иметь возможность общаться «безопасно», не рискуя атакой MITM. – tomplast

Защитить открытый ключ RSA во время транспортировки

ответ

Смежные вопросы