(Ah oui, et je sais aussi que je n’ai que très modérément confiance dans la plupart des courbes elliptiques dont les paramètres ont été judicieusement choisis — mais judicieusement pour qui ? — sur des critères non-spécifiés…)
Il me semble aussi que certain cryptographe se demande si la NSA n'aurait pas déjà cassé de l'ECC. C'est pour ça qu'il mette en avant RSA qui est solide depuis des années.
(menaces probablement à la fois plus nombreuses et plus crédibles qu’une attaque matérielle).
C'est vrai :)
J'imagine que le plus dure est de gérer l'accès à la carte quand elle est connecté sur un ordinateur. Mais c'est censé être rare.
Le plus simple pour qu'une carte résiste est que son contenu soit relativement unique. En général, il faut plusieurs carte pour briser leur sécurité, ce qui n'est pas le cas avec une clef privé par carte.
Concernant le token, est-ce que vous avez tenu compte que cela peut être plus ou moins facile de récupérer les secrets d'une carte à puce ? (cf les cartes à puce de décodeurs satellites)
Une carte à puce est un ordinateur très simple dont on peut observer le fonctionnement. Et je ne parle pas des bêtes failles de débordement de buffer qui peuvent permettre de lire complètement la mémoire et donc la clef privée.
Si le pire est la perte de la Sous-clef de chiffrement, il faudrait la protéger au moins autant que la clef primaire non ?
Ou alors, il faudrait une clef de signature de plus, gérer par un token, sans que cette clef n'y sortent jamais (je pars du principe que chiffrer dans un token est trop lent).
Ou alors, il faut révoquer périodiquement cette sous clef.
Je ne sais pas si c'est vrai, mais il semble que le taux d'usage des cpu dans les petits cluster x86 (~100 machines) ne dépasse pas 10% de taux d'occupation à cause de l'attente des transfert réseau.
En gros, dans les clusters x86, cela serait la latence des IO qui coince.
D'après la source, pour rester dans la course technologique, les allemands ont sous traité au américain, et ont fermé les yeux, quand ils ont vu qu'ils ne contrôlaient plus rien.
J'imagine que les services sont un peu en roues libres, et contre des informations antiterroristes, ils sont prêt à donner n'importe quoi. J'imagine que l'accès à Xkeyscore n'était pas gratuit non plus (le moteur de recherche dans toutes les données captées).
" (mot de passe à changer, internet limité, interdire les clé USB…)"
Ceux qui prennent ce genre de mesure oublie que l'on doit travailler. Cela me rappelle un bocal sans réseau extérieur, ni clef usb : mais comment faire pour lire les specs ?!
Le pourquoi peut être compris, mais c'est insupportable au quotidien. Ou alors, il faut fournir 2 machines, l'une pour le dev, l'autre pour trouver des informations sur internet. Mais en général, les directions sont trop pingres pour faire ça.
"Mais peut-on objectivement penser que tous les employés qui vont passer sont digne de confiance ? L’équilibre à trouver ne me semble pas simple."
Non, si un personne veut vraiment faire sortir des infos, elle peut booter sur un liveCD ou autre, et recopier des fichiers, ou même démonter un disque dur.
Pour éviter ce genre de cas, ces mesures de sécurité font chi… tous les jours les personnes honnêtes qui veulent faire leur boulot.
Mais personne n'a envie de payer les 500 à 700€ de la machine au début. Ensuite, personne ne veut l'entretenir (laver, nettoyer, rincer…). C'est plus de long de faire du café, etc…
C'est la tragédie des communs : personne n'aime s'en occuper. Donc, un café cher, et une cafetière jetable, cela marche bien. Si le café était mauvais, cela serait à revoir, mais ce n'est pas le cas.
Oui, à condition de maitriser les installation des navigateurs pour leur changer leur certificat racine. Sinon, cela ne marche pas sans démarche illégale.
D'ailleurs, je pense même que mettre des proxy espion menteur TLS, est à la limite de la légalité, le jour ou une affaire sort suite à l'espionnage des ces connexions, la boite risque d'avoir mal. (donné bancaire, mail perso syndical ou médical,…). Personne n'acceptera un enregistrement de ses conversations au téléphone pro, alors pourquoi l’accepter sur internet ?
Oui, dans la réalité le cache n'est ni chaud ni froid, mais tiède (sauf donnés >10Mo). L'idéal est de bencher un code réel.
En général, je teste le pire cas : cache froid (== cela sera toujours plus rapide en vrai, et tu vois les effets d'optimisation type tilling). Je fais une courbe, et jamais de moyenne, cela permet de voir visuellement tous les effets que tu cites en python (gc…).
Dans un projet libre, le plus important est le courage et l’obstination du mainteneur, il n'y a que ça pour maintenir le projet en vie. On le voit bien avec le mainteneur de GPG par exemple. A coté de ça, la structure téchnique d'un projet est secondaire.
Concernant les patchs, changer de structure de base nécessitait de tout reprendre, on ne commence pas une contribution en cassant tout. Je suis passé à autre chose. Et concernant les critiques, tu n'en as pas eu le dixième de ce que l'on a pu prendre sur le tête pour Lisaac. Le mainteneur en a eu marre et a coupé tout contact, et le projet est mort.
Ton projet est très utile, tu arrives à secouer Gimp, qui le méritait bien, et maintenant tu va au-delà. C'est bien plus important que les querelles techniques.
"(Ce message est aussi valable pour N. Boulay, qui depuis quelques années, à chaque news Linuxfr sur G'MIC en profite sur donner son avis sur la bonne façon de programmer. Depuis le temps, il aurait donc eu le temps de contribuer d'une manière ou d'un autre au projet pour nous remettre dans le "droit chemin", mais on a jamais eu de nouvelles, on attend toujours)."
Cela fait longtemps que je n'essayes plus de te convaincre. C'est ton projet, tu fais ce que tu veux. J'avais juste trouver génial la façon d'utiliser la lib pour faire du traitement d'image, et parfaitement horrible le code de la lib. D'ailleurs, je t'avais filé un mini patch qui a augmenté les perfs de 5 à 10% si je me rappelle bien.
Par exemple, la structure mémoire de l'image n'était pas un objet à part des traitements, il était ainsi impossible de changer le layout mémoire sans devoir réécrire tous les traitements. Je voulais tenter une organisation en "tile", voir rendre possible l’auto-vectorisation. Mais cela a été impossible à faire.
En même temps, il y a plein de trucs sous emacs qui manque sous d'autre IDE (selection carré, killing ring, recherche à la volé (qui existe maintenant sous firefox), autocomplétion (mais moins bien que eclipse)…)
"Après, reste l’argument du « je suis le mainteneur du projet, et c’est comme ça que je trouve que c’est le plus simple et le plus adapté à mon cas d’utilisation ». Et là, il n’y a rien à redire."
La discussion a lieu à chaque release. Donc, je n’insiste pas plus que ça.
Bon travail ! Vu le nombre de fautes que j'écris, je pensais en écrire un, un jour :)
Juste une suggestion à faire entre le préprocesseur et le passage des règles : pourquoi ne pas chercher à étiqueter chaque mots avec son type grammatical précis ? Cela aiderait beaucoup les règles suivantes. Tu te bases uniquement sur le mot pour faire ton choix, mais si tu prends une phrase entière, les choix réels diminuent fortement.
Ensuite, tu peux utiliser quelques heuristiques (niveau de langage du reste du texte, qui permet de choisir une des signification plutôt qu'une autre, domaine de langage du reste, etc…).
Au lieu de chercher à réduire à une étiquette par mot, je laisserai l'ensemble des possibles (pourquoi pas avec un pourcentage de probabilité) et je couperais les étiquettes fausses si on prend la phrase entière. Les probabilités peuvent servir pour trier les suggestions de correction.
J'ai juste une remarque sur ton bench : "10 boucles et moyennes de 3 meilleurs".
Si tu traces une courbe des temps d’exécution de chaque boucle, tu verras un temps décroissant sur les 3 ou 4 premières exécution puis un plateau, et parfois des pics (allocation mémoire, switch de contexte…).
En fait, tu remplit tes caches, et ensuite, ils sont "chaud", le code est ainsi le plus rapide. Mais c'est loin de la réalité. Dans la réalité, tu ne ré-exécutes jamais le même code sur les même données 2 fois de suite.
Ce genre de bench ne permet pas d'estimer tout code d'optimisation d'usage du cache (tiling, accès linéaire à la mémoire,…).
A l'inverse, si tu nettoies complètement les caches (boucles entre 2 exécutions sur des données externes). Tu te places dans un pire cas : le cache "froid". Ce n'est peut être pas non plus réaliste.
Dans tous les cas, je préfère utiliser une courbe (ici tu aurais 10 points). Tu as 3 cas, donc 3 courbes. Tu peux voir l'efficacité de la 1er exécution, l'augmentation de perf ensuite, et visualiser tous problèmes avec les données (point aberrant dû à changement de contexte par exemple)
[^] # Re: OpenPGP, libsodium...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 3.
Il me semble aussi que certain cryptographe se demande si la NSA n'aurait pas déjà cassé de l'ECC. C'est pour ça qu'il mette en avant RSA qui est solide depuis des années.
"La première sécurité est la liberté"
[^] # Re: Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
C'est vrai :)
J'imagine que le plus dure est de gérer l'accès à la carte quand elle est connecté sur un ordinateur. Mais c'est censé être rare.
Le plus simple pour qu'une carte résiste est que son contenu soit relativement unique. En général, il faut plusieurs carte pour briser leur sécurité, ce qui n'est pas le cas avec une clef privé par carte.
"La première sécurité est la liberté"
[^] # Re: Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Concernant le token, est-ce que vous avez tenu compte que cela peut être plus ou moins facile de récupérer les secrets d'une carte à puce ? (cf les cartes à puce de décodeurs satellites)
Une carte à puce est un ordinateur très simple dont on peut observer le fonctionnement. Et je ne parle pas des bêtes failles de débordement de buffer qui peuvent permettre de lire complètement la mémoire et donc la clef privée.
"La première sécurité est la liberté"
# Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Si le pire est la perte de la Sous-clef de chiffrement, il faudrait la protéger au moins autant que la clef primaire non ?
Ou alors, il faudrait une clef de signature de plus, gérer par un token, sans que cette clef n'y sortent jamais (je pars du principe que chiffrer dans un token est trop lent).
Ou alors, il faut révoquer périodiquement cette sous clef.
"La première sécurité est la liberté"
[^] # Re: Court circuit
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 4.
Je ne sais pas si c'est vrai, mais il semble que le taux d'usage des cpu dans les petits cluster x86 (~100 machines) ne dépasse pas 10% de taux d'occupation à cause de l'attente des transfert réseau.
En gros, dans les clusters x86, cela serait la latence des IO qui coince.
"La première sécurité est la liberté"
[^] # Re: Utiliser Tor, faire tourner un nœud freenet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal boitenoirekiller.com veut pourrir les boites noires de la DCRI. Évalué à 2.
Le principe même des noeuds de sortie Tor pose problème. Il faudrait surtout développé la parti "service caché" des site web.
"La première sécurité est la liberté"
[^] # Re: Autre initiative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal boitenoirekiller.com veut pourrir les boites noires de la DCRI. Évalué à 2.
Si OC déménage, cela peut marquer certain !
"La première sécurité est la liberté"
[^] # Re: Statistiquement détectable
Posté par Nicolas Boulay (site web personnel) . En réponse au journal boitenoirekiller.com veut pourrir les boites noires de la DCRI. Évalué à 1.
Il n'y a pas de générateur de texte pour faire des phrases différentes ?
"La première sécurité est la liberté"
[^] # Re: A qui profite le crime ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Snowden : Les services secrets allemands auraient espionné Airbus pour la NSA. Évalué à 5.
D'après la source, pour rester dans la course technologique, les allemands ont sous traité au américain, et ont fermé les yeux, quand ils ont vu qu'ils ne contrôlaient plus rien.
"La première sécurité est la liberté"
[^] # Re: A qui profite le crime ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Snowden : Les services secrets allemands auraient espionné Airbus pour la NSA. Évalué à 3.
la source en anglais :
http://www.spiegel.de/international/germany/bnd-intelligence-scandal-puts-merkel-in-tight-place-a-1031944.html
"La première sécurité est la liberté"
[^] # Re: A qui profite le crime ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Snowden : Les services secrets allemands auraient espionné Airbus pour la NSA. Évalué à 6.
J'imagine que les services sont un peu en roues libres, et contre des informations antiterroristes, ils sont prêt à donner n'importe quoi. J'imagine que l'accès à Xkeyscore n'était pas gratuit non plus (le moteur de recherche dans toutes les données captées).
"La première sécurité est la liberté"
[^] # Re: Mauvais problème
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 2.
" (mot de passe à changer, internet limité, interdire les clé USB…)"
Ceux qui prennent ce genre de mesure oublie que l'on doit travailler. Cela me rappelle un bocal sans réseau extérieur, ni clef usb : mais comment faire pour lire les specs ?!
Le pourquoi peut être compris, mais c'est insupportable au quotidien. Ou alors, il faut fournir 2 machines, l'une pour le dev, l'autre pour trouver des informations sur internet. Mais en général, les directions sont trop pingres pour faire ça.
"Mais peut-on objectivement penser que tous les employés qui vont passer sont digne de confiance ? L’équilibre à trouver ne me semble pas simple."
Non, si un personne veut vraiment faire sortir des infos, elle peut booter sur un liveCD ou autre, et recopier des fichiers, ou même démonter un disque dur.
Pour éviter ce genre de cas, ces mesures de sécurité font chi… tous les jours les personnes honnêtes qui veulent faire leur boulot.
"La première sécurité est la liberté"
[^] # Re: Mauvais problème
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 5.
Ne pas prendre ses employés pour des cons, leur faire confiance, leur donner les moyens de travailler, cela marche mieux à mon avis.
"La première sécurité est la liberté"
[^] # Re: Mauvais problème
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
Si les boites n'ont pas besoin de faire de l'usurpation d'identité pour avoir le certificat, le problème est donc dans le système de certificat.
"La première sécurité est la liberté"
[^] # Re: Machine a expresso a grain
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Enfin une solution pour du café libre au boulot.. Évalué à 4.
Si.
Mais personne n'a envie de payer les 500 à 700€ de la machine au début. Ensuite, personne ne veut l'entretenir (laver, nettoyer, rincer…). C'est plus de long de faire du café, etc…
C'est la tragédie des communs : personne n'aime s'en occuper. Donc, un café cher, et une cafetière jetable, cela marche bien. Si le café était mauvais, cela serait à revoir, mais ce n'est pas le cas.
"La première sécurité est la liberté"
[^] # Re: Mauvais problème
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
La cnil depuis le changement de président, c'est du grand n'importe quoi.
"La première sécurité est la liberté"
[^] # Re: Machine a expresso a grain
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Enfin une solution pour du café libre au boulot.. Évalué à 2.
On est à 8000 cafés par an depuis 2 ans, avec une Nespresso 1er prix, qui a du coûter 50€.
"La première sécurité est la liberté"
[^] # Re: Mauvais problème
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
Oui, à condition de maitriser les installation des navigateurs pour leur changer leur certificat racine. Sinon, cela ne marche pas sans démarche illégale.
D'ailleurs, je pense même que mettre des proxy espion menteur TLS, est à la limite de la légalité, le jour ou une affaire sort suite à l'espionnage des ces connexions, la boite risque d'avoir mal. (donné bancaire, mail perso syndical ou médical,…). Personne n'acceptera un enregistrement de ses conversations au téléphone pro, alors pourquoi l’accepter sur internet ?
"La première sécurité est la liberté"
[^] # Re: Mauvais problème
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
Cela n'est vrai que pour les pays puissant, il y a plein de pays en dictature ou presque, qui n'ont pas les moyens de faire ça.
"La première sécurité est la liberté"
[^] # Re: micro bench dans une loupe
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.7 - PyDataParis. Évalué à 3.
Oui, dans la réalité le cache n'est ni chaud ni froid, mais tiède (sauf donnés >10Mo). L'idéal est de bencher un code réel.
En général, je teste le pire cas : cache froid (== cela sera toujours plus rapide en vrai, et tu vois les effets d'optimisation type tilling). Je fais une courbe, et jamais de moyenne, cela permet de voir visuellement tous les effets que tu cites en python (gc…).
"La première sécurité est la liberté"
[^] # Re: color2gray et organisation du code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 8.
Dans un projet libre, le plus important est le courage et l’obstination du mainteneur, il n'y a que ça pour maintenir le projet en vie. On le voit bien avec le mainteneur de GPG par exemple. A coté de ça, la structure téchnique d'un projet est secondaire.
Concernant les patchs, changer de structure de base nécessitait de tout reprendre, on ne commence pas une contribution en cassant tout. Je suis passé à autre chose. Et concernant les critiques, tu n'en as pas eu le dixième de ce que l'on a pu prendre sur le tête pour Lisaac. Le mainteneur en a eu marre et a coupé tout contact, et le projet est mort.
Ton projet est très utile, tu arrives à secouer Gimp, qui le méritait bien, et maintenant tu va au-delà. C'est bien plus important que les querelles techniques.
"La première sécurité est la liberté"
[^] # Re: color2gray et organisation du code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 3.
Cela fait longtemps que je n'essayes plus de te convaincre. C'est ton projet, tu fais ce que tu veux. J'avais juste trouver génial la façon d'utiliser la lib pour faire du traitement d'image, et parfaitement horrible le code de la lib. D'ailleurs, je t'avais filé un mini patch qui a augmenté les perfs de 5 à 10% si je me rappelle bien.
Par exemple, la structure mémoire de l'image n'était pas un objet à part des traitements, il était ainsi impossible de changer le layout mémoire sans devoir réécrire tous les traitements. Je voulais tenter une organisation en "tile", voir rendre possible l’auto-vectorisation. Mais cela a été impossible à faire.
"La première sécurité est la liberté"
[^] # Re: color2gray et organisation du code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 2.
En même temps, il y a plein de trucs sous emacs qui manque sous d'autre IDE (selection carré, killing ring, recherche à la volé (qui existe maintenant sous firefox), autocomplétion (mais moins bien que eclipse)…)
"Après, reste l’argument du « je suis le mainteneur du projet, et c’est comme ça que je trouve que c’est le plus simple et le plus adapté à mon cas d’utilisation ». Et là, il n’y a rien à redire."
La discussion a lieu à chaque release. Donc, je n’insiste pas plus que ça.
"La première sécurité est la liberté"
# joli travail !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 5.
Bon travail ! Vu le nombre de fautes que j'écris, je pensais en écrire un, un jour :)
Juste une suggestion à faire entre le préprocesseur et le passage des règles : pourquoi ne pas chercher à étiqueter chaque mots avec son type grammatical précis ? Cela aiderait beaucoup les règles suivantes. Tu te bases uniquement sur le mot pour faire ton choix, mais si tu prends une phrase entière, les choix réels diminuent fortement.
Ensuite, tu peux utiliser quelques heuristiques (niveau de langage du reste du texte, qui permet de choisir une des signification plutôt qu'une autre, domaine de langage du reste, etc…).
Au lieu de chercher à réduire à une étiquette par mot, je laisserai l'ensemble des possibles (pourquoi pas avec un pourcentage de probabilité) et je couperais les étiquettes fausses si on prend la phrase entière. Les probabilités peuvent servir pour trier les suggestions de correction.
"La première sécurité est la liberté"
# micro bench dans une loupe
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.7 - PyDataParis. Évalué à 10.
J'ai juste une remarque sur ton bench : "10 boucles et moyennes de 3 meilleurs".
Si tu traces une courbe des temps d’exécution de chaque boucle, tu verras un temps décroissant sur les 3 ou 4 premières exécution puis un plateau, et parfois des pics (allocation mémoire, switch de contexte…).
En fait, tu remplit tes caches, et ensuite, ils sont "chaud", le code est ainsi le plus rapide. Mais c'est loin de la réalité. Dans la réalité, tu ne ré-exécutes jamais le même code sur les même données 2 fois de suite.
Ce genre de bench ne permet pas d'estimer tout code d'optimisation d'usage du cache (tiling, accès linéaire à la mémoire,…).
A l'inverse, si tu nettoies complètement les caches (boucles entre 2 exécutions sur des données externes). Tu te places dans un pire cas : le cache "froid". Ce n'est peut être pas non plus réaliste.
Dans tous les cas, je préfère utiliser une courbe (ici tu aurais 10 points). Tu as 3 cas, donc 3 courbes. Tu peux voir l'efficacité de la 1er exécution, l'augmentation de perf ensuite, et visualiser tous problèmes avec les données (point aberrant dû à changement de contexte par exemple)
"La première sécurité est la liberté"