La NSA n'a plus trop besoin de backdoorer les protocoles puisqu'il leur suffit de demander poliment les clefs
Ça dépend à qui. Un gros industriel étranger aux USA, au hasard chinois, dont les équipements réseaux sont utilisés par 30% de la planète ne donnera pourtant rien à la NSA, quoi qu'il arrive, en dehors du territoire américain.
Pareil avec un groupe terroriste, qui ne donnera pas ses clefs. On peut imaginer qu'un terroriste n'y connaît pas forcément grand-chose en crypto, donc il va prendre un logiciel "grand public" mais "open source" (afin d'éviter quelques backdoors standard) ; le logiciel opensource, lui, va respecter les standards (histoire d'éviter de faire des conneries, la crypto c'est pas simple), c'est-à-dire :
pour la cryptographie asymétrique, utiliser les courbes elliptiques du NIST
pour la génération d'aléa, utiliser les algorithmes recommandés par le NIST (Dual Elliptic Curve Deterministic RBG (Dual_EC_DRBG), qui d'une part est peu efficace (un mécanisme asymétrique pour générer de l'aléa, sérieusement…), d'autre part possède des propriétés mathématiques qui n'excluent pas qu'en connaissant un secret particulier, toute la séquence d'aléa puisse être remontée. Or la spécialité de la NSA est l'espionnage…
Pour 1., des Allemands ont proposé un protocole pour générer des courbes elliptiques dont l'utilisateur peut être sûr que le générateur n'a pas volontairement inséré une faiblesse connue de lui seul ( http://www.ecc-brainpool.org/ ).
Hors contexte, un peu d'histoire maintenant : concernant le chiffrement (pourri) du GSM, A5/1, les Allemands voulaient qu'il soit sûr, l'OTAN (largement influencé en cela, certainement, par les USA), non.
Security researcher Ross Anderson reported in 1994 that "there was a terrific row between the NATO signal intelligence agencies in the mid-1980s over whether GSM encryption should be strong or not. The Germans said it should be, as they shared a long border with the Warsaw Pact; but the other countries didn't feel this way, and the algorithm as now fielded is a French design."
Si tu es incriminé, en théorie tu peux invoquer le droit à ne pas témoigner contre toi-même.
Si techniquement ça utilise la perfect forward secrecy (ephemeral DH, https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante ) tu peux toujours donner tout ce que tu veux le protocole cryptographique empêchera la police d'avoir accès à quoi que ce soit.
Si enfin c'est vraiment utile mais oublié (par exemple un poème épique de passe), il ne faut jamais l'avoir écrit sur un bout de papier. Sinon c'est de la destruction de preuves.
Comment ils font pour prouver
Ils ne prouvent pas.
Quand ils rendent un verdict, les juges français le rendent selon leur intime conviction, pas selon des preuves.
Exemple célèbre : Landru.
la NSA peut aussi augmenter la sécurité de tous le monde
Très bonne blague.
C'est aussi la NSA qui a réduit la taille des clefs de 64 à 56 bits, soit-disant pour des "bits de parité" qui n'ont jamais servi à quoi que ce soit.
Si la NSA avait 10 ans d'avance en maths/cryptographie, elle a aussi 10 ans d'avance en calcul et infiniment plus de ressources en 1979 que n'en avait l'EFF en 1999 quand elle a construit le DES cracker https://en.wikipedia.org/wiki/EFF_DES_cracker (2000 puces dédiées à la recherche exhaustive).
Bref la NSA a renforcé le DES contre tous ceux (et seulement ceux) qui n'avaient pas la capacité de le craquer par force brute, capacité qu'il est fortement vraisemblable qu'elle avait.
De la même façon qu'avec le module de sécurité de Lotus Notes, http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html qui était sûr face à tous ceux qui n'avaient pas la clef privée de la NSA, mais pas sûr du tout face à la NSA.
Encore aujourd'hui, maintenant que les protocoles asymétriques envahissent la vie quotidienne, qui fournit les courbes elliptiques sur lesquels ils reposent ? le NIST, à savoir le paravent de la NSA.
Le protocole est documente publiquement.
Toute spec contient un point obscur que chacun interprète comme ça l'arrange.
Et dans tout point obscur peut se nicher une faille de sécurité discrète mais majeure.
Que tous les pays aient de mauvaises / discutables raisons est a mon avis sacrament tire par les cheveux…
On a pourtant bien vu ce qu'il en était pour l'adoption de la "norme" OpenXML…
Cf ce que je te disais ci-dessous. L'abstraction, quand elle suit le code, est précisée au fur et à mesure et finit toujours par exploser, sinon c'est qu'elle ne suit pas le code.
Sinon quand les différences sont minimes, autant en effet ne comparer que ce qui est différent. C'est d'ailleurs comme ça, à l'inverse, que les failles sont trouvées (regarder ce qu'un patch de sécurité corrige, pourquoi et comment, et comment on peut le contourner).
un audit ca trouve toutes les faille
Ça trouve facilement les failles logiques, oui, beaucoup moins les failles logicielles (type buffer overflow & co). Pas toutes, mais beaucoup. En crypto par exemple, il est même possible de prouver qu'un protocole d'échange est sûr.
Il y a evidemment des cas specialises, mais ca n'est pas faisable a l'echelle du pays.
Visiblement dès qu'il s'agit d'échanger des informations classifiées, c'est le cas… Et l'infrastructure du bousin a l'air de couvrir tout le pays vu que c'est un téléphone portable…
Ca a un cout enorme. Personne ne s'amuse a forker de distrib et la gerer soi-meme a part la Chine, et encore ils ne l'utilisent que tres peu, ca en dit long.
Hahaha. Tu veux dire que Microsoft, qui gère un écosystème logiciel comparable à une distribution à lui tout seul, est aussi riche et puissant que tout l'État chinois ? En retirant, bien sûr, la division XBox et tutti quanti.
En plus point n'est besoin de maintenir une distribution complète, seulement les logiciels utiles pour l'administration…
Et je ne suis pas sûr que le coût ne soit pas comparable à celui du développement, fonderie et production d'un composant, en plus en si petit nombre !
Alors là, permets moi de mettre sérieusement en doute tes compétences sur ce sujet.
Tu pars du meme point, tu suis les chemins en parrallele, les differences sont sensees etre minimes
Tu veux dire que tu testes le programme sur quelques entrées seulement ??? Donc tu ne passes jamais sur les entrées particulières qui justement activent la branche dont le cas négatif n'est pas testé et qui sert à la faille ?
Ou alors tu testes exhaustivement le programme sur toutes les entrées ? bon courage, s'il ne prend ne serait-ce qu'un seul entier sur 64 bits…
Ou alors tu fais une abstraction de l'entrée (genre une représentation par intervalle), et tu suis les conditions les unes à la suite des autres ? Au bout de 64 branches, tu as morcelé ton intervalle en potentiellement 264 sous-intervalles qu'il t'est impossible de suivre exhaustivement, donc il te faut une abstraction de ton abstraction, mais alors es-tu sûr que tu couvriras bien tous les cas ?
Au final c'est tres faisable vu que c'est un cas particulier.
Pour un "Hello World ! " c'est faisable bien sûr, mais sur un gros bout de code (ou pire sur un OS entier), c'est totalement irréaliste de l'envisager.
c'est quand meme gonflant cette attitude de gars moyen de linuxfr qui a pour habitude de mieux s'y connaitre que tous les ingenieurs securite de la DGSE, du ministere de la defense, …
Tu parles de toi ? Ou alors tu n'est pas un "gars moyen de linuxfr" mais un "gars supérieur" ?
Recompiler, executer et deployer des versions modifiees ne sert pas a grand-chose quand le produit a une taille monstre tel qu'une distrib ou Windows.
Haha.
Ca ne protége par exemple pas de failles dues au design (au hasard tout ce qui est crypto, tout ce qui du aux concepts tels qu'isolation de domaine web, …)
On parle des failles de sécurité logicielle, pas logiques. Pour les failles logiques, un audit (dans les cas simples) et sinon (d'après le lien que je donne ci-dessus) carrément faire les couches crypto en interne est ce qu'il y a de mieux.
La SEULE methode qui est valide, c'est une analyse statique du binaire compile pour s'assurer que son comportement est identique au binaire de reference.
Non. Le problème de l'identité de programme est indécidable. Ce n'est résoluble que dans les cas les plus simples, et certainement pas sur un "gros" binaire.
La seule méthode valide pour s'assurer que le binaire correspond aux sources est de le générer par un compilateur de confiance.
même config en entrée --> résultat différent, tu me fais peur.
Généralement, un algorithme non-déterministe donne de meilleurs résultats ou es plus efficace qu'un déterministe…
La seule maniere c'est de faire une analyse statique du code binaire entre les 2 fichiers et s'assurer que le code execute a le meme comportement.
Ou plutôt de déployer le programme recompilé par ses soins à partir des sources, et non pas de déployer des binaires étrangers.
D'autant qu'avec un peu de chance, même l'analyse statique, surtout sur des gros paquets de code, ne prouvera rien du tout : prouver que deux programmes font la même chose est indécidable en général.
On est coupable jusqu'a ce qu'on soit prouve innocent ?
En matière d'espionnage et de sécurité informatique, oui. Le principe de base de la sécurité est "tout ce qui n'est pas autorisé est interdit".
En contre-espionnage, c'est "tout ce qui n'est pas explicitement de confiance est potentiellement un espion".
D'autant qu'on ne se rend compte qu'on a été espionné qu'une fois le mal effectué, et toujours par quelque chose en qui on avait confiance (exemple : http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html )
Donc la règle est : on ne fait confiance à rien par défaut. Donc oui, coupable jusqu'à être prouvé innocent.
D'autant plus quand Microsoft n'a aucun intérêt à se fâcher avec le gouvernement américain (déjà, la boîte est obligé de se conformer à certaines décisions de justice non publiées ; de plus, contrairement à la France, les services de renseignement US peuvent donner des informations à leurs industriels), et que les logiciels Microsoft sont potentiellement une source de renseignement prodigieuse pour la NSA. Bref Microsoft + NSA = gagnant, gagnant.
En fait, la France, la Chine, la Russie, plein d'autres gouvernements et meme societes, ont acces aux sources.
Tant qu'on ne peut pas recompiler et exécuter et déployer les versions modifiées, ça ne sert à rien, et c'est plus pour rassurer l'homme politique qu'autre chose. La décision d'utiliser Windows n'est pas sur des critères techniques mais politiques.
L'étude des failles de sécurité se fait de toutes façons au niveau de l'assembleur ou par fuzzing, donc en boîte noire, par contre leur correction nécessite les sources.
Et une simple recompilation, qui modifie le placement en mémoire de certaines structures par exemple et la structure de certains bouts de code suffit à se protéger de bouts de code malveillants préparés à l'avance sur une version générique du logiciel.
a) Et tu crois que tout le monde lit les sources de Linux ?
En tout cas, toutes les sources de Linux sont lues et relues avant intégration, publiquement c'est-à-dire avec des gens reconnus qui mettent chacun leur réputation en jeu.
"nous travaillons sur une méthode en théorie plus rapide". Il n'y a donc aucun élément pour juger du potentiel de Daala pour l'instant.
Ben si, la théorie de la méthode en question, non ?
[^] # Re: Sécurité du DES
Posté par khivapia . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 4.
La NSA n'a plus trop besoin de backdoorer les protocoles puisqu'il leur suffit de demander poliment les clefs
Ça dépend à qui. Un gros industriel étranger aux USA, au hasard chinois, dont les équipements réseaux sont utilisés par 30% de la planète ne donnera pourtant rien à la NSA, quoi qu'il arrive, en dehors du territoire américain.
Pareil avec un groupe terroriste, qui ne donnera pas ses clefs. On peut imaginer qu'un terroriste n'y connaît pas forcément grand-chose en crypto, donc il va prendre un logiciel "grand public" mais "open source" (afin d'éviter quelques backdoors standard) ; le logiciel opensource, lui, va respecter les standards (histoire d'éviter de faire des conneries, la crypto c'est pas simple), c'est-à-dire :
pour la cryptographie asymétrique, utiliser les courbes elliptiques du NIST
pour la génération d'aléa, utiliser les algorithmes recommandés par le NIST (Dual Elliptic Curve Deterministic RBG (Dual_EC_DRBG), qui d'une part est peu efficace (un mécanisme asymétrique pour générer de l'aléa, sérieusement…), d'autre part possède des propriétés mathématiques qui n'excluent pas qu'en connaissant un secret particulier, toute la séquence d'aléa puisse être remontée. Or la spécialité de la NSA est l'espionnage…
Pour 1., des Allemands ont proposé un protocole pour générer des courbes elliptiques dont l'utilisateur peut être sûr que le générateur n'a pas volontairement inséré une faiblesse connue de lui seul ( http://www.ecc-brainpool.org/ ).
Hors contexte, un peu d'histoire maintenant : concernant le chiffrement (pourri) du GSM, A5/1, les Allemands voulaient qu'il soit sûr, l'OTAN (largement influencé en cela, certainement, par les USA), non.
https://en.wikipedia.org/wiki/A5/1
Security researcher Ross Anderson reported in 1994 that "there was a terrific row between the NATO signal intelligence agencies in the mid-1980s over whether GSM encryption should be strong or not. The Germans said it should be, as they shared a long border with the Warsaw Pact; but the other countries didn't feel this way, and the algorithm as now fielded is a French design."
[^] # Re: Quid de TrueCrypt
Posté par khivapia . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 4.
Ça dépend si tu es incriminé ou non.
Si tu es incriminé, en théorie tu peux invoquer le droit à ne pas témoigner contre toi-même.
Si techniquement ça utilise la perfect forward secrecy (ephemeral DH, https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante ) tu peux toujours donner tout ce que tu veux le protocole cryptographique empêchera la police d'avoir accès à quoi que ce soit.
Si enfin c'est vraiment utile mais oublié (par exemple un poème épique de passe), il ne faut jamais l'avoir écrit sur un bout de papier. Sinon c'est de la destruction de preuves.
Comment ils font pour prouver
Ils ne prouvent pas.
Quand ils rendent un verdict, les juges français le rendent selon leur intime conviction, pas selon des preuves.
Exemple célèbre : Landru.
# Sécurité du DES
Posté par khivapia . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 8.
la NSA peut aussi augmenter la sécurité de tous le monde
Très bonne blague.
C'est aussi la NSA qui a réduit la taille des clefs de 64 à 56 bits, soit-disant pour des "bits de parité" qui n'ont jamais servi à quoi que ce soit.
Si la NSA avait 10 ans d'avance en maths/cryptographie, elle a aussi 10 ans d'avance en calcul et infiniment plus de ressources en 1979 que n'en avait l'EFF en 1999 quand elle a construit le DES cracker https://en.wikipedia.org/wiki/EFF_DES_cracker (2000 puces dédiées à la recherche exhaustive).
Bref la NSA a renforcé le DES contre tous ceux (et seulement ceux) qui n'avaient pas la capacité de le craquer par force brute, capacité qu'il est fortement vraisemblable qu'elle avait.
De la même façon qu'avec le module de sécurité de Lotus Notes, http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html qui était sûr face à tous ceux qui n'avaient pas la clef privée de la NSA, mais pas sûr du tout face à la NSA.
Encore aujourd'hui, maintenant que les protocoles asymétriques envahissent la vie quotidienne, qui fournit les courbes elliptiques sur lesquels ils reposent ? le NIST, à savoir le paravent de la NSA.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Cf mes autres commentaires ci-dessous.
[^] # Re: Windows backdoor
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Le protocole est documente publiquement.
Toute spec contient un point obscur que chacun interprète comme ça l'arrange.
Et dans tout point obscur peut se nicher une faille de sécurité discrète mais majeure.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 1.
Que tous les pays aient de mauvaises / discutables raisons est a mon avis sacrament tire par les cheveux…
On a pourtant bien vu ce qu'il en était pour l'adoption de la "norme" OpenXML…
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Mais elle est indispensable à la sécurité.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 3.
Il manque :
c) Il est possible de déployer les versions modifiées et recompilées
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 1.
Cf ce que je te disais ci-dessous. L'abstraction, quand elle suit le code, est précisée au fur et à mesure et finit toujours par exploser, sinon c'est qu'elle ne suit pas le code.
Sinon quand les différences sont minimes, autant en effet ne comparer que ce qui est différent. C'est d'ailleurs comme ça, à l'inverse, que les failles sont trouvées (regarder ce qu'un patch de sécurité corrige, pourquoi et comment, et comment on peut le contourner).
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Oui, pour la recherche des failles.
Non, pour la possibilité de recompiler et déployer des versions modifiées.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 5.
un audit ca trouve toutes les faille
Ça trouve facilement les failles logiques, oui, beaucoup moins les failles logicielles (type buffer overflow & co). Pas toutes, mais beaucoup. En crypto par exemple, il est même possible de prouver qu'un protocole d'échange est sûr.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
Il y a evidemment des cas specialises, mais ca n'est pas faisable a l'echelle du pays.
Visiblement dès qu'il s'agit d'échanger des informations classifiées, c'est le cas… Et l'infrastructure du bousin a l'air de couvrir tout le pays vu que c'est un téléphone portable…
Ca a un cout enorme. Personne ne s'amuse a forker de distrib et la gerer soi-meme a part la Chine, et encore ils ne l'utilisent que tres peu, ca en dit long.
Hahaha. Tu veux dire que Microsoft, qui gère un écosystème logiciel comparable à une distribution à lui tout seul, est aussi riche et puissant que tout l'État chinois ? En retirant, bien sûr, la division XBox et tutti quanti.
En plus point n'est besoin de maintenir une distribution complète, seulement les logiciels utiles pour l'administration…
Et je ne suis pas sûr que le coût ne soit pas comparable à celui du développement, fonderie et production d'un composant, en plus en si petit nombre !
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 2.
cf ci-dessus, http://c2.com/cgi/wiki?TheKenThompsonHack depuis https://linuxfr.org/users/lucky--2/journaux/espionnage-sous-linux-ou-delire-paranoiaque#comment-1468916
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 1.
Alors là, permets moi de mettre sérieusement en doute tes compétences sur ce sujet.
Tu pars du meme point, tu suis les chemins en parrallele, les differences sont sensees etre minimes
Tu veux dire que tu testes le programme sur quelques entrées seulement ??? Donc tu ne passes jamais sur les entrées particulières qui justement activent la branche dont le cas négatif n'est pas testé et qui sert à la faille ?
Ou alors tu testes exhaustivement le programme sur toutes les entrées ? bon courage, s'il ne prend ne serait-ce qu'un seul entier sur 64 bits…
Ou alors tu fais une abstraction de l'entrée (genre une représentation par intervalle), et tu suis les conditions les unes à la suite des autres ? Au bout de 64 branches, tu as morcelé ton intervalle en potentiellement 264 sous-intervalles qu'il t'est impossible de suivre exhaustivement, donc il te faut une abstraction de ton abstraction, mais alors es-tu sûr que tu couvriras bien tous les cas ?
Au final c'est tres faisable vu que c'est un cas particulier.
Pour un "Hello World ! " c'est faisable bien sûr, mais sur un gros bout de code (ou pire sur un OS entier), c'est totalement irréaliste de l'envisager.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 3.
c'est quand meme gonflant cette attitude de gars moyen de linuxfr qui a pour habitude de mieux s'y connaitre que tous les ingenieurs securite de la DGSE, du ministere de la defense, …
Tu parles de toi ? Ou alors tu n'est pas un "gars moyen de linuxfr" mais un "gars supérieur" ?
Sinon visiblement, d'après http://www.lepoint.fr/actualites-technologie-internet/2010-01-06/nicolas-sarkozy-a-teste-le-teorem-son-futur-telephone-crypte/1387/0/411021 quand il s'agit de réellement protéger un secret par ces gens-là, tout est fait from scratch en interne, jusqu'au composant (donc forcément le logiciel qui tourne dessus, et toutes les couches supérieures).
Recompiler, executer et deployer des versions modifiees ne sert pas a grand-chose quand le produit a une taille monstre tel qu'une distrib ou Windows.
Haha.
Ca ne protége par exemple pas de failles dues au design (au hasard tout ce qui est crypto, tout ce qui du aux concepts tels qu'isolation de domaine web, …)
On parle des failles de sécurité logicielle, pas logiques. Pour les failles logiques, un audit (dans les cas simples) et sinon (d'après le lien que je donne ci-dessus) carrément faire les couches crypto en interne est ce qu'il y a de mieux.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 4.
La SEULE methode qui est valide, c'est une analyse statique du binaire compile pour s'assurer que son comportement est identique au binaire de reference.
Non. Le problème de l'identité de programme est indécidable. Ce n'est résoluble que dans les cas les plus simples, et certainement pas sur un "gros" binaire.
La seule méthode valide pour s'assurer que le binaire correspond aux sources est de le générer par un compilateur de confiance.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 1.
même config en entrée --> résultat différent, tu me fais peur.
Généralement, un algorithme non-déterministe donne de meilleurs résultats ou es plus efficace qu'un déterministe…
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 4. Dernière modification le 10 juillet 2013 à 10:54.
La seule maniere c'est de faire une analyse statique du code binaire entre les 2 fichiers et s'assurer que le code execute a le meme comportement.
Ou plutôt de déployer le programme recompilé par ses soins à partir des sources, et non pas de déployer des binaires étrangers.
D'autant qu'avec un peu de chance, même l'analyse statique, surtout sur des gros paquets de code, ne prouvera rien du tout : prouver que deux programmes font la même chose est indécidable en général.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 7.
On est coupable jusqu'a ce qu'on soit prouve innocent ?
En matière d'espionnage et de sécurité informatique, oui. Le principe de base de la sécurité est "tout ce qui n'est pas autorisé est interdit".
En contre-espionnage, c'est "tout ce qui n'est pas explicitement de confiance est potentiellement un espion".
D'autant qu'on ne se rend compte qu'on a été espionné qu'une fois le mal effectué, et toujours par quelque chose en qui on avait confiance (exemple : http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html )
Donc la règle est : on ne fait confiance à rien par défaut. Donc oui, coupable jusqu'à être prouvé innocent.
D'autant plus quand Microsoft n'a aucun intérêt à se fâcher avec le gouvernement américain (déjà, la boîte est obligé de se conformer à certaines décisions de justice non publiées ; de plus, contrairement à la France, les services de renseignement US peuvent donner des informations à leurs industriels), et que les logiciels Microsoft sont potentiellement une source de renseignement prodigieuse pour la NSA. Bref Microsoft + NSA = gagnant, gagnant.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 6.
En fait, la France, la Chine, la Russie, plein d'autres gouvernements et meme societes, ont acces aux sources.
Tant qu'on ne peut pas recompiler et exécuter et déployer les versions modifiées, ça ne sert à rien, et c'est plus pour rassurer l'homme politique qu'autre chose. La décision d'utiliser Windows n'est pas sur des critères techniques mais politiques.
L'étude des failles de sécurité se fait de toutes façons au niveau de l'assembleur ou par fuzzing, donc en boîte noire, par contre leur correction nécessite les sources.
Et une simple recompilation, qui modifie le placement en mémoire de certaines structures par exemple et la structure de certains bouts de code suffit à se protéger de bouts de code malveillants préparés à l'avance sur une version générique du logiciel.
[^] # Re: Bof
Posté par khivapia . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 3.
a) Et tu crois que tout le monde lit les sources de Linux ?
En tout cas, toutes les sources de Linux sont lues et relues avant intégration, publiquement c'est-à-dire avec des gens reconnus qui mettent chacun leur réputation en jeu.
[^] # Re: Accès SSH
Posté par khivapia . En réponse au message Machine compromise.. Évalué à 2.
qu'on rajoute un noexec sur les partitions bien séparées qui ne contiennent pas d'exécutables,
sans oublier nosuid nodev
[^] # Re: Colin mon p’tit frère
Posté par khivapia . En réponse au journal Privé de bac à cause d'un logiciel propriétaire. Évalué à 3.
combien de temps pour obtenir sur un smartphone autant de réponses à autant de questions complexes ?
Surtout avec un Neo Freerunner limité au GPRS…
[^] # Re: Pour le succès
Posté par khivapia . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 3.
"nous travaillons sur une méthode en théorie plus rapide". Il n'y a donc aucun élément pour juger du potentiel de Daala pour l'instant.
Ben si, la théorie de la méthode en question, non ?
[^] # Re: Libre
Posté par khivapia . En réponse au journal AMD rejoint la Document Foundation pour accélérer Libreoffice. Évalué à 2.
existe-t-il des projets de CPU ou GPU libre?
Oui, il y a celui-là, qui peut monter assez haut en fréquence dès qu'on l'implémente sur une cible matérielle :
http://en.wikipedia.org/wiki/One_instruction_set_computer
-------> []