Dans le cas où elle est sur un support statique (et chiffrée avec une passphrase) le problème de compromission est bien moindre. Après pour le problème de perte, rien ne t'empêche de la distribuer selon un secret partagé de Shamir.
OpenPGP fournit déjà un mechanisme de sous-clef complètement satisfaisant sans à avoir à réinventer la roue.
Un usage raisonné d'OpenPGP consiste à génerer une clef secondaire de signature (et une clef secondaire de chiffrement), d'exporter la partie privée clefs en détruisant la partie privée de la clef principale, et d'utiliser cette version pour un usage quotidien. La clef privée complète est quant à elle écrite sur un support passif ou sur une machine déconnectée du réseau.
En cas de compromission, les sous-clefs sont révoqués, de nouvelles sont générés et signées par la clef principale.
La clef principale n'est utilisé (sauf compromission des sous-clefs) que pour renouveller les sous-clefs ou pour étendre son réseau de confiance.
En parlant de TikZ et de graphviz dans le même thread, il y a dot2tex qui permet de génerer du code LaTeX utilisant PGF/TikZ à partir du résultat de graphviz. C'est tout simplement génial.
Il y a une chose dont je reverai à propos du choix des licences : un arbre de décision.
Genre
[ Redistribution ]
/ \
faible contraintes Avec la même licence
de licence
/
[ Utilisation des auteurs
pour en faire de la pub ]
/ \
oui non
/ \
… [ publicité ]
/ / \
BSD-2 oui non
/ \
… …
/ \
BSD-4 BSD-3
(Aucune garantie de véracité sur l'arbre d'exemple proposé).
il ne va pas tester les nombres séquentiellement, sinon il va faire les même tests que les autres mineurs.
Je ne vous pas pourquoi, du moment qu'il commence à un endroit aléatoire, ça semble même être mieux.
Notations, N le nombre de sels possibles, supposons qu'il sont de taille fixés (en vrai j'en sais rien), n le nombre de sels testés.
Hypothèse 1 : les deux protagonistes tirent les sels aléatoirements, le nombre de sel en commun entre les deux suit une loi hypergéometrique de paramêtre (n,n/N,N). Avec n/N→0, on a une loi binomiale. Le nombre de sels en commun a donc pour espérance n²/N et pour variance n²/N.
Hypothèse 2 : les deux protagonistes tirent séquentiellement les nombres à partir d'une position aléatoire (en supposant un bouclage si on arrive à la fin de l'espace des sels possibles), on obtient que la proba qu'il en aient exactement i en commun, avec i=1…n, qui vaut 1/N, bien entendu elle vaut 0 pour i>n, et elle vaut ce qu'il faut pour sommer à 1 pour i=0. On a donc (avec utilisation de n/N→0) une espérance de n²/(2N) et une variance de n²/(3N).
Bref, il semble même plus judicieux de tirer séquentiellement que à partir d'une position aléatoire. (Et en plus comme sha256 est un algo par bloc, on peut même avoir un avantage à ne pas recalculer depuis le début du sel pour aller plus vite, encore faut-il que le sel soit à la fin du machin à calculer, j'espère que non sinon c'est trop facile).
Après il ne faut pas oublier qu'on est en train de parler de proba qui sont très très petite, et même très très inférieure à la proba de trouver un sel valide, je m'excuse par avance auprès de la confrérie des mouches.
Posté par jben .
En réponse au journal Comment fonctionne Bitcoin.
Évalué à 2.
Dernière modification le 12 juillet 2013 à 16:05.
Justement, de loin, (je ne connais que rapidement le fonctionnement de bitcoin), ça a l'air d'un sel et non d'un nonce. La caractéristique d'un nonce c'est qu'il ne doit pas être réutilisé, on l'introduit pour éviter tout ce qui est du genre replay.
Y-a-t'il se genre de restriction, ou c'est juste un sel ?
Ça c'est déjà 512 ou 1536 Mio de plus que nécessaire.
Ça dépend comment tu défini necessaire.
Si c'est necessaire pour les programmes, alors oui, 512 MiB suffisent largement. Si c'est necessaire à un bon fonctionnement fluide, 2 GiB sont souvent appréciable, même sur un netbook, ainsi beaucoup de lectures se font sur le cache, les écritures peuvent se faire bufferiser largement…
J'en profite pour parler de torsocks, qui fonctionne pareil que tsocks, mais qui à quelques patches sympas en plus, dans l'optique de tor. C'est à dire, un peu plus d'appels interceptés, et il ne grogne pas quand il voit un .onion.
Et même dans le second cas, on va s'apercevoir que les requêtes DNS passent à côté par exemple.
Avec SOCKS 5 (et 4a) elles ne devraient pas passer à coté. Après il y a le risque d'un programme mal codé qui fait la résolution DNS dans tout les cas, c'est pour cela que je préfère en règle générale de passer via tsocks, car lui je sais qu'il fait le boulot.
Déjà je me pose des questions sur le -x. J'utilise la variante openbsd de netcat et le -x. Enfin…
Ma seconde intérogation est socks4. Avec socks4, la résolution doit forcément être faite avant l'utilisation du proxy. Donc niveau anonymat, c'est bof.
Et enfin mon intérogation finale est la suivante : avec socks4a et socks5, netcat fait t'il la résolution avant d'utiliser le proxy, où utilise t'il directement le proxy ?
Comme TOR ouvre une proxy SOCKS sur ta machine, il suffit donc que ton application ne gère par particulièrement TOR, mais les proxy SOCKS, déjà ça élargie la gamme.
De plus si une application ne gère par les proxy socks, et qu'elle est dynamiquement liée, un outil génial comme tsocks fonctionne très bien. Il charge le programme avec un LD_PRELOAD qui fait le boulot d'interception et de redirection du traffic réseau vers le proxy SOCKS.
Tout dépend du but recherché. Le but de TOR, ce n'est pas de masquer le contenu, c'est de marquer la source du contenu.
S'il s'agit de publier des informations dans un pays répressif par exemple, l'objectif n'est pas de protéger le contenu, mais l'identité de celui qui en est à l'origine.
Mais vous, vous enverrez un journal pour quelqu'un ?
Comprendre pour toi ?
Oui, mais mes conditions sont beaucoup plus strictes que celles de Marotte (sans vouloir mettre en defaut Marotte, je l'ai trouvé trop cool sur ce coup là) :
un journal traitant un sujet précis,
un journal assez long et bien rédigé,
un journal structuré,
une pensée argumentée, ou un travail construit,
sous licence CC-BY, et dès que tu me l'envoie par mail,
dans un mail signé avec une clef OpenPGP dont le fpr aura été publié sur ton compte.
Pour les 4 premiers points, je te répondrais en indiquant quels sont les défauts, autant d'aller-retours que necessaires seront effectués. Pour les deux derniers, je jetterai le mail.
Bon, en réalité j'ai été un peu présompteux, à la vérification, mon max, c'est sur les 4 derniers et les deux premiers octets, il manque encore deux octets.
Sur ma machine (elle a quelques années) j'arrive à tester 15⋅106 clefs/seconde, il en faudrait 40000 pendant un an en espérance. Rien d'irréalisable, surtout avec des machines modernes. Bref, il y a 20 octets dans le fpr, en utiliser que 8 est une débilité sans nom.
J'ai pas pu éditer mon commentaire précedent, oui je suis lent.
Il faudrait une vérification par LinuxFr.org en envoyant un message chiffré sur l'adresse associée au compte, pour vérifier que la personne qui a le compte a bien aussi la clé GPG qu'elle déclare (par contre elle a pu mentir en déclarant une adresse de courriel trompeuse genre elvis.presley@). Et potentiellement vérifier chacune des adresses de courriel de la clé.
Ça dépend ce que garanti LinuxFR.org vis-à-vis de la clef. Il y a deux options :
LinuxFR.org garantit que la clef est celle de l'utilisateur (et l'a verifié).
LinuxFR.org garantit que le fpr est celui saisi par l'utilisateur.
Le premier schema consiste à transformer dlfp en autorité de certification, le seconde consiste à permettre aux membres d'exposer une information sans la modifier. Le second schema suffit au problème initial, et est ce que j'entendais dans mon entrée de suivi.
Posté par jben .
En réponse à l’entrée du suivi Empreinte OpenPGP dans son profil.
Évalué à 2 (+0/-0).
Dernière modification le 02 juillet 2013 à 23:40.
Le long id suffit. Ta démonstration ne donne pas jusque là deux long id identiques (juste deux short id identiques, ce qui est déjà connu et documenté).
non le long id ne suffit pas. Si on utilise 20 octets, il y a une raison. Sur mon journal je ne match que le short id, mais matcher le long id ça prends juste plus de temps mais c'est faisable. Depuis mon dernier journal j'ai largement amélioré la vitesse, il suffit d'utiliser les proprieté de sha1. (Un facteur 20 de mémoire). Enfin j'ai déja obtenue des collision volontaires sur les 4 premiers et 4 derniers octets, donc obtenir une collision sur les 8 derniers, c'est pas la mort, c'est long, mais faisable avec mes pauvres ressources.
Comme preuve, j'ai lancé une recherche de collision sur les 8 derniers octets de ta clef ;-).
Soit tu récupère l'integralité de la clef sur dlfp si possible, soit si dlfp ne propose que le fpr tu récupère la clef sur un serveur de clef et tu l'importes. Une fois importé tu calcule son fpr, tu le compare avec celui revendiqué par l'utilisateur kadalka de dlfp, si ça matche tu local-sign. (Pour ce genre de signature, il n'est pas recommandé de publié la signature, ce n'est pas une vérification de visu, c'est une vérification conditionnelement à dlfp).
C'est pareil qu'avec le code dans un commentaire, si il note dans un commentaire son fpr ou dans son profil (imaginons que dlfp trouve mon idée géniale, ce que je pense qu'elle est), alors si tu récupère une clef qui n'est pas celle de kadalka mais que tu as accepté :
quelqu'un a été capable de générer une clef avec le même fpr, oups c'est le modèle de clef OpenPGP version 4 qu'il faut jeter,
un admin dlfp a modifié le commentaire/profil (même point que tu avais relevé)
tu t'es laissé berné par un fpr approchant, tu n'as que ce que tu mérites. Et hop, de l'autopub
L'empreinte ne sert pas à cela. L'identifiant de la clé (genre 618D63E9) est suffisant pour juste se dire que si Oumph sur LinuxFr.org a collé 618D63E9 dans son profil utilisateur, c'est qu'il accepterait de recevoir des courriels chiffrés pour cette clé (à supposer qu'on soit capable de trouver son adresse de courriel, ce que son profil ne fournit pas de base, mais sa clé GPG l'indique sûrement si elle est publiée sur un serveur de clés).
Non avec le short id tu n'es pas sûr d'avoir la bonne clef. Je m'auto-réferencie : cf. un de mes journaux
Pas exactement, car en mettant l'intégralité de la clef (ou son empreinte), on a l'info suivante : l'utilisateur Oumph de LinuxFR.org revendique la possession de la clef en question. Si tu as mis une clef de fingerprint fpr sur ton profil, je ne pourrais pas envoyer un courrier signé disant je suis Oumph de LinuxFR.org sauf si je parviens à obtenir une clef de même fpr que toi.
A contrario si quelqu'un reçoit un courriel signé avec la clé 618D63E9, le simple fait que cette clé soit mentionné sur le profil de Oumph sur LinuxFr.org ne devrait pas lui suffire à croire que c'est une seule et même personne (car Mallaury pourrait très bien mettre 618D63E9 sur son profil aussi).
Dans ce cas ça veut dire que Mallaury accèpte le fait que tu puisses te faire passer pour lui. C'est pareil que sur une carte de visite, je peux mettre la clef de quelqu'un d'autre, c'est crétin, mais je peux.
Surtout le problème de ne mettre que le short id (les 4 derniers octets du fpr) ou le long id (8 derniers octets du fpr), c'est qu'il est aisé de générer des clef qui ont même id. Allez je me fait de la pub deux fois : cf. un de mes journaux.
[^] # Re: La solution est pourtant simple !
Posté par jben . En réponse au journal OVH sous le coup d'un acte de piraterie. Évalué à 3.
Oh que non, une chaîne de Markov d'ordre 1 basée sur des transitions sur le clavier peut générer cela très facilement…
[^] # Re: Une fois la clé perdue ?
Posté par jben . En réponse au journal Présentation d'idée : PGPID. Évalué à 3.
Dans le cas où elle est sur un support statique (et chiffrée avec une passphrase) le problème de compromission est bien moindre. Après pour le problème de perte, rien ne t'empêche de la distribuer selon un secret partagé de Shamir.
[^] # Re: Une fois la clé perdue ?
Posté par jben . En réponse au journal Présentation d'idée : PGPID. Évalué à 5.
OpenPGP fournit déjà un mechanisme de sous-clef complètement satisfaisant sans à avoir à réinventer la roue.
Un usage raisonné d'OpenPGP consiste à génerer une clef secondaire de signature (et une clef secondaire de chiffrement), d'exporter la partie privée clefs en détruisant la partie privée de la clef principale, et d'utiliser cette version pour un usage quotidien. La clef privée complète est quant à elle écrite sur un support passif ou sur une machine déconnectée du réseau.
En cas de compromission, les sous-clefs sont révoqués, de nouvelles sont générés et signées par la clef principale.
La clef principale n'est utilisé (sauf compromission des sous-clefs) que pour renouveller les sous-clefs ou pour étendre son réseau de confiance.
[^] # Re: le pasclient, c'est encore mieux!
Posté par jben . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
En parlant de TikZ et de graphviz dans le même thread, il y a dot2tex qui permet de génerer du code LaTeX utilisant PGF/TikZ à partir du résultat de graphviz. C'est tout simplement génial.
# Arbre de décision
Posté par jben . En réponse au journal ChooseALicense.com. Évalué à 6.
Il y a une chose dont je reverai à propos du choix des licences : un arbre de décision.
Genre
(Aucune garantie de véracité sur l'arbre d'exemple proposé).
[^] # Re: elle est connue
Posté par jben . En réponse au journal Gnu/Linux est une passoire. Évalué à 3.
Exacte, j'utilise pentadactyl sur une machine et vimperator sur les autres, et les deux ont ce comportement.
[^] # Re: elle est connue
Posté par jben . En réponse au journal Gnu/Linux est une passoire. Évalué à 5.
Mon navigateur m'affiche en bas, Yanked: "something", quand je copie un truc. Après, si je decide de le coller quelque part, c'est mon choix.
[^] # Re: nonce
Posté par jben . En réponse au journal Comment fonctionne Bitcoin. Évalué à 2.
Je ne vous pas pourquoi, du moment qu'il commence à un endroit aléatoire, ça semble même être mieux.
Bref, il semble même plus judicieux de tirer séquentiellement que à partir d'une position aléatoire. (Et en plus comme sha256 est un algo par bloc, on peut même avoir un avantage à ne pas recalculer depuis le début du sel pour aller plus vite, encore faut-il que le sel soit à la fin du machin à calculer, j'espère que non sinon c'est trop facile).
Après il ne faut pas oublier qu'on est en train de parler de proba qui sont très très petite, et même très très inférieure à la proba de trouver un sel valide, je m'excuse par avance auprès de la confrérie des mouches.
[^] # Re: nonce
Posté par jben . En réponse au journal Comment fonctionne Bitcoin. Évalué à 2. Dernière modification le 12 juillet 2013 à 16:05.
Justement, de loin, (je ne connais que rapidement le fonctionnement de bitcoin), ça a l'air d'un sel et non d'un nonce. La caractéristique d'un nonce c'est qu'il ne doit pas être réutilisé, on l'introduit pour éviter tout ce qui est du genre replay.
Y-a-t'il se genre de restriction, ou c'est juste un sel ?
[^] # Re: Facile
Posté par jben . En réponse au message Question théorique sur les clefs USB. Évalué à 4.
Ça dépend comment tu défini necessaire.
Si c'est necessaire pour les programmes, alors oui, 512 MiB suffisent largement. Si c'est necessaire à un bon fonctionnement fluide, 2 GiB sont souvent appréciable, même sur un netbook, ainsi beaucoup de lectures se font sur le cache, les écritures peuvent se faire bufferiser largement…
[^] # Re: Utiliser Tor
Posté par jben . En réponse au journal Oignons sur la route. Évalué à 4.
J'en profite pour parler de
torsocks
, qui fonctionne pareil quetsocks
, mais qui à quelques patches sympas en plus, dans l'optique de tor. C'est à dire, un peu plus d'appels interceptés, et il ne grogne pas quand il voit un.onion
.[^] # Re: Utiliser Tor
Posté par jben . En réponse au journal Oignons sur la route. Évalué à 3.
Avec SOCKS 5 (et 4a) elles ne devraient pas passer à coté. Après il y a le risque d'un programme mal codé qui fait la résolution DNS dans tout les cas, c'est pour cela que je préfère en règle générale de passer via tsocks, car lui je sais qu'il fait le boulot.
[^] # Re: Utiliser Tor
Posté par jben . En réponse au journal Oignons sur la route. Évalué à 5.
Je ne sais pas bien.
X
étant setuid root, je ne sais pas si la variable d'environnementLD_PRELOAD
n'est pas perdue en route.Par contre pour que avoir la variable dans ton environnement, rien ne t'empeche de mettre dans ton
.xinitrc
où.Xsession
, un truc du genre :# Quelques interrogation sur la résolution des noms
Posté par jben . En réponse au journal Oignons sur la route. Évalué à 5. Dernière modification le 09 juillet 2013 à 10:04.
Déjà je me pose des questions sur le
-x
. J'utilise la variante openbsd de netcat et le-x
. Enfin…Ma seconde intérogation est
socks4
. Avec socks4, la résolution doit forcément être faite avant l'utilisation du proxy. Donc niveau anonymat, c'est bof.Et enfin mon intérogation finale est la suivante : avec socks4a et socks5, netcat fait t'il la résolution avant d'utiliser le proxy, où utilise t'il directement le proxy ?
[^] # Re: Utiliser Tor
Posté par jben . En réponse au journal Oignons sur la route. Évalué à 4.
Comme TOR ouvre une proxy SOCKS sur ta machine, il suffit donc que ton application ne gère par particulièrement TOR, mais les proxy SOCKS, déjà ça élargie la gamme.
De plus si une application ne gère par les proxy socks, et qu'elle est dynamiquement liée, un outil génial comme
tsocks
fonctionne très bien. Il charge le programme avec unLD_PRELOAD
qui fait le boulot d'interception et de redirection du traffic réseau vers le proxy SOCKS.[^] # Re: Utiliser Tor
Posté par jben . En réponse au journal Oignons sur la route. Évalué à 6.
Tout dépend du but recherché. Le but de TOR, ce n'est pas de masquer le contenu, c'est de marquer la source du contenu.
S'il s'agit de publier des informations dans un pays répressif par exemple, l'objectif n'est pas de protéger le contenu, mais l'identité de celui qui en est à l'origine.
[^] # Re: Rendez moi le thème précédent !
Posté par jben . En réponse au journal Le thème surprise de linuxfr.org ce soir.. Évalué à 2. Dernière modification le 05 juillet 2013 à 23:16.
Le changement de style est une fonctionnalitée reservées aux utilisateurs connectés.
Toutefois tu peux localement (c.-à-d. au niveau de ton navigateur) changer de style avec un script Greasemonkey. Cf. un de mes commentaires précedent sur cette page.
[^] # Re: Changer de style
Posté par jben . En réponse au journal Le thème surprise de linuxfr.org ce soir.. Évalué à 8. Dernière modification le 04 juillet 2013 à 12:03.
Allez hop, un contournement (mal écrit, et à l'arrache mais bon). Un script Greasemonkey :
… et linuxfr redevient utilisable.
[^] # Re: Changer de style
Posté par jben . En réponse au journal Le thème surprise de linuxfr.org ce soir.. Évalué à 10.
Tu n'es pas le seul. Je trouve personnellement ce style immonde, et inutilisable.
Qu'il existe, soit, ça ne me pose pas de problèmes, mais qu'on me l'impose, je dis non. Tous avec moi pour le non !
[^] # Re: Question
Posté par jben . En réponse au journal et hop, une nouvelle version de qy.share : multisites !. Évalué à 2.
Comprendre pour toi ?
Oui, mais mes conditions sont beaucoup plus strictes que celles de Marotte (sans vouloir mettre en defaut Marotte, je l'ai trouvé trop cool sur ce coup là) :
Pour les 4 premiers points, je te répondrais en indiquant quels sont les défauts, autant d'aller-retours que necessaires seront effectués. Pour les deux derniers, je jetterai le mail.
Je te laisse le soin de trouver mon mail.
[^] # Re: Hmm
Posté par jben . En réponse à l’entrée du suivi Empreinte OpenPGP dans son profil. Évalué à 2 (+0/-0).
Bon, en réalité j'ai été un peu présompteux, à la vérification, mon max, c'est sur les 4 derniers et les deux premiers octets, il manque encore deux octets.
Sur ma machine (elle a quelques années) j'arrive à tester 15⋅106 clefs/seconde, il en faudrait 40000 pendant un an en espérance. Rien d'irréalisable, surtout avec des machines modernes. Bref, il y a 20 octets dans le fpr, en utiliser que 8 est une débilité sans nom.
[^] # Re: Hmm
Posté par jben . En réponse à l’entrée du suivi Empreinte OpenPGP dans son profil. Évalué à 2 (+0/-0).
J'ai pas pu éditer mon commentaire précedent, oui je suis lent.
Ça dépend ce que garanti LinuxFR.org vis-à-vis de la clef. Il y a deux options :
Le premier schema consiste à transformer dlfp en autorité de certification, le seconde consiste à permettre aux membres d'exposer une information sans la modifier. Le second schema suffit au problème initial, et est ce que j'entendais dans mon entrée de suivi.
[^] # Re: Hmm
Posté par jben . En réponse à l’entrée du suivi Empreinte OpenPGP dans son profil. Évalué à 2 (+0/-0). Dernière modification le 02 juillet 2013 à 23:40.
non le long id ne suffit pas. Si on utilise 20 octets, il y a une raison. Sur mon journal je ne match que le short id, mais matcher le long id ça prends juste plus de temps mais c'est faisable. Depuis mon dernier journal j'ai largement amélioré la vitesse, il suffit d'utiliser les proprieté de sha1. (Un facteur 20 de mémoire). Enfin j'ai déja obtenue des collision volontaires sur les 4 premiers et 4 derniers octets, donc obtenir une collision sur les 8 derniers, c'est pas la mort, c'est long, mais faisable avec mes pauvres ressources.
Comme preuve, j'ai lancé une recherche de collision sur les 8 derniers octets de ta clef ;-).
[^] # Re: Bonne idée
Posté par jben . En réponse à l’entrée du suivi Empreinte OpenPGP dans son profil. Évalué à 2 (+0/-0).
Soit tu récupère l'integralité de la clef sur dlfp si possible, soit si dlfp ne propose que le fpr tu récupère la clef sur un serveur de clef et tu l'importes. Une fois importé tu calcule son fpr, tu le compare avec celui revendiqué par l'utilisateur kadalka de dlfp, si ça matche tu local-sign. (Pour ce genre de signature, il n'est pas recommandé de publié la signature, ce n'est pas une vérification de visu, c'est une vérification conditionnelement à dlfp).
C'est pareil qu'avec le code dans un commentaire, si il note dans un commentaire son fpr ou dans son profil (imaginons que dlfp trouve mon idée géniale, ce que je pense qu'elle est), alors si tu récupère une clef qui n'est pas celle de kadalka mais que tu as accepté :
[^] # Re: Hmm
Posté par jben . En réponse à l’entrée du suivi Empreinte OpenPGP dans son profil. Évalué à 3 (+0/-0).
Non avec le short id tu n'es pas sûr d'avoir la bonne clef. Je m'auto-réferencie : cf. un de mes journaux
Pas exactement, car en mettant l'intégralité de la clef (ou son empreinte), on a l'info suivante : l'utilisateur Oumph de LinuxFR.org revendique la possession de la clef en question. Si tu as mis une clef de fingerprint fpr sur ton profil, je ne pourrais pas envoyer un courrier signé disant je suis Oumph de LinuxFR.org sauf si je parviens à obtenir une clef de même fpr que toi.
Dans ce cas ça veut dire que Mallaury accèpte le fait que tu puisses te faire passer pour lui. C'est pareil que sur une carte de visite, je peux mettre la clef de quelqu'un d'autre, c'est crétin, mais je peux.
Surtout le problème de ne mettre que le short id (les 4 derniers octets du fpr) ou le long id (8 derniers octets du fpr), c'est qu'il est aisé de générer des clef qui ont même id. Allez je me fait de la pub deux fois : cf. un de mes journaux.