Quels standards pour la signature et le cryptage PGP des mails ?

Posté par Sebastien le 11 décembre 2001 à 21:13. Modéré par Fabien Penso.

Étiquettes :

déc.

2001

D'un côté, certains MUA (NdM: Mail User Agent) comme Kmail font du PGP "in line", c'est à dire dans le corps du mail. D'autres utilisent des messages PGP/MIME (NdM: la signature est dans une partie MIME). Bien entendu, ce n'est pas vraiment compatible, et il est pénible de lire les mails de l'un avec l'autre.
Qu'en disent les RFC ? A l'origine, PGP était "in line", comme le définit la RFC 1991 qui date de 1996... Mais depuis, les RFC 2015 et 3156 (la 3156 est une maj de la RFC 2015 datée de 2001) définissent clairement PGP/MIME comme "proposed standard".

Mutt par exemple, utilise PGP/MIME... mais c'est quasiment le seul (oui oui il y a aussi Gnus). Kmail utilise le PGP inline...

Avant que tout le monde passe en PGP/MIME, il est préférable bien entendu de pouvoir utiliser les deux.

En attendant ça, vous pouvez utiliser 3 scripts Perl pour permettre à Kmail de lire les mails cryptés/signés en PGP/MIME, ou bien passer à Gnus (en bricolant un peu il doit surement faire les deux et même plus :p)

Note du modérateur: la version CVS de Gnus (Oort Gnus) supporte tous les modes d'utilisation de PGP, dans le corps comme en détaché, de manière transparente et sans qu'il y ait besoin de "bricoler". Je vous rappelle également qu'il existe GnuPG, une implémentation libre du protocole OpenPGP, qui remplace complètement la version commmerciale nommée PGP. Voir le lien dans la boîte Edito :)

Aller plus loin

RFC 1991 (9 clics)
RFC 3156 (4 clics)
Les 3 scripts pour kmail (3 clics)
muttfr (12 clics)
gnusfr (14 clics)

# Gnus il le fait

Posté par Fabien Penso (site web personnel, Mastodon) le 11 décembre 2001 à 21:32. Évalué à 10.

Pour information, avec ma configuration de gnus disponible sur http://perso.linuxfr.org/penso/emacs.tar.gz(...(...)) tout cela fonctionne.

Par défaut je sign/crypte en MIME, mais si j'ai une fiche bbdb pour la personne (un espèce d'adressbook super puissant) avec le champs pgp-mail à la valeur qu'il faut, je l'envoie en inline. En fait pour ce champs là j'ai 4 valeurs possibles pour signer/crypter en inline ou mime automatiquement, sans que Gnus me demande quoi que ce soit au moment de l'envoi du message. Quand je vois un mec qui utilise GnuPG/PGP avec Outlook par exemple, je fais en sorte de crypter en inline.

Tous mes messages sont signés quand j'en envoie, le tout en MIME, sauf si c'est un message usenet, dans ce cas c'est en inline pour respecter la netiquette usenet qui dit qu'il ne faut pas envoyer d'attachement.

Tout cela avec quelques lignes de Lisp. Enfin j'dis ça, j'dis rien ;-)
- [^] # Sylpheed aussi
  
  Posté par Anonyme le 11 décembre 2001 à 21:33. Évalué à 5.
  
  Tout est dans le sujet
  - [^] # Re: Sylpheed aussi
    
    Posté par Serge Rossi (site web personnel) le 11 décembre 2001 à 22:26. Évalué à 8.
    
    Ah quand même ! Je m'inquiétais que personne ne cite ce génialissime client de messagerie graphique (GTK) mais très léger, fulgurant et qui fait tout (POP3 / IMAP4 / PGP / LDAP / SSL / X-Face).
    
    Allez, l'URL du site pour la peine :
    
    http://sylpheed.good-day.net/(...(...))
    - [^] # Re: Sylpheed aussi
      
      Posté par Pascal Terjan (site web personnel) le 11 décembre 2001 à 22:45. Évalué à 3.
      
      Il est bugué sur l'IMAP (tous les dossiers apparaissent en double...) et j'ai pas trouvé ou faire un bug-report. en plus les archives de ML n'esxistent qu'en japonais :(
      - [^] # Re: Sylpheed aussi
        
        Posté par Anonyme le 11 décembre 2001 à 22:51. Évalué à -1.
        
        Ca doit être un "bug" relatif au serveur IMAP, j'ai aucun problème de ce côté là.
        
        Je me souviens que quand j'avais configuré un client mail en PHP, il y avait des particularités pour chaque serveur IMAP, il y a peut-être un rapport...
        
        [^] # Re: Sylpheed aussi
        
        Posté par Pascal Terjan (site web personnel) le 11 décembre 2001 à 23:12. Évalué à 1.
        
        Ouais mais bon la ca marche avec netscape, avec kmail, en PHP, avec evolution (gnus me trouve la bonne liste de dossiers mais foire ensuite).
        
        Donc je me dis que ce bug vient de sylpheed.
        
        [^] # Re: Sylpheed aussi
        
        Posté par Anonyme le 11 décembre 2001 à 23:16. Évalué à 1.
        
        Moi je me dis que ça viens du fait qu'il ne prend pas en compte les spécificités du serveur IMAP. Après réflexion, le problème que tu décris, justement, je l'ai eu avec le client mail PHP dont je parlais...
      - [^] # Re: Sylpheed aussi
        
        Posté par Wi][ish le 12 décembre 2001 à 13:47. Évalué à 2.
        
        "les archives de ML n'esxistent qu'en japonais"
        
        C'est inexacte, je suis abonné à la ML Devel version US
        
        depuis plus d'1 an. Il y a 2 ML.
        
        [^] # Re: Sylpheed aussi
        
        Posté par Pascal Terjan (site web personnel) le 12 décembre 2001 à 14:19. Évalué à 1.
        
        Il y a en effet deux ML mais pour les archives ils ne mettent un lien que vers le japonais. Tu sais ou sont celles de la ML anglaise ?
        
        [^] # Re: Sylpheed aussi
        
        Posté par Wi][ish le 12 décembre 2001 à 14:29. Évalué à -1.
        
        http://sylpheed.good-day.net/#ml(...(...))
        
        (et hop -1, on précise sinon on se retrouve à -42)
        
        [^] # Re: Sylpheed aussi
        
        Posté par Wi][ish le 12 décembre 2001 à 14:32. Évalué à -1.
        
        La mailing list US ne possede pas d'archive.
        
        La seule façon d'y accéder, c'est de s'y abonner.
        
        --
        
        (et hop -1)
      - [^] # Re: Sylpheed aussi
        
        Posté par Sebastien Rodriguez le 12 décembre 2001 à 15:24. Évalué à 3.
        
        Pour le bug report, il est préférable de le faire sur le "fork" sylpheed-claws qui intègre les dernières fonctionnalités de Sylpheed, mais surtout qui corrige plus vite les bugs et transfère les corrections dans la branche principale.
        
        Une adresse : http://sylpheed-claws.sourceforge.net/(...)
        
        Essayez !!!
    - [^] # Re: Sylpheed aussi
      
      Posté par Neryel le 11 décembre 2001 à 22:56. Évalué à 2.
      
      Moi j'aime bien Sylpheed, mais j'ai pas trouvé comment me servir de GPG avec... je sais, je sais, RTFM mais j'ai pas trouvé ;) (mal cherché ?)
      - [^] # Re: Sylpheed aussi
        
        Posté par Anonyme le 11 décembre 2001 à 23:03. Évalué à 8.
        
        Il suffit d'installer gpgme et de compiler sylpheed avec l'option --with-gpgme (ou un truc du genre)
        
        Ensuite, tu as un onglet Privacy dans la boite de dialogue des Common Preferences pour dire si tu veux toujours crypter ou toujours signer ; sinon, quand tu édites un message, dans le menu Message, tu as les options Sign et Crypt qui font ce qu'elles indiquent.
        
        Voilà.
        
        (Je mets pas -1 parce que ça peut intéresser des gens et que ça parle de comment GPGiser avec Sylpheed)
    - [^] # Re: Sylpheed aussi
      
      Posté par Jean-Yves B. le 11 décembre 2001 à 23:23. Évalué à 4.
      
      Il ne gère pas l'authentification CRAM-MD5 ou CRAM-SHA1 avec l'IMAP (authentification type Challenge/Response qui permet de ne pas transmettre le mot de passe de manière plus ou moins directement lisible (non, base64 ne protège pas de la lecture)).
      
      Ne gère pas non plus les STARTTLS correctement.
      - [^] # Re: Sylpheed aussi
        
        Posté par benja le 12 décembre 2001 à 00:37. Évalué à 5.
        
        CRAM-MD5
        
        CRAM-SHA1
        
        authentification type Challenge/Response
        
        STARTTLS
        
        base64
        
        Est-ce que tu pourrais, s'il te plait, expliquer à l'inculte que je suis, tous ces acronymes.
        
        Merci.
        
        [^] # Re: Sylpheed aussi
        
        Posté par Jean-Yves B. le 12 décembre 2001 à 01:16. Évalué à 10.
        
        CRAM-MD5
        
        CRAM-SHA1
        
        authentification type Challenge/Response
        
        RFC2195 [1]
        
        En fait le mot de passe n'est pas transmis sur le fil. Pour simplifier (à mort) le serveur envoie un nombre au client, le client fait une opération mathématique non-réversible avec le mot de passe et le nombre envoyé par le serveur puis envoie le résultat au serveur. Le serveur fait le même calcul dans son coin avec le bon mot de passe et teste si ça concorde. Le mot de passe n'est pas transmis, seule une preuve de possession du mot de passe l'est.
        
        MD5 ou SHA1 sont deux opérations mathématiques [à ce jour] non inversibles [facilement].
        
        STARTTLS
        
        RFC2595 [2]
        
        C'est la commande en IMAP (entre autres) pour basculer un flux en mode SSL, donc chiffré et éventuellement authentifié. Quand elle est complètement supportée, on n'est pas obligé de se connecter en SSL direct sur un port spécial, on se connecte sur le port classique imap (143) et après avoir vérifié que le serveur est apte à supporter SSL, on bascule. Si il ne peut pas alors on utilise autre chose ou on laisse tomber.
        
        base64
        
        Une opération permettant de transmettre des informations 8bit sous une forme 7bit. Il en existe d'autres, comme UUEncode, mais celle-ci est devenue standard comme moyen de transport dans une des RFC de MIME (RFC1341 [3]).
        
        Voilà, voilà. Je commence les cours de français demain :)
        
        [1] ftp://ftp.isi.edu/in-notes/rfc2195.txt(...(...))
        
        [2] ftp://ftp.isi.edu/in-notes/rfc2595.txt(...(...))
        
        [3] http://www.fourmilab.ch/webtools/base64/rfc1341.html(...(...))
        
        [^] # Re: Sylpheed aussi
        
        Posté par Wi][ish le 12 décembre 2001 à 13:57. Évalué à 2.
        
        "MD5 ou SHA1 sont deux opérations mathématiques [à ce jour] non inversibles [facilement]."
        
        C'est inexacte SHA-1, qui est un algorithme de hashage sur 160 bits, est réversible. Pour preuve, SHA-1 sert de base à "Shacal", un aglo de cryptage assez rapide candidat à NESSIE (New European Schemes for Signatures, Integrity, and Encryption).
        
        Pour plus d'info sur NESSIE et Shacal:
        
        http://www.cosic.esat.kuleuven.ac.be/nessie/index.html(...(...))
        
        http://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions.ht(...))

[^] # SHA-1

Posté par Jean-Yves B. le 12 décembre 2001 à 14:26. Évalué à 4.

En fait, SHA-1 est un hash cryptographique non réversible.

cf. nos amis du NIST http://www.itl.nist.gov/fipspubs/fip180-1.htm(...(...))

ou même les manpages d'OpenSSL.

Mais il existe des algos de chiffrement symmétrique basé sur SHA-1, comme SHACAL.

Après tout, DES est utilisable selon 2 modes (hash ou chiffrement symétrique) aussi (passwd Unix standard vs. commande crypt).

[j'ai la flemme de ressortir mon cours de crypto mais bon, il suffit de changer deux trois trucs pour passer d'un mode à l'autre]
- [^] # Re: SHA-1
  
  Posté par Wi][ish le 12 décembre 2001 à 14:41. Évalué à 1.
  
  "Il suffit de changer deux trois trucs pour passer d'un mode à l'autre"
  
  Effectivement, autant pour moi...
  
  Shacal n'utilise pas entièrement SHA-1, il zap une étape sur la fin de son algo, qui permet de le rendre réversible. Sans cette condition, il n'est effectivement pas symétrique.

[^] # Re: Sylpheed aussi

Posté par Foxy (site web personnel) le 12 décembre 2001 à 11:22. Évalué à 1.

Avec l'utilisation de la librairie GPGME et la compilation avec l'option "--enable-gpgme", Sylpheed supporte PGP/GPG en respectant le type PGP/MIME (RFC 2015).

Il existe un patch pour avoir aussi le support du mode GPG "ASCII armored" (signature dans le corps du message) : http://www.teledix.net/sylpheed/(...(...)) http://www.teledix.net/sylpheed/0.6.3/sylpheed-0.6.3-gpg_ascii_armo(...))

A ce propos, je travaille depuis ce WE à l'implémentation de GPG/PGP dans le MUA Balsa (MUA de Gnome) : http://www.balsa.net(...(...))

[^] # Re: Gnus il le fait

Posté par Sebastien le 11 décembre 2001 à 22:50. Évalué à 8.

J'ai mis exprès "oui oui il y a aussi Gnus" entre parenthèses dans la news en pensant à toi Fabien, j'étais sur que tu ferais le premier commentaire pour expliquer que gnus lave plus blanc qui blanc :p

[^] # Re: Gnus il le fait

Posté par Benjamin Michotte le 11 décembre 2001 à 23:01. Évalué à 10.

pour les gens qui utilisent des logiciels non conforme aux RFC,

dans les versions 1.3.x avec x >= 21 (je crois), il suffit de faire un :set pgp_create_traditional pour que mutt envoye le mail au format PGP in line.

il est donc possible de faire des hook pour les gens qui utilisent ces mua.

exemple de hook

send-hook benoit 'set pgp_create_traditional' et voila...

[^] # Re: <S>Gnus</S> mutt il le fait

Posté par Benjamin Michotte le 12 décembre 2001 à 01:51. Évalué à 10.

j'oubliais de rajouter... pour que mutt reconnaisse les mails inline, rajoutez donc ceci dans votre .procmailrc

(désolé pour l'identation)

:0

* !^Content-Type: message/

* !^Content-Type: multipart/

* !^Content-Type: application/pgp

{

:0 fBw

* ^-----BEGIN PGP MESSAGE-----

* ^-----END PGP MESSAGE-----

| formail \

-i "Content-Type: application/pgp; format=text; x-action=encrypt"

:0 fBw

* ^-----BEGIN PGP SIGNED MESSAGE-----

* ^-----BEGIN PGP SIGNATURE-----

* ^-----END PGP SIGNATURE-----

| formail \

-i "Content-Type: application/pgp; format=text; x-action=sign"

}
- [^] # Re: <S>Gnus</S> mutt il le fait
  
  Posté par Cedric_Duval le 12 décembre 2001 à 20:41. Évalué à 2.
  
  Ou alors, pour Mutt 1.3.x, utiliser la fonction
  
  check-traditional-pgp (ESC P)
  
  pour vérifier les signatures inline.

# Avec Pine ?

Posté par Julien CARTIGNY (site web personnel) le 11 décembre 2001 à 21:36. Évalué à 0.

Et avec Pine ? je crois qu'il n'accepte pas quand la signature est en PGP/MIME...... existe t'il des moyens (avec filtres ou scripts externes) pour réaliser cette opération ?

[^] # Re: Avec Pine ?

Posté par Gaël Le Mignot le 11 décembre 2001 à 21:52. Évalué à -6.

Pine, c'est Mal(TM)

http://www.epita.fr:8000/~le-che_e/pine.html(...(...))

-1

# standard?

Posté par Antoine Schweitzer-Chaput le 11 décembre 2001 à 22:16. Évalué à 10.

A mon avis le cryptage des mails n'a aucune chance de se généraliser tant que deux protocoles incompatibles tels que ceux-ci coexisteront.

D'après la news la RFC semble assez jeune, est-ce que les clients mail auront tous la volonté de la respecter rapidement? En particulier est-ce que Outlook va changer, parceque malheureusement je ne pense pas qu'un standard pourra s'imposer rapidement sans une compatibilité Outlook...

[^] # Re: standard?

Posté par Rin Jin (site web personnel) le 11 décembre 2001 à 22:50. Évalué à 2.

J'ai quand même peur que si Outlook accepte un des deux standard, microsoft le transforme suffisament pour ne pouvoir lire que les mails crypté avec Outlook, un peu comme le html "conforme" de chez MS.
[^] # Re: standard?

Posté par Sebastien le 11 décembre 2001 à 22:53. Évalué à 1.

Le plus important est que les MUA libres sachent lire et ecrire les deux.

Ensuite, comme c'est un standard et que techniquement celà semble plus propre, mime/pgp s'imposera petit à petit. J'ai entendu parler de plugin mime/pgp pour outlook... c'est à verifier.
[^] # Re: standard?

Posté par Patrice Fortier le 12 décembre 2001 à 10:06. Évalué à 1.

Et encore, on a pas parlé de s/mime...

Ca en fait du boulot pour les codeurs de mua :)
[^] # Re: standard?

Posté par VACHOR (site web personnel) le 12 décembre 2001 à 11:35. Évalué à 5.

Si si, ca peut. Il faut simplement supporter les différentes versions.

Il n'y a pas une version "meilleure" que d'autres, il y a des versions, qui ont chacune des avantages et inconvénients. Chacun doit prendre la version qui est la mieux suivant l'usage. Aux clients de se débrouiller avec les implémentations.
[^] # Outlook fait du inline

Posté par Xavier Bestel (site web personnel) le 12 décembre 2001 à 12:51. Évalué à 3.

§Y'a un plugin PGP pour Outlook, mais qui fait que du inline. Donc quand tu envoies un MIME, le mail est vide est le message crypté est dans un attachment.

Evolution fait les deux, lui. Mais il n'envoie que le MIME (RFC-correct)

# Et pour mutt ?

Posté par the_freeman le 11 décembre 2001 à 23:18. Évalué à 1.

Existe-t-il des filtres/scripts pour utilisée les deux ?

Peut être pour les prochaines versions ?

[^] # Re: Et pour mutt ?

Posté par bmc le 11 décembre 2001 à 23:27. Évalué à -5.

Y'avait un truc là dessus sur muttfr.org, j'ai oublié l'url
[^] # Re: Et pour mutt ?

Posté par Benjamin Michotte le 12 décembre 2001 à 00:44. Évalué à 0.

regarde un rien plus haut ;)

A propos de mutt... actuellement, il est en version 1.3.24i qui est une des candidates pour <B>mutt 1.4</I> qui ne sera plus trop long avant d'arriver.
- [^] # Re: Et pour mutt ?
  
  Posté par Benjamin Michotte le 12 décembre 2001 à 00:45. Évalué à -3.
  
  dans la famille "binny découvre le html"...
  
  hop, -1(TM)

# Y'a pas que PGP dans la vie.....

Posté par Vanhu le 12 décembre 2001 à 08:50. Évalué à 5.

Y'a aussi les certificats SMIME (RFC 2311), basés sur les PKI (et tout le monde le dit, les PKIs, c'est l'avenir !!! :-).

La notion d'autorité de certification permet (sous reserve de faire confiance à cette fameuse autorité) de se passer du problème de diffusion fiable des clés publiques dans la méthode PGP....

Pour info, il y a au moins un patch pour Mutt ( http://elmy.myip.org/mutt/smime.html(...(...)) ), mais si quelqu'un connait une technique à base de scripts et d'OpenSSL pour faire pareil avec un Mutt 1.2.5, je suis preneur ....

[^] # Re: Y'a pas que PGP dans la vie.....

Posté par William Steve Applegate (site web personnel) le 12 décembre 2001 à 10:24. Évalué à 4.

Et Gnus est aussi compatible (je tiens l'info de l'Évangéliste Fabien P.). Quant aux autres, c'est le néant le plus total. Or, Netscape Messenger (quand même assez répandu) intègre S/MIME depuis longtemps. On peut donc penser que ce serait une voie à explorer. Après tout, rien ne sert de crypter ses messages si vos correspondants ne peuvent les lire, ou doivent pour cela installer tout un attirail (loi n° 7548 des avanies informatiques : tout idiot avec un ordinateur installe un nombre astronomique de programmes inutiles, mais rechigne à télécharger quoi que ce soit lorsque vous en avez besoin). Bref, PGP c'est vachement bien, mais ça a du mal à entrer dans les moeurs...
Envoyé depuis mon PDP 11/70
[^] # Re: Y'a pas que PGP dans la vie.....

Posté par Anonyme le 12 décembre 2001 à 13:11. Évalué à 5.

Le problème de S/MIME est qu'il faut justement passer par une autorité de certification.

Tu peux très bien avoir la tienne, mais pour que ce soit vraiment valable, il faut passer par des autorités de certification reconnues.

Il y a deux choses qui me dérangent avec cette méthode :

- On est dépendant d'un système lourd de certification

- L'attribution d'un certificat est _payante_

Sinon, comme je disais, on peut avoir sa propre autorité de certification, mais ça retire tout l'intérêt de la chose... autant avoir des clés GPG qu'on a échangé _physiquement_ avec la personne en question...
- [^] # Re: Y'a pas que PGP dans la vie.....
  
  Posté par William Steve Applegate (site web personnel) le 12 décembre 2001 à 14:48. Évalué à 1.
  
  >- L'attribution d'un certificat est _payante_
  
  Non non, direction http://thawte.com/getinfo/products/personal/join.html(...(...)) pour un certificat gratos. Le seul truc c'est qu'il n'y a pas ton nom dessus (puisqu'ils ne peuvent pas le connaître). Donc tu présentes une pièce d'identité à un « notaire » de leur Web of Trust et il te met ton nom dessus ( http://www.thawte.com/getinfo/programs/wot/about.html(...(...)) ).
  
  Je ne dis pas que cette solution est la meilleure (les systèmes centralisés, ça fait ringard) mais comme plus de gens l'utilisent pour l'instant, ça a encore un intérêt...
  Envoyé depuis mon PDP 11/70
[^] # Re: Y'a pas que PGP dans la vie.....

Posté par Emmanuel Blindauer (site web personnel) le 12 décembre 2001 à 13:40. Évalué à 2.

smime aussi présent dans les futures versions de kmail, en tout cas dans la bonne branche du CVS:

http://www.gnupg.org/aegypten/development.en.html(...(...))

ca regroupe aussi des choses qui n'ont pas trop de rapport avec , mais aussi des addon sécurité.

# et les autres mua?

Posté par Emmanuel Blindauer (site web personnel) le 12 décembre 2001 à 09:02. Évalué à 2.

Et les autres MUA (a part kmail, mutt et gnus), ils signent comment ?netscape ou outlook, ils savent faire ?

[^] # Re: et les autres mua?

Posté par Foxy (site web personnel) le 12 décembre 2001 à 10:48. Évalué à 1.

Netscape ne sait absolument pas signer en utilisant PGP/GPG (en tout cas pas dans la version de base, et c'est prévu à long-terme dans Mozilla Mail), de même pour Outlook. Par contre, il existe de plugins qui permettent d'utiliser PGP/GPG en utilisant le mode "ASCII armored" (signature dans le corps du message).

Pour une excellente synthèse sur les clients/plugins de mail PGP/GPG, voir OpenPGP : http://www.geocities.com/openpgp/courrier_en.html(...(...))
[^] # Re: et les autres mua?

Posté par Benjamin Michotte le 12 décembre 2001 à 17:13. Évalué à 2.

un bon résumé des clients mails pour pour differentes plateformes (windows compris) avec liens vers les plugins si ils existent :
http://www.cryptorights.org/pgp-users/pgp-mail-clients.html(...)

# PGP = fausse securite ?

Posté par Jean-Marc Chapuzot le 12 décembre 2001 à 09:41. Évalué à -7.

Jusqu'a une periode recente ma societe utilisait PGP pour proteger ses mails concernant des sujets sensibles. A la suite d'une consultation avec le ministere de l'industrie et le contre-espionnage cette protection a ete abandonne au profit d'un autre systeme car les "grandes oreilles" etaient en mesure de lire a livre ouvert les mails proteges avec PGP. On a depuis un autre systeme de codage ....

[^] # Re: PGP = fausse securite ?

Posté par Benoît Sibaud (site web personnel) le 12 décembre 2001 à 10:00. Évalué à 4.

Je ne vois vraiment pas l'intérêt de ton commentaire, à part lancer un troll. Dire que des gens pensent dans les milieux autorisés qu'il pourrait éventuellement et sous toute réserve, à prendre de façon conditionnelle, une hypothètique faille dans PGP, ça avance à quoi ?

Donc soit tu en dis un peu plus sur les logiciels (PGP, GPG, etc) concernés, les versions concernées et la faille, soit tu ne dis rien !

Pour le moment c'est du FUD.
- [^] # GPG = fausse - fausse securite ?
  
  Posté par TSelek le 12 décembre 2001 à 10:23. Évalué à 3.
  
  Peut être faut-il comrendre qu'"ils" n'arrivent pas à casser les OpenPGP, d'ou le besoin de répandre ces fausses rumeurs "il est déjà cassé ce truc, utilisez donc autre chose". Ou alors il s'agit de softs NA avec key-escrow (NSA_KEY, c'est pas une rumeur mais une contrainte US à l'exportation).
  - [^] # Re: GPG = fausse - fausse securite ?
    
    Posté par Jean-Marc Chapuzot le 12 décembre 2001 à 10:53. Évalué à 0.
    
    La societe pour laquelle je travaille a eu pas le passe des problemes concernant l'espionage économique. Notre interet reste de pouvoir communiquer en "toute" securite a l'abri des oreilles indiscretes (USA, France, Russie, etc...).Si le service de renseignement national arrivent a lire les messages "proteges" par PGP il y a de forte chance que les autres aussi.
    - [^] # Re: GPG = fausse - fausse securite ?
      
      Posté par Banux (site web personnel) le 12 décembre 2001 à 11:14. Évalué à 2.
      
      Lu
      
      Pourrait t'on avoir un peu plus de details ?
      
      Par exemple la taille des cles utilise ?
      
      Car effectivement je pense qu'il doit exister des moyens de decrypter mais il faut voir en combien de temps et avec qu'elle moyens.
      
      Et si ce n'est pas une info confidentiels vous utiliser qu'elle moyen de cryptage maintenant ?
      
      ++
      
      Banux
      - [^] # Re: GPG = fausse - fausse securite ?
        
        Posté par Jean-Marc Chapuzot le 12 décembre 2001 à 13:33. Évalué à 0.
        
        Nous utilisons un PKI hybride. Le reste est confidentiel.
        
        [^] # Re: GPG = fausse - fausse securite ?
        
        Posté par Jean-Yves B. le 12 décembre 2001 à 14:12. Évalué à 4.
        
        Que l'échange de clés se fasse par un PKI ou dans le style OpenPGP ne change rien.
        
        Les mêmes algos de crypto sont utilisés dans les deux cas. C'est juste qu'avec une PKI tu as un « Tree of Trust » versus le « Web of Trust » d'OpenPGP.
        
        Le seul intérêt que je vois au PKI (S/MIME par ex.) est le fait de pouvoir apporter une « sémantique » à un certificat [x509] : dire qu'il est pour le timestamping ou pour le chiffrement ou pour la signature ou ... ce qui permet d'avoir plusieurs dimensions de confiance dans les clés.
        
        Mais les algos sont les mêmes, donc ça marche pareil : échange de clés RSA ou DH/DSS et compagnie, chiffrement en IDEA, BlowFish, 3DES ou whatever. Franchement, mis à part 2, 3 changements de couleurs (là on peut faire des digests supplémentaires, blabla) pour l'emballage c'est la même chose, sauf que l'on fait plus facilement du fric avec (Bonne vieille méthode de l'échange de tampon contre pot-de-vin bien connu dans toute bureaucratie qui se respecte).
        
        Si OpenPGP est cassé, S/MIME (SSL et autres PKIseries dans le même sac) l'est aussi, et inversement.
        
        <analogie type=douteuse>
        
        Les PKI c'est la crypto « business », OpenPGP c'est le Peer-To-Peer de la crypto.
        
        </analogie>
        
        La seule différence est la gestion du niveau de confiance des clés.
        
        Biblio :
        
        Spec S/MIMEv3 RFC2633 http://www.rfc-editor.org/rfc/rfc2633.txt(...(...))
        
        Style de crypto RFC2630 http://www.rfc-editor.org/rfc/rfc2630.txt(...(...))
        
        Spec OpenPGP RFC2440 http://www.rfc-editor.org/rfc/rfc2440.txt(...(...))
    - [^] # Re: GPG = fausse - fausse securite ?
      
      Posté par Benoît Sibaud (site web personnel) le 12 décembre 2001 à 11:19. Évalué à 8.
      
      Bonjour,
      
      je travaille pour <insérez ici votre service de renseignements préférés>.
      
      Je ne voudrais pas vous inquiètez mais je décrypte vos messages PGP d'une seule main tout en écoutant vos conversations téléphoniques et en consultant les sites XXX que vous fréquentez. Je lis aussi le SSL dans le texte et l'AES me fait doucement rigoler. Par contre le plain-text résiste encore à tous mes assauts.
      
      Pour votre sécurité, je vous conseille donc le plain-text.
      
      Veuillez diffuser ce messsage à tout votre carnet d'adresses, avec votre clé privée PGP en pièce jointe.
      
      Merci de votre attention.
      
      Ps: jusque là, toujours du FUD.
  - [^] # Re: GPG = fausse - fausse securite ?
    
    Posté par Matafan le 12 décembre 2001 à 12:48. Évalué à -1.
    
    Peut-être aussi qu'ils lancent la rumeur en espérant que certains y voient une rumeur lancée pour pousser les utilisateur à abandonner PGP, et restent donc sous PGP qui, bien sûr, serait effectivement cassé.
    
    On peut en imaginer des choses ;)
    
    [-1]

# Les RFC, comment ça marche ?

Posté par Yannick (site web personnel) le 12 décembre 2001 à 10:04. Évalué à 6.

Oui, je sais, c'est un peu hors-sujet, mais je me demandais comment marche les RFC, où on les trouve, comment savoir laquelle correspond à ce qu'on cherche...

Des questions de gars qui apprend quoi !

Désireux de faire profiter à tous ma trouvaille, j'indique aux personne que ça interesse des explications :

http://www.commentcamarche.net/internet/rfc.php3(...(...))

http://www.rfc-editor.org/(...(...))

D'ailleurs, si d'autres personnes ont des liens vers d'autres normes je suis prenneur...

[^] # Re: Les RFC, comment ça marche ?

Posté par lorill (site web personnel) le 15 décembre 2001 à 02:34. Évalué à 1.

http://www.ietf.org(...)

# Et evolution...

Posté par Jar Jar Binks (site web personnel) le 12 décembre 2001 à 10:42. Évalué à 6.

On a beaucoup tapé sur Ximian, mais on pourra noter qu'Evolution, malgré sa lourdeur, gère parfaitement le PGP/MIME. Il possède également toutes les fonctionnalités qui manquent à Sylpheed.

En bref, je trouve que sa réputation de copie d'Outlook est surfaite, car il est infiniment plus perfectionné (allez raconter à Outlook comment gérer une arborescence de boîtes aux lettres maildir).

J'ajouterai que la notion de répertoires virtuels est très intéressante (enfin, peut-être qu'ils ne l'ont pas inventée).

[^] # Re: Et evolution...

Posté par Xavier Bestel (site web personnel) le 12 décembre 2001 à 11:57. Évalué à 2.

Ben Evolution c'est carrément excellent. 'faut avoir une bonne machine (sur mon laptop pII 300MHz ça va bien), c'est tout. J'ai essayé plusieurs mailers, et je trouve Evo vraiment au top.
[^] # Les critiques sur Ximian ne sont pas principalement sur des

Posté par Anonyme le 12 décembre 2001 à 12:43. Évalué à 4.

« On a beaucoup tapé sur Ximian »

Les critiques sur Ximian ne sont pas principalement sur des aspects techniques.

(je met mon propos dans le titre, évidemment, je sais que les 1,5 % de votants s'empresseront d'occulter un propos qui ne brosse pas dans le sens du poil)

Selon certains, linuxfr doit être representatif des utilisateurs de « Linux » en France : des moutons incapables de supporter qu'on refuse leurs conceptions manichéennes donc.

Pour eux, soit Ximian est soit gentil soit méchant. Mais comprendre qu'on puisse critiquer Ximian sur certains points importants mais qu'en même temps Ximian ne fait pas forcement que de la merde, cest impossible.

La preuve est là : Jar Jar Binks ne comprend pas que l'on puisse critiquer la volonté de Ximian de faire du logiciel propriétaire, du fait qu'Evolution supporte PGP.
- [^] # Re: Les critiques sur Ximian ne sont pas principalement sur des
  
  Posté par Jar Jar Binks (site web personnel) le 12 décembre 2001 à 13:16. Évalué à 2.
  
  La preuve est là : Jar Jar Binks ne comprend pas que l'on puisse critiquer la volonté de Ximian de faire du logiciel propriétaire, du fait qu'Evolution supporte PGP.
  
  Je ne vois pas le rapport. Ximian ne sont pas les seuls à faire à la fois du libre et du propriétaire. Netscape, IBM, et bien d'autres en font autant. Par contre, Ximian a eu certaines pratiques douteuses, il est vrai. Mais ce que je vois, c'est qu'ils ont fait un excellent logiciel, diffusé sous licence GPL, et qui s'intègre parfaitement dans un environnement Gnome (ou non-Gnome comme chez moi). Et par intégration, j'entends par exemple la possibilité de l'utiliser conjointement avec d'autres logiciels, le respect des standards... Et je ne peux qu'en conclure que la majeure partie des critiques étaient infondées. Bien sûr, il faut surveiller leurs pratiques, mais pour l'instant ils ont fait beaucoup pour la communauté.

# Mutt et le PGP inline

Posté par Alexis B. le 12 décembre 2001 à 11:01. Évalué à 5.

Mutt aussi peut très facilement se configurer pour envoyer des messages

cryptés et signés en mode "inline".

Il suffit de rajouter la petite macro suivante dans son .muttrc :

macro compose S "Fgpg --no-verbose --clearsign --armor\no" "GPG sign as text/pla

in"

macro compose N "Fgpg --no-verbose -v -o - --encrypt --sign --textmode --armor -

-always-trust\no" "GPG encrypt as text/plain"

A partir de là, dans l'écran d'envoi (celui dans lequel vous tapez y pour

envoyer le message), vous pouvez taper N pour crypter et signer un message, et S

pour seulement le signer.

Ces macros sont valables pour gpg, avec la locale fr, mais les équivalents

pgp sont faciles à trouver.

[^] # Re: Mutt et le PGP inline

Posté par Jar Jar Binks (site web personnel) le 12 décembre 2001 à 11:32. Évalué à 3.

Il y a plus simple ; dans le man muttrc, on trouve :

pgp_create_traditional

Type: quadoption

Default: no

This option controls whether Mutt generates old-style PGP encrypted or signed messages under certain circumstances.

Mais plus loin : Also note that using the old-style PGP message format is strongly deprecated.
- [^] # Re: Mutt et le PGP inline
  
  Posté par Alexis B. le 12 décembre 2001 à 12:08. Évalué à 1.
  
  Je ne l'avais pas précisé dans mon message, mais c'est pour la version stable : 1.2.5.
  
  Je crois que l'option dont tu parles n'est présente que dans la version de développement!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.