Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
a un moment il faut bien partagé ta clé publique au moins une fois avec ton destinataire pour qu'il puisse lire tes mails, inconvénient si tu l'envoies par mail, il peut potentiellement être intercepté par un tiers qui tu coup aura ta clé publique et pourra lire tes futur messages chiffré sans que tu le sache
Oui, mais non ... 
ma clé « publique » est diffusée, ça c'est pas un problème ... reste à savoir si c'est la bonne ..; et c'est là que les signatures entrent en jeu si j'ai bien compris, pour établir le « niveau de confiance » qu'on peut attribuer à cette clé ...
Ma clef "publique" est trouvable sur le serveur OpenPGP, d'un simple gpg --search .
******
ubub, ta clé publique associée ton adresse ne comporte pas de sous-clé :
J'ai accès à 7 autres clés associées à des adresses e-mail ou autrement dénommées comptes de messagerie et toutes ont leur sous-clé. Je ne sais pas ce que cela signifie, mais c'est quand même intrigant.
Ouais, intrigant ..; j'ai pas tout compris le rôle des sous-clés ...
Ma clé, est la clé « primaire » et la sous-clé en même temps .
Ta clé, j"ai vu comporte deux sous clés avec des numéros différents associés à une clef
C'est flou pour moi tout ça ... 
Dernière modification par ubub (06-11-2024 21:40:54)
Hors ligne
a un moment il faut bien partagé ta clé publique au moins une fois avec ton destinataire pour qu'il puisse lire tes mails, inconvénient si tu l'envoies par mail, il peut potentiellement être intercepté par un tiers qui tu coup aura ta clé publique et pourra lire tes futur messages chiffré sans que tu le sache
Tu peux trouver ma clé publique ici : https://db.debian.org/fetchkey.cgi?fing … F91CEB80D8
Tu penses vraiment que s’il suffisait de la connaître pour lire mes mails chiffrés, ou usurper mes signatures de paquets Debian, je la partagerais de cette manière sans arrière pensée ? 
En ligne
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
En ligne
Dernière modification par Croutons (07-11-2024 14:21:37)
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
Hors ligne
Dernière modification par dezix (07-11-2024 19:52:48)
Hors ligne
de ces précisions
Comme la science n'est pas infuse, elle se diffuse.
Useless Use of Cat Award
Filenames and Pathnames in Shell: How to do it Correctly
À chaque problème sa solution, à chaque solution son moyen, si pas de moyen, toujours le problème !
En ligne
Dans ce système le risque est (je crois) de se faire refiler une fausse clé public
Exact, c’est la première étape nécessaire à une attaque de type "man in the middle". C’est donc une attaque ciblée, de la part de quelqu’un qui nous vise spécifiquement.
En ligne
D'authenifier l'indentité du créateur de la signature
Et d'authentifier l'intégralité de ce qui est signé (un message ou un fichier)
Cela est obtenu en réalisant un hash du fichier (ou message), puis en chiffrant le hash obtenu.
La signature est soit
Soit ajoutée au message (il sera alors nécessaire de dissociée le message de la signature pour contrôler l'intégralité)
Soit placée dans un fichier séparé. On parle alors de signature dissociée. C'est par exemple utile, pour signer un binaire.
En communication :
La clé publique est utilisée pour :
Chiffrer un message que l'on désire envoyer au propriétaire de cette clé.
Et pour vérifier une signature afin de garantir l'identité du signataire (en déchiffrant le hash de ce qui est signé).
La clé privée permet :
De déchiffrer un message qui a été chiffré par la clé publique
De signer un message ou un fichier (de chiffrer le hasch de ce qui est signé)
Exemple : Soit Alice qui veux envoyer un message signé et chiffré à Bob :
Alice et Bob on chacun une paire de clé :
Alice : Apub sa clé publique et Apriv sa clé privé (ou secrète)
Bob : Bpub sa clé publique et Bpriv sa clé privé (ou secrète)
Alice donne/envoie sa clé publique (Apub) à Bob (ou Alice la publie sur un serveur et Bob la récupère)
Bob donne/envoie sa clé publique (Bpub) à Alice (ou Bob la publie sur un serveur et Alice la récupère)
Alice crée le message :
Elle réalise un hash du message
Elle crée la signature en chiffrant avec sa clé privée (Apriv) le hash obtenu
La signature est ajoutée au message
Puis avec la clé publique de Bob (Bpub), elle chiffre le tout
... Le message est envoyé à Bob
Bob reçoie le message :
Il utilise sa clé privé (Bpriv) pour déchiffrer le message
Il dissocie le message et sa signture
Avec la clé publique d'Alice (Apub), il déchiffre la signature (contrôle de l'identité d'Alice)
Il réalise un hash du message
Et compare les 2 hash, ils doivent être identique (controle de l'intégralité du message)
... Bob peut lire le message d'Alice
Notes :
Ici est utilisé l'ordre : Écriture > Signature > Chiffrement ==> Déchiffrement > Vérification de la signature > Lecture
Je ne garantie pas que cet ordre soit exacte (je l'ai su, mais ne m'en souvient plus)
Cela pourrait être l'inverse : Écriture > Chiffrement > Signature ==> Vérification signature > Déchiffrement > Lecture
Ce mécanisme est basé sur deux priorités :
La clé privée doit restée secrète.
Et on doit être certain que la clé publique appartient à son propriétaire.
La clé publique peut être connue de tous.
Expliqué autrement :
Forum > Internet > Importer une clé GPG dans Thunderbird #31
(fr) Fonctionnement de la signature numérique (igm.univ-mlv.fr)
dezix a écrit :Dans ce système le risque est (je crois) de se faire refiler une fausse clé public
Exact, c’est la première étape nécessaire à une attaque de type "man in the middle". C’est donc une attaque ciblée, de la part de quelqu’un qui nous vise spécifiquement.
Par exemple Hackim fait croire à Alice que sa clé publique (Hpub) est celle de Bob.
Alice utilise la fausse clé publique de Bob (Hpub) pour chiffrer le message
Elle envoie le message chiffré à Bob
Hackim intercepte le message, le déchiffre avec sa clé privée (Hpriv)
Il lit le message
Puis il chiffre le message avec la vrai clé publique de Bob (Bpub)
Et l'envoie à Bob
Bob reçois le message chiffré
Le déchiffre avec sa clé privé (Bpriv)
... Un tel cheminement est extrêmement difficile à déceler.
Dernière modification par agp91 (07-11-2024 19:41:39)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
Hors ligne
En ligne
échanger la clé devant une chope de bière... les yeux dans les yeux
Ou qu'un autre (A) dont on est certain de sa clé publique (et qu'on ai confiance en lui) signe la clé publique d'un autre (B) (dont A est certain de la clé publique de B).
B peut alors aussi certifier (signer) les clés publique dont il est certain
... etc
Si un maillon est corrompu, la chaîne de confiance est brisée.
Haha, c'est le b.a.-ba de la confiance mutuelle entre amis et amis des amis (et amis des amis des amis ...)
Dernière modification par agp91 (07-11-2024 21:13:07)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
En ligne
L'obtenir auprès d'un personnel de cette activité (après avoir prouvé qu'il appartient à cette activité)
Ou quelle soit signée par une autorité de confiance (une personne ou un organisme)
Le dernier point, nous amène aux autorités de certification (AC) ou CA (Certificate Authority)
Les certificats (de clé publique) sont puissants, ils peuvent par aussi prouver un attribut. Par exemple, prouver de ne pas être mineur sans divulguer son identité.
[edit]
prouver de ne pas être mineur sans divulguer son identité
(ou appartenir à un groupe)
A condition qu'il n'y ait pas vole ou cession/vente de clé privé.
Dernière modification par agp91 (08-11-2024 01:47:35)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
En ligne
Dernière modification par agp91 (08-11-2024 02:20:59)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
En ligne
Pages : 1