Сложная модель шифрования / дешифрования - возможно ли это?

Question

Предположим, у меня есть сервер, который публикует информацию (например, через шину сообщений) четырем сторонам: A, B, C и D. Любой участник может обнаружить весь трафик в зашифрованном виде.Чтобы использовать эту информацию, очевидно, что ее необходимо будет расшифровать:

• Сторона А должна иметь возможность считывать всю информацию (т.е. дешифровать информацию, предназначенную для А, В и С)
• Сторона B должна иметь возможность считывать информацию, предназначенную для B и C
• Сторона C должна иметь возможность считывать только информацию, предназначенную для стороны C
• Сторона D должна иметь возможность считывать информацию дляB и D

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

Есть ли лучший способ?

РЕДАКТИРОВАТЬ

По сути, я хотел бы, чтобы у каждого человека был свой закрытый ключ, а при шифровании сообщения я должен сказать, что этозашифрован с помощью key = A | B | C, так что это означает, что человек с любым из ключей A, B или C может расшифровать его.Представьте себе сундук, к которому могут быть прикреплены n замки, любой из которых может открыть сундук.

Answer 1

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

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

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

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

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

Ни один из укладчиков полки, менеджеров по запасам, менеджеров секций или менеджеров магазинов не получитлюбая подсказка о криптографии с открытым / закрытым ключом

Ну, их программное обеспечение / устройство справится с этим.

Answer 2

То, что вы хотите, может быть достигнуто с помощью обычных протоколов, основанных на криптографии с открытым ключом. API шифрования Bouncy Castle имеет поддержку OpenPGP и CMS , каждый из которых может работать из Scala.

Чтобы настроить все:

• Каждой стороне дается пара открытых / закрытых ключей.
  
  • Никто НИКОГДА не разделяет закрытый ключ.Закрытый ключ должен оставаться закрытым
• Каждая сторона знает открытый ключ каждой другой стороны

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

У API много нюансов, но модульные тесты и примеры действительно помогут вам с ними ориентироваться.

Детали реализации

Оба протокола работают в основномтаким же образом.

1. Надежно сгенерируйте случайный симметричный ключ
2. Для каждого получателя зашифруйте симметричный ключ открытым ключом получателя.Все зашифрованные открытые ключи записываются в заголовок сообщения.
3. Шифрование сообщения с использованием симметричного ключа.Это становится содержимым сообщения.

Получатели переворачивают процесс для расшифровки сообщения

1. Поиск заголовка сообщения для ключа, адресованного самому себе.
2. Использование личного ключарасшифровать симметричный ключ.
3. Используйте симметричный ключ для расшифровки содержимого сообщения.

Answer 3

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

Предполагая, что общая форма вашей проблемы:

• Существует n сторон, пронумерованных от p_1 до p_n
• Сообщения имеют уровень безопасности m, так что только стороны от p_1 до p_m могут дешифровать сообщение.

Вы можете использовать этот обмен ключамишаг:

• Генерируйте n ключей AES, пронумерованных от k_1 до k_n.
• Надежно передайте каждый ключ k_i всем сторонам от p_1 до p_i.

Затем дляотправьте сообщение с уровнем безопасности m, просто зашифруйте его ключом k_m.

Одним из побочных эффектов этой схемы является то, что сторона p_b не имеет возможности помешать стороне p_a дешифровать сообщения, которые она отправляет, если <б.Надеюсь, все в порядке. </p>

Answer 4

Можете ли вы использовать пользовательское шифрование, как Blowfish?В таком случае вы можете поделиться ключом шифрования Blowfish и сохранить его, скажем, в файле свойств!Когда данные поступают, в зависимости от места назначения и значения ключа в файле свойств вы можете попробовать расшифровать их