Безопасный способ отправки открытого ключа через сокет

Как безопасно отправить RSA::PublicKey другому пользователю через сокет? Я думал экспортировать ключ в ByteQueue и отправить массив байтов пользователю, где он может снова создать открытый ключ.

Или это утечка информации, которая может быть использована не по назначению?

//Generate keys
AutoSeededRandomPool rng;

InvertibleRSAFunction params;
params.GenerateRandomWithKeySize(rng, 3072);

//Create
RSA::PublicKey publicKey(params);

//Save
ByteQueue queue;
publicKey.Save(queue);

byte publicKeyBuffer[1000];
size_t size = queue.Get((byte*)&publicKeyBuffer, sizeof(publicKeyBuffer));

//Load
RSA::PublicKey loadkey;
ByteQueue queue2;
queue2.Put2((byte *)&publicKeyBuffer, size, 0, true);

loadkey.Load(queue2);

rsa cryptography crypto++
person Dagob    schedule 06.11.2013    source источник
comment
Насколько я понимаю, публичные ключи называются публичными не просто так. Вы можете смело отправлять их, публиковать и т. д., для этого они и нужны.   -  person bereal    schedule 06.11.2013
comment
Как говорит bereal, открытые ключи являются открытыми. Но проблема в том, что злоумышленник-посредник может отправить клиенту собственный открытый ключ, полностью разрушив схему. Здесь обсуждается проблема: blogs.msdn.com/b/ericlippert/archive/2011/09/27/   -  person ntoskrnl    schedule 06.11.2013

Ответы (1)


arrow_upward
5
arrow_downward

Как безопасно отправить RSA::PublicKey другому пользователю через сокет?

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

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

Есть два способа решить проблему распределения ключей: корень доверия и сеть доверия. Корень доверия используется в PKI с публичными и частными центрами сертификации; в то время как сеть доверия используется PGP и ее друзьями.

Распространение ключей «решается» с разной степенью успеха в Интернете с помощью PKI и общедоступных центров сертификации. См., например, RFC 5280, Internet X.509 Сертификат инфраструктуры открытых ключей и список отзыва сертификатов (CRL ) Профиль, как это должно работать; и см. статью Питера Гутманна Техническая безопасность о том, как это не удается на практике (иногда впечатляющим образом).

Для одноранговых приложений, которые не используют «корень доверия» или PKI, последняя тенденция заключается в том, чтобы (1) использовать Short Authentication String (SAS) с начальным сообщением и (2) привязать все последующие сеансы к прошлым сеансам (по сути, формируя цепочку из первого сессия). Во время исходного сообщения получатель проверяет ключ открытого ключа от отправителя с помощью голоса, считывая небольшой дайджест, например отпечаток открытого ключа (голос — отличный механизм аутентификации).

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

экспортировать ключ в ByteQueue и отправить массив байтов

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

Также обратите внимание, что конфиденциальность может вызывать беспокойство, как у людей, которые являются диссидентами в угнетенной стране. Диссиденты и репрессивные режимы — не единственный вариант использования, и это может быть проблемой для сертификации и аккредитации (C&A ) тоже.

Однажды я провалил проверку в Федеральном органе США, потому что слил адрес электронной почты. В этом случае адрес электронной почты был в сертификате пользователя вместе с ключом. (Все, что делает сертификат, это привязывает открытый ключ к личности через подпись «авторитета» над обоими).

person jww    schedule 10.01.2014