Ваш вопрос почти наверняка ошибочен. Обычно вы не хотите шифровать сообщения от одного пользователя другому на сервере и почти никогда не хотите расшифровывать их на сервере.
Во-первых, весь смысл шифрования с открытым ключом заключается в том, что никто, кроме пользователя и его собственного доверенного программного обеспечения, не имеет доступа к его личному ключу.
Вы не хотите хранить личные ключи пользователей на сервере - это будет означать, что если ваш сервер будет взломан или какой-то недовольный сотрудник захочет саботировать вашу компанию, он сможет расшифровать любое сообщение в мире. Большинство пользователей не будут доверять такой системе, и они не должны.
Таким образом, вы должны выполнить расшифровку на клиенте принимающего пользователя, где его личный ключ доступен.
Обычно вы также хотите выполнить шифрование на клиенте отправляющего пользователя. В противном случае каждое сообщение отправляется в виде открытого текста на сервер, где хакер (или недобросовестная серверная компания) может легко украсть его до того, как оно будет зашифровано. Опять же, пользователи не будут и не должны доверять такой конструкции.
Это означает, что отправляющему клиенту, конечно же, нужен открытый ключ получателя. Но этим легко управлять: вы храните открытый ключ каждого на сервере и добавляете команду, которую отправляющий клиент может использовать для получения открытого ключа получателя.
В некоторых проектах вы хотите вместо этого использовать отдельный внеполосный механизм для совместного использования открытых ключей. Например, если вы используете GPG и хотите полагаться на его сеть доверия вместо того, чтобы использовать сервер для управления доверием к удостоверениям, вы бы дали клиенту возможность импортировать открытые ключи и хранить их, либо дать ему возможность взаимодействовать с существующим хранилищем ключей.
Если вы действительно хотите полностью зашифровать PK на сервере, вы можете . Это просто не дает особого преимущества для безопасности.
Для этого вы можете сохранить личный ключ каждого пользователя в базе данных. Затем вы просто получаете зашифрованное сообщение и закрытый ключ и расшифровываете его перед отправкой. Тогда открытый текст доступен только в некотором кратковременном буфере памяти, а не в базе данных. Но обратите внимание, что это не лучше, чем просто не шифровать вещи вообще. Конечно, любой, кто может получить доступ к вашей базе данных, не может напрямую получить расшифрованные сообщения, но он может получить зашифрованные сообщения и ключи, необходимые для их расшифровки, что также хорошо. На самом деле это лучше для злоумышленника, потому что теперь они могут расшифровывать другие сообщения, используя тот же закрытый ключ, подписывать сообщения, выдавать себя за пользователя и т. Д.
Кроме того, пользователь может отправить закрытый ключ всякий раз, когда он хочет получить сообщение. Затем вы извлекаете зашифрованное сообщение из базы данных, расшифровываете его с помощью закрытого ключа и отправляете его пользователю. Теперь и закрытый ключ, и открытый текст живут только во временной памяти. Но это все еще добавляет почти ничего к не шифрованию вообще. Сообщения - и, что еще хуже, закрытые ключи - передаются в виде открытого текста через открытый интернет. Кроме того, любой, кто может взломать ваш сервер, не может извлечь приватные ключи из вашей базы данных, но он может просто сохранить их по мере их поступления.