Hello,
Je me permets d'écrire ce journal tel un mémo technique sur mon utilisation relativement basique de GPG, mais également comme un appel à la correction de ce que je n'aurais pas ou mal compris.
J'ai personnellement découvert GPG lors de ma fin d'étude (encore relativement proche), avec le logiciel pass. En effet pass nécessite l'utilisation d'une clef GPG pour le chiffrement de ses données. A l'époque j'étais tombé sur l'article de alexcabal que j'avais jugé pertinent et que j'avais suivi plus ou moins à la lettre sans plus de réflexion.
Un certain temps plus tard, j'ai souhaité revoir mon usage complètement casual de Git, et en souhaitant m'améliorer sur ce sujet, j'ai découvert le principe de signature de commit par clef GPG. J'ai donc décidé de créer une nouvelle clef GPG
afin de l'utiliser en tant que signature sur mes projets pro, et encore une autre clef pour mes projets perso (oui, on va en reparler de ces clefs).
Bref, me voici quelques années plus tard sans avoir véritablement réutilisé GPG, sur le point de quitter mon entreprise pour une autre. Et c'est donc logiquement qu'il va me falloir générer une nouvelle clef pour mon nouvel emploi, mais également une seconde pour mon nouvel email personnel (au revoir Google).
Pour me dépoussiérer un peu sur le sujet je me rends en premier lieu sur linuxfr.org (mais pas que), je fouille un peu et je dévore tous les articles suivants :
GPG en large en long en travers sur linuxfr.org :
- https://linuxfr.org/news/bien-demarrer-avec-gnupg
- https://linuxfr.org/users/gouttegd/journaux/de-la-gestion-des-clefs-openpgp
- https://linuxfr.org/news/gpg-les-concepts-en-clair-et-pedagogiquement
Ces trois articles à eux seuls sont une mine d'or qui m'ont énormément éclaircie ma lanterne, et je recommande d'ailleurs de lire les commentaires de ces trois articles qui fourmillent de questions et de remarques pertinentes.
La signature de commit sur git-scm/github/gitlab :
- https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
- https://docs.github.com/en/github/authenticating-to-github/generating-a-new-gpg-key
- https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/
Et enfin plusieurs articles sur les best-practices et notamment l'utilisation des Subkeys :
- https://wiki.debian.org/subkeys
- https://gist.github.com/Integralist/f7e17034800b65b51eb7e9807720025a
- https://blog.eleven-labs.com/en/openpgp-almost-perfect-key-pair-part-1/
- https://gist.github.com/Integralist/f7e17034800b65b51eb7e9807720025a
Après avoir lu ce contenu, je suis resté cependant perplexe sur certains détails, et notamment ce concept de trust et d'identité, je ne comprenais pas comment gérer aussi facilement plusieurs identités avec plusieurs clefs qui évoluent au cours de la vie. Long story short, je suis finalement tombé sur l'article de Bortzmeyer dans un commentaire, qui parle justement des identités. Il semble que j'étais à côté de la plaque pendant plusieurs années.
Donc après avoir fait le ménage dans mon ~/.gnupg je me retrouve avec une seule clef principale contenant toutes mes identités, et je (pense?) avoir maintenant compris les bases de GnuPG. Prochaine étape, les mails chiffrés :)
Ah non j'allais oublier un problème ! J'ai eu un mal fou pour changer la clef utilisée pour pass, et n'obtenais que des
gpg: 878AED67: skipped: Unusable public key
Jusqu'à ce que je tombe sur le mot clef usage:
gpg --edit-key --expert name@domain.tld
sec ed25519/0xABC1234567890
created: 2021-05-10 expires: 2023-05-10 usage: SC
trust: ultimate validity: ultimate
ssb ed25519/0x0987654321DEF
created: 2021-05-10 expires: 2023-05-10 usage: S
J'ai rapidement fait le lien avec SC = sign capability et S = sign only. Et je me suis rendu compte qu'il me manquait donc une clef de Chiffrement (usage: E pour Encrypt). Je n'ai pas vérifié cela plus tôt car j'avais pu lire sur plusieurs sources qu'à la génération d'une clef principale, on obtenait automatiquement une subkey de chiffrement, mais il semble que cela ne soit plus le cas, où que j'ai raté quelque chose.
# Désolé mais je peu pas attendre ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
J'ai du apprendre à me servir de GPG dernièrement et j'ai fait le même constat : c'est linuxfr que j'ai trouvé les infos les plus pertinentes …
Vendredi c'est le pont dont je peu déverser ma bile …
Je veux juste me moquer des effets de modes chez nos camarades grosses structures qui gèrent nos sous.
Apparemment cette année la mode chez les sultants en sécurité c'est GPG et le cryptage, tout doit être crypté et sécurisé.
Surtout quand on communique avec des fournisseurs …
il y a qq années la mode c'était SSL et les certificats, pour un look moderne et sportif
Pour les amateurs de dentelles il y avait la double authentification cela rajoute un coté soyeux, plus confortable.
Cette année, l'inspiration est venu d'un retour a des matières nobles et sures comme le cryptage GPG, avec la texture immatérielle des clés RSA 1024 ou 2048 Bits …
Ou comment faire du neuf avec du vieux … après tout la mode n'est qu'un éternel recommencement.
Mais surtout, le plus important, ne pas enlever une couche, ne sait on jamais … même technique que pour Windows ou la violence … si ça marche pas mieux, dans le doute rajoute une couche …
Et le tout, c'est la que c'est le plus drôle, sur un protocle PeSit déjà crypté déjà sécurisé avec double authentification etc … qui a fait ses preuves depuis …longtemps très longtemps …
une époque bien avant le Grand Réseau … ou les magiciens passaient des lunes et des lunes a peaufiner leur incantations sur des grimoires … car oui en ce temps la … on écrivait sur du papier … pas des présentations.
Ahh messieurs … les encapsuleurs de couches ( c'est presque une contrepétrie …) je vous remercie et c'est avec impatience que j'attends la prochaine couche …
[^] # Re: Désolé mais je peu pas attendre ...
Posté par jmiven . Évalué à 4.
Le "cryptage", c'est tout de même un appeau à troll dépassé. Mais après tout, comme tu dis, la mode n'est qu'un éternel recommencement ;-)
[^] # Re: Désolé mais je peu pas attendre ...
Posté par Christophe B. (site web personnel) . Évalué à 1. Dernière modification le 11 mai 2021 à 09:00.
Apparemment certains viennent de le découvrir :)
Si encore c'était pour remplacer un transfert ftp absolument pas sécurisé OK
mais la c'est pour rajouter une couche de plus pour transmettre des données qui au final vont atterrir sur des enveloppes et du mailing :)
Quelqu'un a dit un jour : que le génie c'était de donner des idées aux autres 20 ans plus tard …
[^] # Re: Désolé mais je peu pas attendre ...
Posté par Philippe F (site web personnel) . Évalué à 6.
Pour rester dans le même filon, mon entreprise vient d'activer une fonctionnalité de sécurité de Office 365 / Outlook 2016 que nous utilisons en interne: tous les mails sont chiffrés. Du coup, je m'suis dit: "cool, plus besoin de chiffrer nos documents en gpg alors !". Que nenni. Il semble que comme l'hébergement soit aux US et qu'on fait globalement de la haute sécurité (carte à puce, passeport, carte d'identité, carte bancaire), on peut pas faire confiance à Crosoft.
Donc on se tape la double couche de documents à échanger en pgp, plus les spécificités de Office pour dire que c'est un mail à usage restreint, niveau de confidentialité "Confidential".
[^] # Re: Désolé mais je peu pas attendre ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
On sent que le IT "commun", le plus courant, va s'écrouler sous sa masse …
Imagine :
Tu compresses+cryptes tes fichiers
tu les envoies par mail via l'option de sécurité Compression+cryptage
et a tout les coups cela passe par un VPN qui compresse et crypte
gabégie de ressources …
Mais bon je ne suis pas surpris, j'ai des clients avec 12 ans d'historique jamais utilisé
et personne pour prendre la décision de purger, le cout en stockage sauvegarde etc …
[^] # Re: Désolé mais je peu pas attendre ...
Posté par Psychofox (Mastodon) . Évalué à 5.
Cela-dit tu ne fais pas forcément confiance aux même entités pendant le transfort et le stockage d'une même document/message. Et tu peux avoir une partie du traffic dont tu acceptes que l'un peut avoir une vue dessus mais pas l'autre.
[^] # Re: Désolé mais je peu pas attendre ...
Posté par ff9097 . Évalué à 5.
Dire ça et utiliser Office 365….
# Sous-clef de chiffrement
Posté par gouttegd (site web personnel) . Évalué à 9.
Pas tout-à-fait,
SCne signifie pas Sign Capability mais Sign, Certify, et indique que la clef est utilisable non seulement pour signer mais aussi pour certifier.La certification étant un cas particulier de signature, où l’on signe d’autres clefs (au lieu de signer des fichiers ou des e-mails).
Générer une sous-clef de chiffrement est bien toujours le comportement par défaut de GnuPG. Sauf gros bug (toujours possible mais franchement peu probable parce qu’un bug pareil aurait peu de chance de passer inaperçu), le seul moyen d’obtenir une clef comme la tienne (clef principale SC + une sous-clef S) est de le demander explicitement.
[^] # Re: Sous-clef de chiffrement
Posté par nox . Évalué à 5.
Ah oui en effet, merci de la rectification!
En relisant mes notes, je me rends compte que c'est exactement cela, bien vu :
gpg --full-generate-key --expert
Select (11) ECC (set your own capabilities)
Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate
Current allowed actions: Sign Certify > (Q) Finished
[...]
# Pareil
Posté par chimrod (site web personnel) . Évalué à 3.
J'ai redécouvert récemment GPG, également via la protection des mots de passes. Jusqu'alors, j'avais la vision de GPG un peu réductrice d'être associé aux courriels, avec des contraintes que j'imaginais un peu lourdes (le process de création d'une clef est "sérieux" quand on veut juste tester sans aller plus loin).
J'ai sauté le pas il y a un an, en m'achetant une clef GPG (une version "non sécurisée" qui n'est pas basée sur carte à puce). Cela me permet de versionner mes mots de passe sans risque dans git (et donc de sécuriser une perte), ou d'y avoir accès sans avoir à diffuser ma clef GPG (le token est suffisant).
Comble du bonheur, il est également possible d'utiliser la clef GPG pour ssh, ce qui évite d'avoir à multiplier les clefs autorisées !
# gopass
Posté par ianux (site web personnel, Mastodon) . Évalué à 2.
Si tu utilises pass, GPG et git, je te conseille de jeter un coup d’œil à gopass qui est 100% compatible avec pass au niveau API et propose des fonctionnalités supplémentaires comme la synchro avec un dépot git, des extensions pour les navigateurs, des applis pour smartphone, le support OTP, etc.
[^] # Re: gopass
Posté par nox . Évalué à 1.
Intéressant!
Mais à vrai dire je comptais déjà migrer mon Pass vers autre chose. J'utilise également Bitwarden, et je veux essayer d'utiliser rofi-rbw pour le cli et bricoler quelque chose avec dmenu pour avoir l'équivalent de mon utilisation de Pass.
[^] # Re: gopass
Posté par Fabien PRORIOL . Évalué à 2.
J'utilise pass, mais j'ai pas compris l’intérêt de gopass par rapport a pass…
Déjà dans pass
Déjà dans pass (browserpass…)
Déjà dans pass
Il existe une extension pass (pass-otp) mais j'ai pas testé (j'utilise FreeOTP pour le moment…)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.