Асимметричное шифрование для более двух получателей?

Question

Я хочу создать приложение, в котором несколько человек должны надежно общаться друг с другом (подумайте о децентрализованном групповом чате) - звучит просто, но вот моя проблема:

Насколько я понял, с асимметричное шифрование у вас есть открытый ключ и закрытый ключ. Каждый, кто хочет отправить сообщение кому-то, должен зашифровать его открытым ключом, а получатель может расшифровать его с помощью закрытого ключа.
Но если есть более двух человек, которые должны иметь возможность читать все сообщения, я не знаю, как это должно работать ... Либо у каждого есть общественность и закрытый ключ, который, я думаю, плохая идея - или каждый должен иметь открытый ключ everybodys и должен отправлять отдельное сообщение каждому получателю.
Кроме того, я хочу сделать 100% уверенным, что тот, кто действительно посылает сообщение, является тем, кем он себя притворяется. (так что никто не может «подделывать» сообщения)

Есть ли алгоритм шифрования, который решает мою проблему?

Answer 1

Предполагаю, вы имеете в виду асимметричное шифрование, а не асинхронное шифрование.

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

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

"recip1|recip1EncryptedSessionKey|recip2|recip2EncryptesSessionKey..." 

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

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

Обратите внимание, что как и во всех аспектах шифрования, имеет решающее значение, что ключ сеанса действительно случайный. Не просто полагайтесь на простой генератор случайных чисел ванили для этого, и ради небес ради не сворачивайте свои собственные. Убедитесь, что вы используете cryptographically secure pseudorandom number generator.

Настоящая чат-система, скорее всего, будет довольно сложной, возможно, с механизмом повторного установления нового сеансового ключа, а детали защищенного протокола могут быть довольно сложными. I.e., подумайте, как вы защитите себя от плохого парня, входящего и обманывающего всех, используя ключ сеанса по его выбору! Но основы такие, как указано выше.

Answer 2

Управление удлинять группы получателей

В a comment к Richard Schwartz' good answer, спросите вы

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

При применении протокола в сценарии группового чата не допускайте, чтобы термин «сеансовый ключ» вводил вас в заблуждение. Скорее, подумайте о ключе для симметричного шифрования как «ключа сообщения»: каждый раз, когда кто-то отправляет сообщение группе, они должны генерировать новый случайный симметричный ключ, шифровать его с помощью открытого ключа каждого законного получателя отдельно и доводить все эти криптограммы до симметрично зашифрованное сообщение. Таким образом, каждый отправитель самостоятельно решает, кого они считают частью группы получателей из своих собственных отправленных сообщений.

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

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

Обеспечение аутентичности

В редактировании к исходному вопросу, вы добавили

Кроме того, я хочу, чтобы сделать 100% уверен, что тот, кто посылает сообщение на самом деле, кто он притворяется быть. (Так что никто не может «поддельные» сообщения)

Шифрование не может сделать это, но криптография имеет другой способ, чтобы убедиться, что

• сообщение на самом деле исходит от которого утверждал, что послал его
• сообщение не было изменено, так как

И путь обеспечения этих вещей подписей, которые также являются то, что общественно-пр Криптография ivate-key позволяет. Пусть отправители подписывают свои сообщения своим личным ключом. (Что обычно означает «шифрование» криптографически защищенного хеша сообщения с закрытым ключом.) И пусть получатели проверяют подписи (путем «дешифрования» подписи открытым ключом отправителя и сравнения результата с хешем сообщения, которое они вычисляли сами по себе.)

не свернуть свое собственное ничего (кроме случаев, когда вы должны)

ответов Ричарда советов вам не свернуть свой собственный (псевдо) генератор случайных чисел.Для всего, что вы собираетесь использовать в производстве, я бы продлить это ничего шифрование:

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

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

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

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