При шифровании файла для отправки его соавтору я вижу следующее сообщение:
gpg: using subkey XXXX instead of primary key YYYY
Почему это могло быть? Я заметил, что, когда они отправляют мне зашифрованный файл, он также кажется зашифрованным в отношении моего подраздела, а не моего первичного ключа. Для меня это не проблема; gpg (1.4.x, macosx) просто обрабатывает его и продолжает работу. Но для них, с их автоматической настройкой инструментов, это кажется проблемой, и они попросили меня обязательно использовать их первичный ключ.
Я попытался немного почитать, и у меня есть заказ на книгу Майкла Лукаса «GPG & PGP», но я не понимаю, почему это различие. я иметь прочитал, что ключ, используемый для подписи, и ключ, используемый для шифрования, будут разными, но я предположил, что сначала речь шла об открытых и закрытых ключах.
В случае, если это была проблема с доверием / проверкой, я прошел через процесс сравнения отпечатков пальцев и проверки, да, я доверяю этому ключу. Пока я делал это, я заметил, что у основных & подключей были разные примечания по "использованию":
primary: usage: SCA
subkey: usage: E
«E», вероятно, означает «шифрование». Но мне не удалось найти никакой документации по этому поводу. Более того, мой соавтор уже несколько лет использует эти инструменты и методы, так почему это может быть проблемой только для меня?
Хотя исходный пост ниже правильно объясняет, почему вы можете захотеть использовать отдельные ключи шифрования и подписи, он не дает хорошего ответа на вопрос, почему вы используете подключи вместо первичного ключа. Debian Wiki предоставляет гораздо более подробный ответ.
Подводя итог, ваш первичный ключ - это ваша онлайн-личность, а ваша личность и репутация создаются тем, что другие люди ручаются за то, что этот ключ является вашим, подписывая его сами. (Вы можете думать об этом, как о своей репутации в Твиттере, а ваша репутация - как о ваших подписчиках в Твиттере, или вы можете возразить против этой аналогии, но я надеюсь, что это дает вам некоторое представление о том, почему вы хотите ее защищать.) Итак, поскольку ваш основной ключ очень важен и накапливается годами, вы очень хотите его защитить. В частности, вы не хотите хранить его на компьютере, который может быть украден или взломан; вы хотите, чтобы ваш первичный ключ был отключен в надежном месте.
Это, конечно, делает ваш первичный ключ очень неудобным в использовании. Поэтому для повседневных операций вы хотите использовать ключ, который не представляет такой большой проблемы, чтобы заменить его, если он будет взломан. Вот почему были изобретены подключи.
Подключ по-прежнему является парой открытого / закрытого ключей и является безопасным, если только у вас есть закрытый ключ. С криптографической точки зрения он так же безопасен, как и ваш первичный ключ. Разница в том, что ваша репутация привязана к ней только вашей собственной подписью, подписью вашего закрытого ключа. Если использовать аналогию с Твиттером, мир верит, что вы являетесь вашим дескриптором Твиттера, потому что так говорят все ваши подписчики (я знаю, на самом деле это не всегда так, но аналогии сложны!), А затем, установив это доверие, вы можете тогда гораздо легче убедить мир, что вы являетесь владельцем своего аккаунта в Instagram, просто написав об этом в Твиттере, и люди поверят вам, потому что твит пришел из вашей учетной записи, которой они доверяют.
Вы по-прежнему хотите сохранить свой подключ в безопасности, но теперь, если он скомпрометирован, это не большая проблема, как если бы ваш первичный ключ был скомпрометирован (или, по аналогии, кто-то взломал вашу учетную запись Twitter). Теперь вы можете просто отозвать подключ и выдать новый, подписав сертификат отзыва и новый подключ и разместив их в своей связке открытых ключей (например, твиттер: «Эй, мой дескриптор Instagram изменился, не используйте старый, используйте это один вместо "). Это делает хранение подраздела на портативном компьютере более приемлемым риском, чем хранение на нем первичного ключа.
TL; DR Подключи значительно упрощают управление ключами, отделяя криптографические функции открытых ключей от функций доверия и идентификации (первичных) открытых ключей.
Если вы изучите детали математики шифрования с открытым ключом, вы обнаружите, что подписание и дешифрование на самом деле являются идентичными операциями. Таким образом, в наивной реализации можно обманом заставить кого-нибудь расшифровать сообщение, попросив его подписать его.
Чтобы избежать этого, на практике делается несколько вещей. Наиболее очевидным является то, что вы никогда не подписываете фактическое сообщение, вместо этого вы подписываете безопасный хэш сообщения. Менее очевидно, но для большей безопасности вы используете разные ключи для подписи и шифрования. Кроме того, хранение отдельного ключа шифрования позволяет хранить другие, возможно, более важные и определенно менее часто используемые ключи в автономном режиме и в большей безопасности. Так обстоит дело с ключами, которые вы проверили. Кстати флаги означают:
Обратите внимание, что во всех случаях «ключ» означает пару открытого и закрытого ключей.
Это не должно быть проблемой для вашего друга, если у него все настроено правильно, но правильно настроить все может быть сложнее, чем следовало бы. Так что, возможно, лучшим решением для вашего друга будет создание нового открытого ключа, который он использует как для подписи, так и для шифрования. Как я уже сказал, поскольку основная защита от атаки состоит в том, чтобы подписать только криптографически безопасный хэш сообщения, наличие такого ключа не является серьезным недостатком.
В остальном я вряд ли сильно помогу. Я всегда считал PGP / GPG слишком сложным из-за того, чего мало что он дает. Удачи.