Обновление

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

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

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

Подключ по-прежнему является парой открытого и закрытого ключей и является безопасным, если только у вас есть закрытый ключ. С криптографической точки зрения он так же безопасен, как и ваш первичный ключ. Разница в том, что ваша репутация привязана к ней только вашей собственной подписью, подписью вашего закрытого ключа. Если использовать аналогию с Twitter, мир доверяет вам, потому что все ваши подписчики так говорят (я знаю, что на самом деле это не всегда так, но аналогии сложны!), А затем, установив это доверие, вы можете тогда гораздо легче убедить мир, что вы являетесь владельцем своего аккаунта в Instagram, просто написав об этом в Твиттере, и люди поверят вам, потому что твит пришел из вашей учетной записи, которой они доверяют.

Вы по-прежнему хотите сохранить свой подключ в безопасности, но теперь, если он будет скомпрометирован, это не большая проблема, как если бы ваш первичный ключ был скомпрометирован (или, по аналогии, кто-то захватил вашу учетную запись Twitter). Теперь вы можете просто отозвать подключ и выдать новый, подписав сертификат отзыва и новый подключ и разместив их в своей связке открытых ключей (например, твиттер: «Эй, мой дескриптор Instagram изменился, не используйте старый, используйте это один вместо "). Это делает хранение подраздела на портативном компьютере более приемлемым риском, чем хранение на нем первичного ключа.

TL; DR Подключи значительно упрощают управление ключами, отделяя криптографические функции открытых ключей от функций доверия и идентификации (первичных) открытых ключей.

Исходное сообщение

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

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

• e = зашифровать / расшифровать (расшифровать полученное сообщение в зашифрованном виде, чтобы вы могли его прочесть)
• s = подписать (подписать данные. Например, файл или отправить подписанное электронное письмо)
• c = certify (подписать другой ключ, устанавливающий доверительные отношения)
• a = аутентификация (вход в SSH с помощью ключа PGP; это относительно новое использование)

Обратите внимание, что во всех случаях «ключ» означает открытый и закрытый ключ пара.

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