Comment importer une clé RSA SSH dans GPG en tant que clé privée _primary_?

16

J'ai actuellement une clé SSH que j'utilise depuis un moment et je voudrais commencer à utiliser GnuPG avec un nouveau trousseau de clés. Cependant, étant donné que j'utilise ma clé depuis des lustres, j'aimerais toujours utiliser cette clé dans GPG comme clé principale / principale. J'ai essayé d'importer la clé via ces instructions .

Mais je me retrouve avec ce qui est considéré comme une "sous-clé". De plus, si j'essaie de l'importer sans créer de clé GPG standard, GPG ne voit même pas cette sous-clé. (Je suppose que la sous-clé doit d'abord être signée par la clé principale.)

Comment utiliser cette clé comme clé principale dans secring.gpg?

Brendan Byrd
la source
Dans quel sens voulez-vous dire " clé privée _principale_ "?
MadHatter

Réponses:

16

La réponse simple est: vous ne le faites pas.

Les clés SSH et les clés GnuPG (en fait, OpenPGP) sont complètement différentes, même si les deux protocoles peuvent utiliser des paires de clés RSA.

Et d'ailleurs, pourquoi voudriez-vous le faire? Même si vous deviez utiliser le même matériel de clé pour composer votre clé PGP, vous auriez toujours besoin de distribuer votre clé en tant que clé PGP. Vous n'avez probablement pas distribué votre clé publique SSH aux personnes avec lesquelles vous correspondez, donc d'un point de vue de la distribution de clés, il n'y a pas de différence: ils devront recevoir une clé publique de votre part. Et même si vous avez distribué votre clé publique SSH à d'autres personnes, elles devraient prendre des mesures supplémentaires pour pouvoir l'importer dans leur implémentation OpenPGP, ce qui peut ou non être facile.

Comme kasperd l'a très justement souligné, il ne doit y avoir qu'une seule façon d'interpréter (en particulier) une signature. Si vous deviez utiliser la même clé pour PGP et SSH, si quelqu'un pouvait vous inciter à signer un message spécialement conçu (qui est une capacité supposée dans certaines attaques de système de signature) en une seule, alors même si les deux systèmes sont sécurisés isolément, il il pourrait être possible d'élaborer un tel message d'une manière qui a une signification dans l'un des systèmes, mais une signification différente dans l'autre. Ce serait en soi une vulnérabilité. (Exploitable? Qui sait. Mais pourquoi prendre le risque?)

Les paires de clés PGP et SSH sont des clés à long terme, qui sont utilisées pour sécuriser les clés symétriques éphémères (message et session), ainsi que pour vérifier l'authenticité d'une partie distante. Cela fait de la clé privée PGP ou SSH une cible de valeur beaucoup plus élevée pour un attaquant que la clé symétrique correspondante. Si vous utilisez le même matériau de clé pour les deux, et qu'un attaquant est en mesure de le réaliser, cela ne fait qu'augmenter la valeur d'une attaque réussie sur cette paire de clés.

Sans avoir examiné l'un ou l'autre protocole en détail, j'imagine que reconnaître que le même matériel de clé est utilisé dans les deux serait probablement assez trivial, car la clé publique est essentiellement transmise en clair.

Générez simplement une nouvelle clé PGP. Si vous le souhaitez, faites-le RSA et de la même longueur que votre clé SSH. (Aucune personne sensée ne va y regarder de plus près que de vérifier l'empreinte digitale de toute façon.) Ensuite, distribuez la clé publique aux personnes avec lesquelles vous souhaitez correspondre, en tant que clé PGP. Ce sera beaucoup plus facile pour tout le monde, et très probablement plus sûr, au prix d'une petite quantité d'entropie du pool d'entropie aléatoire de votre système qui devrait être rapidement réapprovisionné de toute façon.


Si vous avez plusieurs clés sur votre trousseau de clés secret et que vous souhaitez spécifier celle qui doit être utilisée par défaut, utilisez les directives default-keyet éventuellement default-recipient{,-self}dans votre ~ / .gnupg / gnupg.conf.

un CVn
la source
1
Je suis d'accord avec cette réponse. Cependant, il y a une raison de plus de ne pas utiliser le même matériau clé. Pour des raisons de sécurité, il ne doit y avoir qu'une seule façon d'interpréter une signature. Si la même signature pouvait être interprétée de deux manières différentes, ce serait une vulnérabilité. Même si ssh et gpg sont sécurisés par eux-mêmes, un adversaire peut vous inciter à signer un message avec l'un, puis à prendre la signature dans l'autre programme, où il pourrait avoir une signification différente.
kasperd
@kasperd Bon point. J'ai modifié la réponse; Comment vous sentez-vous à ce sujet maintenant?
un CV
Ça sonne bien.
kasperd
1
Je pense que cette réponse n'est pas complètement exacte: avec monkeysphere, il existe un cas d'utilisation où vous voudrez peut-être des clés OpenSSH existantes en tant que sous-clés d'authentification uniquement dans votre clé OpenPGP personnelle. Au moins, je voudrais l'utiliser de cette façon.
user134450
Ces clés ne sont pas du tout différentes; leurs métadonnées sont.
foo
5

Vous pouvez convertir une clé SSH en clé OpenPGP avec l'outil pem2openpgpdu projet monkeysphere . Cette clé peut ensuite être importée par gnupg en tant que paire de clés privée / publique régulière. Comme l'autre réponse mentionne que ce n'est généralement pas une bonne idée car ssh n'a pas de concept de certificats, vous ajoutez donc effectivement une capacité à une clé existante qu'elle ne pouvait pas avoir auparavant. Il s'agit généralement d'une interdiction de cryptographie.

Je l'ai quand même fait avec une de mes clés ssh mais j'ai ajouté la paire de clés à mon autre clé OpenPGP en tant que sous-clé qui n'a qu'un seul indicateur de capacité: l'authentification. Cet indicateur est destiné à des situations comme celle-ci, où vous ne voulez pas signer ou chiffrer quoi que ce soit avec une paire de clés (signification --encryptet --signoptions pour gnupg) mais vous voulez l'avoir dans votre boîte à clés pour l'authentification avec OpenSSH et l'agent gnupg de toute façon.

Pour plus de détails, consultez la documentation de monkeysphere.

user134450
la source
2

Il peut y avoir de bonnes raisons de convertir une clé au format PKCS standard pour l'importation en gpg.

Par exemple, si vous souhaitez le mettre sur une carte à puce. Les fonctionnalités fournies par gpg avec ses informations de carte et ses commandes d'édition de carte sont très utiles à cet effet, alors pourquoi ne pas l'utiliser comme outil? Le seul obstacle à surmonter est ... exactement: importer la clé du format PKCS # 8 standard (ou format "raw" RSA PKCS # 1) dans le magasin de clés gpg pour un traitement ultérieur.

Alors - notez mon objection à la réponse approuvée! :)

Une réponse réellement utile à ce type de question se trouve ici: /unix/276317/how-can-i-import-a-key-in-pem-format-not-openpgp-into -gpg

foo
la source
1

Utilisez-le sur Ubuntu 16.04 ou Windows WSL.

sudo apt install -y monkeysphere
cat key.pem | PEM2OPENPGP_USAGE_FLAGS=authenticate pem2openpgp "Key <[email protected]>" > key.pgp

Importer une carte. Peut être fait sur Windows ou Linux.

gpg --import key.gpg

Déplacer vers la carte

Recherchez l'identifiant de signature de clé.

gpg --list-key

Déplacer la clé d'authentification sur la carte

gpg --edit-key FFFFFFFFFFF
keytocard

Sélectionnez un numéro pour l'emplacement d'authentification.

Vous avez terminé ici.

N'oubliez pas de supprimer la clé du trousseau gpg si vous utilisez une carte. Utilisez l'identifiant de clé ci-dessus.

gpg --delete-secret-key FFFFFFFFFFF

Divers

Pas nécessaire mais peut être utile pour obtenir une clé au format pgp basé sur du texte.

gpg -a --export FFFFFF > key.asc
Feu
la source