pshunter a écrit 132 commentaires

J'ai un peu répondu dans un post au-dessus : http://linuxfr.org/comments/595986.html#595986(...)

C'est sûr que la carte à puce est un peu plus sûre, mais pas énormément plus.

les opérations sensibles sont faites sur la carte dont tu as le contrôle
[...]
Une machine compromise peut demander à la carte de signer ce qu'elle veut

C'est surtout ça le problème, comme on ne peut pas vérifier ce qui est demandé à la carte, on est obligé d'exiger un ordinateur de confiance, et si l'ordi et fiable, une clé sur le disque dur est aussi en sécurité.

La solution évoquée plus haut et que je m'efforce de répandre autour de moi c'est de se baser sur les téléphones cellulaires, malheureusement on est déjà passé au stade où toutes leurs fonctionnalités débiles font qu'il y a déjà des virus pour ces plate-formes.

Mais non, c'est le client SMTP, sur la machine de la personne qui rédige le mail que le calcul est fait. La chaîne des serveurs n'est pas modifiée. L'absence du résultat du calcul dans le mail pourra entrer dans les critères du client du destinataire du mail pour le classer en spam.

Comparons la sécurité de la carte à puce et la sécurité d'une clé privée cryptée stockée sur un support amovible. Mon but est de montrer que contrairement à ce qu'on peut penser n'est pas "très largement supérieur", mais juste un peu supérieur.

Attaque 1 : vol de la carte/support

Pour extraire les infos de la carte à puce il faut entreprendre une analyse électronique difficile.

Pour récupérer la clé cryptée sur le support il faut casser le cryptage symétrique qui la protège. On peut attaquer le mot de passe ou directement les x bits de la clé symétrique.

La carte a puce est un peu supérieure car elle peut permettre de mettre un pass simple, en se verrouillant si trop d'essais sont faits, mais avec un pass correct retrouver la clé cryptée est très, très difficile.

Je considère de toute façon que les gens qui ont les moyens et la volonté de lancer ce genre de procédure de cassage ont les moyens de torturer la personne pour qu'elle leur donne le pass.

La carte à puce/support s'utilise sur un ordinateur normalement non vérolé

Attaque 2 : l'ordinateur utilisé n'est plus fiable, on en a plus le contrôle car il a été infesté par un virus/rootkité/etc

Pour utiliser les infos du support il faut les transférer sur l'ordinateur pour les décrypter avec le pass que donne l'utilisateur. Le programme malveillant va pouvoir intercepter le pass ou les infos décryptées quand l'utilisateur s'en sert ; puis s'en servir dans le dos de l'utilisateur.

Pour utiliser la carte, il faut un lecteur, mais on nepeut pas voir ce qui se passe entre l'ordinateur et le lecteur. Le programme malveillant peut demander à la carte de signer n'importe quoi dans le dos de l'utilisateur, soi en interceptant le code pin qu'il taperait au clavier, soit en remplaçant une requête légitime de l'utilisateur si le lecteur est muni d'un clavier.

Dans le cas de la carte à puce, on peut remarquer que l'attaque n'est réalisable que le temps que la carte reste dans le lecteur, mais le mal est fait donc question sécurité c'est pas top.

Le grand danger c'est qu'une grande part de la populace a une grande estime de la technologie carte à puce (cocorico) et qu'elle est souvent considérée et marketée comme de sécurité "très largement supérieure" alors que ce n'est pas du tout le cas. Un système sécurisé, c'est aussi quand les gens en connaissent les limites, ce qui est très rarement le cas, alors ne rajoutons pas de nouvelles illusions.

Je crois plutôt qu'il n'avait pas bien compris que c'est la machine de la personne qui rédige le mail qui calcule le hash. Pour une entreprise, ça serait la même chose, chaque employé a son poste.
Si l'entreprise édite des mailing lists, leurs clients devront les mettre en white-list, je trouve que c'est une bonne chose, car dans le cas où ces mailings ne t'intéressent pas ils passent quand même en spam.

Je ne pense pas que ce qoit le boulot des FAI de bloquer les mails, mais uniquement le client final. Si tu t'abonnes à une ML, tu la mets en whitelist.
Évidemment, c'est moins efficace contre les spammeurs car les FAI doivent encore les acheminer, mais le spam deviendrait beaucoup moins intéressant, en fait hashcash serait un nouveau gros critère pour les antispams.
L'idée étant de tuer les spammeurs par attrition ;)

Ca met à l'

Bon je ne peux pas trop deviner ce que tu voulais écrire, mais je ne vois toujours pas en quoi déporter la crypto sur la carte augmente la sécurité...
Pour moi ces histoires de carte à puce c'est un gros buzz, et ce n'est pas parce que les US s'y mettent que c'est bien.

une signature apporte la non-répudiation

Pas besoin de carte à puce pour faire une signature

D'après ce que je lis, c'est un truc à utiliser de chez soi (et pas chez ses amis, ses voisins ou dans un cybercafé).
Donc, on peut parfaitement se passer de la carte et stocker les clés et le soft d'authentification/accès sur la machine.
Le seul tout petit avantage que je voie à la carte, c'est que la séparation des données sur un support physique distinct permet de
1) si on veut changer de machine, il n'y a rien à nettoyer
2) si on est dans une période où l'OS qu'on utilise est susceptible d'être piraté (failles récentes, etc) éviter d'utiliser la carte.

Mais pour ces 2 points une clé USB fait tout à fait l'affaire.

J'aimerais bien savoir comment un lecteur de carte à puce (et une carte à puce) pourraient magiquement améliorer la sécurité. Tu pourrais donner des détails sur les cas d'utilisation que tu envisages avec ce système ?

Est-ce que le fait que le grand public ne pense pas à ça diminue le danger ?

Oui, avec un OTP rien ne sert de keylogguer, par contre, on peut écrire des troyens qui attendent que tu te logues puis qui font des opérations dans ton dos.

Faudra bientot mettre une barrire a toutes les falaises du monde car les gens ne vont pas voir qu'il y a le vide derriere si on continue comme ca

Notre gouvernement sait bien gérer ce genre de cas. Bientôt, tous les éditeurs de navigateur web seront forcés d'inclure dans les boîtes de mémorisation de mots de passe un encart à gros bords noirs sur fond blanc où il serait inscrit des messages divers comme "mémoriser vos mots de passe nuit à votre sécurité" ;)

donc si je suis dans un cyber cafe

Consulter des informations confidentielles, émettre des signatures électroniques ou passer des ordres depuis un ordinateur dont on a pas le contrôle est un non-sens.

Enblend mélange les ciels sur une très large zone, donc je pense qu'il faut traiter les images avant, sinon tu auras des dégradés à traiter.
Après, il faudrait voir pourquoi tu as des couleurs différentes ; tu a pris tes photos à des moments différents de la journée ? Tu as un lever ou un coucher de soleil ?

N'ont-ils pas changé de logo ?

Enblend, déjà largement utilisé avec le couple Hugin+Nona, permet de faire ça assez facilement, il y a même un exemple sur le site d'Enblend.
En gros, comme les photos se superposent, il suffit d'effacer et rendre transparentes les parties qui ne sont pas intéressantes ou dédoublées.

Oui, je me suis un peu emmêlé les pinceaux, mea maxima culpa. C'est vrai qu'il y a la conversion du proton vers le neutron et c'est ce qui se passe dans le soleil, mais je voulais bien préciser qu'on ne pouvait absolument pas le faire sur Terre (pour l'instant). Toutefois, ce n'est pas du fait d'une température beaucoup plus élevée qu'on peut faire fusionner deux 1H, il y a bien un autre phénomène qui entre en jeu.

Sur la deuxième question, je crois que si l'interaction forte était plus forte de quelques centièmes de pourcent, on pourrait fabriquer du 2He stable, ce qui n'est évidemment pas possible sous les lois actuelles et qui force à la réaction p->n sus-dite.

Si, mais en choisissant bien les matériaux, on peut contrôler ce en quoi ils sont susceptibles de se transformer et privilégier ceux qui sont très stables et peuvent recevoir beaucoup de neutrons (et d'autres particules), ou encore se transformer en substances peu nocives.

Par exemple, le fer (56Fe) se trouve d'habitude avec 30 neutrons mais peut en accepter deux supplémentaires et rester stable. La demi-vie du 59Fe est de 44j (wikipédia), donc pas très dangereux.

Le problème avec la fission de l'uranium/plutonium c'est qu'on obtient forcément des trucs pas cool comme le 90Sr qui s'intègre très bien au corps humain à la place du calcium et a une demi-vie de 30 ans environ, c'est à dire que celui qui l'a absorbé va forcément déguster.

Quelques petites précisions. Contrairement à ce qu'on pourrait croire, on ne peut pas du tout utiliser d'hydrogène classique (1 proton) pour la fusion nucléaire : en effet le but est de produire de l'hélium qui n'est stable qu'avec 2 protons et 2 neutrons. Sans quoi les étoiles brûleraient du fait de l'interaction forte (si je me souviens bien) et l'univers ne serait pas du tout le même : les étoiles brûleraient leur hydrogène beaucoup, beaucoup plus vite. Chose intéressante, si l'interaction forte était un chouilla plus forte, c'est ce qui se produirait.

Il faut donc forcément employer d'autres moyens (déjà évoqués dans le post précédent) pour obtenir de la fusion nucléaire. On peut utiliser du deutérium (le deutérium est présent en quantité faible, naturellement parmi l'hydrogène classique), par exemple en filtrant et en électrolysant l'eau lourde. Dans les bombes H on utilise un mélange d'hydrogène classique et de lithium (3p, 4n) pour produire deux atomes d'hélium.

Terminons donc ce thread sur une note humoristique :

Logiciel propriétaire au code repompé

* Une boîte de développement
* 3 BSD
* 2 MIT/X11
* 4 projets mixtes

Commencez par lancer un projet proprio dans une boîte.
Après une peu de conception, incorporez les BSD en refactorisant vigoureusement.

Ajoutez alors les MIT/X11. Après validation, détarrez des projets mixtes et séparez soigneusement les GPL du reste. Si un GPL se répand jetez ce projet et détarrez-en un autre. Reversez le code sous licence permissive dans le projet pricipal.

Développez jusqu'à ce que le mélange soit homogène. Présentez le tout dans un joli carton.

Sortez la version et distribuez.

C'est faux

Non, ce n'est pas faux, c'est juste que nous avons une perception différente du mot «intégrer».

Pour moi, un code fait normalement partie d'un projet, et un projet a notamment un nom, une organisation, des objectifs et une (ou plusieurs) licence(s). Modifier un de ces paramètres est souvent lourd et change substantiellement, si je puis dire, l'âme du projet.

C'est le code intégré qui doit être modifié si besoin pour coller à la façon de faire du projet, et pas l'inverse. D'ailleurs je pense que c'est ça l'acception générique de «intégrer» : c'est l'intégéré qui s'adapte à l'ensemble, pas le contraire.

Ce que tu suggères, je l'appellerais plutôt «mélanger», mais on va pas se battre sur des questions de terminologie non plus.

Si tu veux te mettre aux posts lapidaires, soit. Tu remarqueras que j'ai essayé de rester courtois au long de ce thread...

On peut intégrer du code BSD dans du code proprio.

Donc, la licence BSD est compatible avec une licence propriétaire.

On peut intégrer du code X dans du code proprio.

Donc, la licence X(MIT) est compatible avec une licence propriétaire.

On ne peut pas intégrer du code GPL dans du code proprio.

Donc, la licence GPL est incompatible avec une licence propriétaire.

Je suis totalement d'accord avec les propositions précédentes, mais ajoutons également :

On ne peut pas intégrer du code GPL dans du code BSD.
Donc, la licence GPL est incompatible avec une licence BSD.

On ne peut pas intégrer du code propriétaire dans du code BSD.
Donc, une licence propriétaire est incompatible avec une licence BSD.

CQFD.

C'est la réalité que ça te plaise ou non. Point.

Et j'aimerais savoir quelle ligne dans un de mes posts t'a fait penser que je croyais le contraire...

La dernière fois que j'ai regardé (il y a quelques mois), hugin avait besoin de PTStitcher (Panorama tools) pour fonctionner. Or, Panorama Tools n'est pas entièrement libre (la bibliothèque l'est, il y a les sources) mais les programmes sont fournis en binaire.
Il semble aussi qu'il y ait eu quelques épisodes controversés à propos de cela avec l'auteur original (Helmut Dersch) qui a un moment cessé de distribuer l'archive, puis a recommencé, le tout sous des rumeurs de pressions d'entreprises et de (supposés) brevets.

Tout cela pour dire que cela n'est pas très clair et j'aimerais savoir ce qu'il en est. Hugin peut-il désormais utiliser libpano12 sans PTStitcher ? Qu'est-ce qui est libre ? Qu'est-ce qui ne l'est pas ?

Hum, ça part en troll et nous n'avons définitivement pas le même point de vue. Avant de continuer et balancer des arguments inutiles, revenons-en au post qui a lancé ça :

Vu que le proprio est compatible BSD, la GPL l'est aussi !

J'aimerais savoir ce que tu cherches à exprimer en disant cela : juste régler un problème de terminologie, mettre en avant une possibilité juridique, autre chose ?

S'il s'agit d'un problème de terminologie, je dois dire que je ne comprends pas. La façon dont tu l'exprimes me semble peu claire et sujette à mauvaise interprétation.

"etre compatible" est une relation symétrique chez moi

Que nenni. Voici un exemple très concret de l'asymétrie de la compatibilité :

Le sang de groupe O est compatible avec tous les autres groupes (A, B, AB et O évidemment).
Le sang de groupe AB n'est compatible qu'avec le groupe AB et aucun autre.

Je ne vais pas énumérer les intermédiaires...

on ne peux pas plier son écran

Si, si, ça arrive, patience ;)

Après une recherche très rapide :

http://reviews-zdnet.com.com/4520-6033_16-4205284.html(...)
http://www.wired.com/news/technology/0,1282,58765,00.html(...)