dénommé MicroBSD il serait un fork d'OpenBSD (Cf leur FAQ).
Cet OS apporte tout ce qu'OpenBSD n'implémente pas (ACL, TPE, détection d'intrusion dans l'install par défaut,etc..).
A noter:
pas encore d'accès aux sources, et beaucoup de choses ont l'air loin d'être avancées...
Il reste qu'au niveau cryptage il va falloir sérieusement se battre contre les lois (En prime: une clé de cryptage de 1024 bits serait cassable)
Aller plus loin
- MicroBSD (26 clics)
- OpenBSD (4 clics)
- Journal du net - clé 1024 cassable (8 clics)
# TPE ?
Posté par shbrol . Évalué à 10.
[^] # Re: TPE ?
Posté par Loic Jaquemet . Évalué à 10.
seul le 'root' a le droit d'exec ca , wheel ca , toto ca ..
un truc du genre .
amoins que ca soit dans l'autre sens ..
[^] # Re: TPE ?
Posté par Lucas . Évalué à 10.
Par exemple, un utilisateur ne peut éxécuter que ce qu'il y a dans /bin et /usr/bin. L'intérêt ? Empêcher un hacker de faire cc exploit.c && ./a.out
[^] # Re: TPE ?
Posté par Def . Évalué à 10.
C-a-d n'autoriser les executions de binaires que dans /usr/bin /sbin etc.
Ca complique les exploits pour des utilisateurs locaux ...
[^] # Re: TPE ?
Posté par PLuG . Évalué à 10.
Je ferai remarquer qu'a moindre cout, tous les unix peuvent etre installés de facon a limiter la casse si /home, /tmp et /var sont montés en mode "noexec" et "nodev".
[^] # Re: TPE ?
Posté par Florent Rougon (site web personnel) . Évalué à 10.
/bin/sh /tmp/vilain_script.sh
Pour un binaire :
/lib/ld-linux.so.2 /tmp/vilain_binaire
[^] # Re: TPE ?
Posté par PLuG . Évalué à -2.
[^] # Re: TPE ?
Posté par Jerome Alet (site web personnel) . Évalué à 0.
La meilleure solution pour éviter la casse est de monter /home /tmp et /var en READONLY.
:-))
[^] # Re: TPE ?
Posté par PLuG . Évalué à 10.
la technique TPE a été décrite dans Phrack numero 54 ( http://www.phrack.org/phrack/54/P54-06(...) ) et repris par la nsa ( http://www.nsa.gov/selinux/inevit-abs.html(...) )
reste a lire tout cet anglais :-)
[^] # j'en ai oublié un
Posté par earxtacy . Évalué à 6.
http://www.trustedbsd.org/(...)
le plus inquiétant c'est le cassage possible
du cryptage 1024 bits.
tout etant encore souvent basé sur la simple clé 128 bits (commerce, etc..)
[^] # Re: j'en ai oublié un - cassage de clés
Posté par zeiram . Évalué à 10.
Attention à ne pas faire des amalgames entre des algorithme de chiffrement de type différents. L'article parle de clés pour des algorithmes asymétriques. Le commerce électronique est basé à la fois sur des algorithmes asymétriques (échange de clés utilisées pour créer un canal sûr) et symétriques (transfert des donées). Une fois le canal sûr créé, les deux parties l'utilisent pour s'échanger une clé de session (qui sera la clé pour le chiffrement symétrique) et n'utilisent plus qu'un algorithme symétrique pour s'échanger les informations. La raison de ceci est qu'un chiffrement symétrique est nettement, très nettement, plus rapide qu'un chiffrement asymétrique. En plus, on peut plus facilement implémenter au niveau matériel un chiffrement symétrique.
En ce qui concerne la longueur des clés, lorsqu'on parle de chiffrement pour le "e-commerce" avec des clés à 128 bits, il s'agit de la longueur de la clé utilisée dans l'algorithme symétrique. La longueur des clés utilisées pour la partie asymétrique est souvent de 1024 bits. Et n'oublions pas qu'à longueur de clé égale (bien que cela n'ait absolument aucun sens de prendre une clé symétrique de 1024 bits ou une clé asymétrique de 128 bits), un algorithme symétrique est nettement plus difficile à casser qu'un algorithme asymétrique. C'est pourquoi on trouve des longueurs de clés allant sans problème jusqu'à 4096 bits pour des clés GPG, alors que l'on a toujours du 128 bits pour le "e-commerce".
Je ne me souviens malheureusement plus quel est le facteur de correspondance sur la longueur des clés pour les deux types d'algorithme afin d'avoir le même niveau de sécurité. Peut-être quelqu'un d'autre a-t-il cela sous la main ?
Bonne journée.
[^] # Re: j'en ai oublié un - cassage de clés
Posté par zeiram . Évalué à 1.
Dans le hors-série numéro 36 de Pour la Science (date : juillet/octobre 2002), consacré à la cryptographie, il est indiqué en page 34 qu'il faut 10^27 MIPS.an[1] pour casser une clé symétrique de 128 bits par recherche exhaustive et "seulement" 7x10^19 MIPS.an pour casser une clé publique RSA de 2048 bits par factorisation. D'après la loi de Moore, ils estiment une date limite de résistance de ces clés à environ l'an 2100 pour les clés symétriques de 128 bits et environ l'an 2080 pour les clés RSA de 2048 bits (3x10^9 pour les clés à 1024 bits, cassable en environ l'an 2030).
Par contre, les clés symétriques de 256 bits (respectivement 4096 bits pour le RSA) resteront "à jamais" incassable car toute l'énergie du soleil ne suffirait pas à effectuer le nombre nécessaire d'opérations en supposant qu'une opération ne demande pas plus d'énergie que le changement d'orbite d'un électron autour d'un atome. Bien entendu, le terme "à jamais" est soumis à la condition qu'il n'y ait pas une découverte scientifique majeure qui change radicalement notre méthode de recherche de ces clés.
Conclusion : une "bonne" clé symétrique à 128 bits est encore plus sure qu'une clé publique à 2048 bits... donc l'utilisation de "seulement" 128 bits pour le chiffrage de "l'e-commerce" n'est pas du tout problématique.
Bonne journée.
[1] 1 MIPS.an correspond à 2^45 opérations élémentaires.
[^] # Re: j'en ai oublié un
Posté par Spadone Pascal . Évalué à 10.
Les clefs 128 bits utilisées pour les transactions CB par exemple sont des clefs symétriques (la même clef est utilisé pour le chiffrage que pour le déchiffrage), avec des algorithmes du genre DES qui consitent en gros à faire plein de XOR entre la clef et les données; les clefs dont le cassage des versions 1024 bits serait posssible sont des clefs asymétriques (clef privée pour chiffrer, clef publique pour déchiffrer), reposant sur le fait qu'il est difficile (donc long) de factoriser le produit de deux grands nombres premiers.
Ces deux types de clefs n'ont donc strictement rien à voir !
[^] # Re: j'en ai oublié un
Posté par earxtacy . Évalué à -3.
je l'avais sans doute déja lue reste a s'en rappeler ;)
[^] # Re: j'en ai oublié un
Posté par vjm . Évalué à 4.
FreeBSD et NetBSD était les BSD issuent de la fermeture du CSRG développant BSD. FreeBSD étant légèrement plus ancien puisque dérivé directement de 386BSD. Ensuite, OpenBSD est un fork de NetBSD orienté sécurité. MicroBSD est un fork (qui a dit vaporware ?) basé sur OpenBSD et lui ajoutant quelques fonctionnalités.
Qui, d'ailleurs ressemblent en partie au travail effectué par TrustedBSD (qui n'est pas un fork) dont le but est de faire passer à FreeBSD les Common Criteria for Information Technology Security Evaluation (reconnus en France, en Allemagne, aux USA, au Royaume-Uni, au Canada et au Pays-Bas) aussi connu sous le nom d'Orange Book. Et justement il demande entre autre des acl, des discretionnary access control (mac avec plusieurs politiques dont notamment un portage de SELinux appelé SEBSD, capabilities...). En passant, TrustedBSD n'est qu'une des nombreuses initiatives du projet CBOSS soutenu par NAI Labs et la DARPA. C'est notamment grâce à CBOSS qu'on a vu le remplacement du PRNG par Yarrow, l'arrivée des syncookies/syncache et bientôt l'arrivée d'UFS2 optimisé pour les Extended Attributes (utilisés pour les ACL et autres) ou l'extension de jail.
Bref, renseignez vous un peu.
http://opensource.nailabs.com/initiatives/cboss/(...)
(future news : CBOSS un fork (bomb) BSD !)
[^] # Re: j'en ai oublié un
Posté par vjm . Évalué à 3.
http://www.freebsd.org/auditors.html(...)
# Troll a donf.....
Posté par kesako . Évalué à -7.
Non mais ils sont dingues ou quoi ?
hop -1 !
[^] # Re: Troll a donf.....
Posté par earxtacy . Évalué à -4.
qui sont vraiment les personnes derriere ce projet!?
je dois etre fatigué car je l'ai meme pas vue dans la faq ;)
# pour résumer
Posté par Lucas . Évalué à 10.
A noter qu'il existe déjà TrustedBSD (voir http://www.trustedbsd.org/(...) ), qui est FreeBSD + ACL.
[^] # Re: pour résumer
Posté par DaFrog . Évalué à 10.
Stephanie est concu comme un ensemble de patchs du noyau OpenBSD destiné à intégrer la distrib par défaut, alors que MicroBSD est un fork, avec du code de Free et NetBSD; les sources de Stephanie sont dispo, ce qui n'est pas encore le cas de MicroBSD.
Ce sont des détails, mais personellement, je préfère largement la solution Stephanie: améliorer la sécurité d'OpenBSD plutot que de créer (encore) un fork supplémentaire...
D'autres différences: MicroBSD inclut un IDS et un certain nombre de serveurs par défaut; il est aussi concu pour tourner à partir d'un CD par exemple...
DaFrog.
[^] # Re: pour résumer
Posté par Lucas . Évalué à 10.
Le gros problème de Stephanie, c'est que le patch ne s'applique que sur OpenBSD 3.1-RELEASE. Pour quelqu'un qui suit OpenBSD 3.1-STABLE, ou pire -CURRENT, c'est inutilisable. Si MicroBSD inclue régulièrement les modifs faites dans OpenBSD, ca peut être un bon plan...
D'autre part, Stephanie n'est absolument pas supporté par les développeurs d'OpenBSD (voir le thread d'il y a qqes jours sur Stephanie)
[^] # Re: pour résumer
Posté par Lucas . Évalué à 10.
Je me réponds à moi-même pour ajouter que c'est assez paradoxal : les personnes intéressées par Stephanie sont obligées de recompiler tout le système, mais ne peuvent pas bénéficier du gros avantage qu'implique la recompilation de tout le système, càd passer en -STABLE ... (les patchs de Stephanie pour OpenBSD 3.1 ne s'applique pas sur 3.1-STABLE, j'ai essayé :( )
Il y a donc vraiment de ce point de vue là une place pour MicroBSD.
lucas
[^] # Re: pour résumer
Posté par Delaregue . Évalué à 6.
# 1024, 2048, etc
Posté par Cedric L'HOMME . Évalué à 10.
Une clef de 1024 bits pour faire un XOR risque de pas tenir lomptemps ...
Une clef de 1024 bits pour faire de l'AES devrait tenir un peu plus longtemps ;)
Parle t'on de cette taille uniquement pour les chiffrements asymetriques qui, si j'ai tout compris, implique presque tout le temps un brute force pour les casser ?
[^] # Re: 1024, 2048, etc
Posté par Salica . Évalué à 10.
Donc, si ton algo est parfait et si tu as une clef de 1024 bits, la seule solution pour le "méchant cracker vilain pas beau" est de passer en revue les 2 EXP 1024 clefs possibles (donc, en moyenne, il trouvera la clef après 2 EXP 1023 essais).
Mais en pratique, tu peux avoir des 'failles' qui te permettent d'éviter de devoir passer toutes les clefs possibles en revue.
Soit c'est l'implémentation de l'algo qui est défectueuse. Soit c'est l'algo lui meme qui contient des 'raccourcis' (voulus ou pas).
En fait, la sécurité absolue existe : c'est le One-Time-Pad. Ca consiste (en gros) à générer *vraiment* aléatoirement une clef aussi longue que ton message. C'est pas facile à mettre en oeuvre, ça ne peut servir qu'une fois, mais c'est le chiffrement ultime (enfin à mon sens hein :-) )
[^] # Re: 1024, 2048, etc
Posté par kael . Évalué à 10.
les deux correspondant doivent avoir la clef pour faire le dechifrage, or come la clef change tout le temps, il faut que les deux correspondant ai un moyen de se transmettre la clef a chaque fois ou un catalogue de clef qu'il detruisent au fur et a mesure de l'utilisaton. dans les deux cas la faille se situe au niveau de l'acces a la clef lors de son transport d'un correspondant 1 vers un correspondant 2.
mais sinon d'un point de vue logique effectivement c'est irreversible si on a pas la clef, meme par cassage bourrin
[^] # One Time Pad : précision
Posté par Salica . Évalué à 6.
Je crois qu'il est bon de préciser que c'est une méthode très lourde à mettre en oeuvre : génération aléatoire d'une clef assez grande, envoi de la clef, aspect "usage unique", ...
En fait, il ne faut pas considérer le OTP comme étant une solution "grand public".
C'est plutot réservé à ceux qui ont les moyens d'envoyer la clef par un porteur qui a une malette attachée à son bras par une menotte :-)
Je devrais essayer de retrouver mes sources, mais il me semble qu'il y a déjà eu des transports de clefs OTP escortées par convoi militaire. C'est un peu lourd pour etre intégré dans SSL ;-)
[^] # Re: One Time Pad : précision
Posté par Aza . Évalué à 1.
Il me semble que le téléphone rouge entre washingtown et moscou fonctionnait justement comme cela.
[^] # Re: One Time Pad : précision
Posté par maurice rosenfelder . Évalué à 1.
Il s'agissait d'une bande de teletype que l'on superposait à celle du texte à crypter sous la forme d'un simple XOR.
Elle était parait'il à l'époque générée à partir des sons d'un piano.
[^] # Re: 1024, 2048, etc
Posté par Jerome Herman . Évalué à 10.
La sécurité du chiffrage ne dépend que de ce que tu as en face. Au 17éme un cryptage par equation du 3ème degré était assez monstrueux, et puis un jour un mec à inventé les nombres imaginaires (i^2=-1) et là plouf, cassée en trente secondes chrono la clef.
Le jour ou les ordinateurs quantiques seront pleinement opérationnels, les clefs assymétriques basées sur les nombres premiers auront du soucis a se faire.
Tu peux toujours un beau matin tomber sur un génie des maths qui va trouver un nouvel espace, un anneau particulier, une propriété marrante d'une base de nombres qui fait que ton système de cryptage vole en éclat du jour au lendemain.
Quand à ta ce tu appelles le One-Time-Pad j'ai du mal à comprendre comment ca marche. C'est le message qui determine la clef. donc c'est forcément l'auteur du message qui possède la clef de décryptage. Il faut donc qu'il transmette la clef a la personne qui va recevoir le message et ce pour chaque nouveau message. Ca m'a surtout l'air d'être une bonne façon de se faire chopper la clef au moins une fois.
En plus il n'éxiste pas à ce jour de moyen de générer un nombre vraiment aléatoire. On peut créer du pseudo aléatoire avec l'uptime de la machine, le nombre de clicks de souris, de frappes clavier, en demandant à l'utilisateur de faire des déplacement avec la souris etc... Mais ça n'est pas aléatoire, c'est juste très complexe mais le hasard n'a rien à faire là dedans.
On peut aussi générer des nombres imprévisibles, par exemple en demandant à un ordi d'itérer un même calcul à l'infini avec une précision très grande. (Exemple x=(x^(1/3))*pi^2). Au bout d'un moment on sort de la précision de la machine (ie deux machines identiques vont avoir deux résultats très différents). C'est un nombre imprévisible, mais il n'est pas aléatoire car certains nombre ont plus de chance de sortir que d'autres (la repartition n'est pas equiprobable).
Tout ca pour dire que ton One-Time-Pad je vois pas bien comment ca marche.
Kha
[^] # je ne comprends pas
Posté par Ice Lion . Évalué à 6.
Les machines actuelles étant déterministes, si deux machines identiques font le même calcul sans faire intervenir de tirages, je ne vois pas comment elles peuvent aboutir à des résultats différents au bout d'un quelconque nombre d'itération.
Que ça soit imprévisible/chaotique à cause d'arrondis ou autres, ok, mais les machines déterministes et identiques devraient obtenir des résultats identiques. Ou alors il me manque une information...
[^] # Re: je ne comprends pas
Posté par Jerome Herman . Évalué à 2.
Pardon je n'ais pas été assez clair. Si on prend deux machines identiques d'un point de vue constructeur, elle ne le sont pas d'un point de vue sillicium. Tous les processeur et toutes les mémoires sont testées dans certains intervalles, mais il ne sont pas fiables à 100%.
La meilleure facon de s'en rendre compte est de prendre un vieux compilateur x86 (génération 386) et de lui demander de convertir le nombre 1 entier en flotant. Sur certaines machines ca donnera 1.000....01 et sur d'autres 0.99999999. Jusque là c'est une simple erreur d'arrondi pas de quoi se réjouir.
Si parcontre on rend un calcul relativement complexe et qu'on itére 20 000 fois
type x = racine cubique de x fois pi au carré.
à la première itération on aura une simple erreur d'arrondi, à la deuxième l'erreur aura augmenté d'elle même. A la 20 000 itération l'erreur sera égale à elle même à la puissance 20 000. Ca peut ne pas être suffisant pour sortir des valeurs standards, mais au bout de plusieurs milliards d'itérations l'erreur d'arrondi cumulé aura plus de poid que le résultat du calcul.
Il y avait une expérience chez SUN avec un modèle asez "simple" de calcul gravitationel à trois particules. Trois planète sont lachées dans l'espace assez proche les unes des autres pour que la gravité entre elle soit forte, et on calcule seconde après seconde leur trajectoires.
Une batterrie de stations SUN aussi semblables que possible avait lancé au même moment les calculs. Deux heures après des différences notables apparaissaient dans les trajectoires, quatres heures après les trajectoires étaient complètement dissemblables.
Le plus beau c'est que lorsque que l'on relancait le même calcul depuis une machine elle finissait toujours par obtenir des résultats différents.
Il y a trois point dans les séries de calculs :
1°) jusqu'à x itération une machine va donner les même résultats que ses homologues
2°) jusqu'à y itération une machine va rester consistante avec ses propres résultats mais va s'éloigner des résultats des autres machines similaires.
3°) a partir de y+1 itération la machine va commencer à rendre des résultats différents de ce qu'elle avait obtenu lors des essais précédents.
C'est un des outils avec lesquels on peut faire des nombres imprévisibles.(Lent mais simple)
En espérant avoir été plus clair cette fois.
Kha
----
-1 parceque hors sujet et chiant à lire.
[^] # Re: 1024, 2048, etc
Posté par PLuG . Évalué à 4.
tu remplis deux carnets (identiques) de ces "clefs",
tu en remet un a ton correpondant en main propre et voila, votre correspondance est chiffrée correctement pour autant de messages qu'il y a de pages dans le carnet ...
reste a ne pas se faire photocopier le carnet par un intrus ...
[^] # Re: 1024, 2048, etc
Posté par Éric (site web personnel) . Évalué à 5.
Je vais essayer d'expliquer ca simplement si j'ai bien compris de quoi il parle.
Tu as un message de moins de 100ko, tu génère un champ de bit de 100ko aléatoirement [1] ca te donne ta clé. Un bête XOR te donne ton message codé.
De l'autre coté reXOR à partir de la clé et le message original est là.
Si tu n'utilise qu'une seule fois la clé et qu'elle est de longueur égale ou supérieure au message il n'y a pas de probleme de décodage.
Où est le probleme ? il y en a 2 :
- si tu peux faire passer la clé avec un moyen sur, vu qu'elle est de meme taille que le message, t'aurais peut etre mieux fait de faire passer ton message :). Il n'y a donc d'interet que si tu as un moyen sur de faire parvenir tes clés avant d'avoir à faire parvenir ton message. (genre le jour X tu distribue tes clés à ton copain parce que tu le rencontre face à face. Le jour X+1 il se passe quelque chose et là tu peux envoyer un message (que tu ne connaissais pas la veille) via une des clés préalablement distribuée) ... faut dire que ca limité énormément l'utilisation
- une clé = un message et taille_clé >= taille_message. Des qu'il y a réutilisatoin il y perte de sécurité. Pas la peine de penser faire passer un fil d'info continu.
Enfin entre temps c'est une solution de cryptage impossible à cracker (si la génération "aléatoire" est non prévisible)
[1] un nombre aléatoire est tout à fait générable. Il ne sera peut etre pas aléatoire d'un point de vue physique mais il sera non prévisible par le méchant (qui n'aura pas assez d'infos pour pouvoir faire cette prévision ni même avoir des statistiques valables sur la sortie). Non prévisible par quelqu'un d'extérieur il y a une quantité de méthodes qui vérifient ca donc "aléatoire" ne pose pas de probleme majeur.
Par contre ton explication de calculs qui sortent de la précision me semble tout à fait mauvaise, et je rejoins le commentaitre de quelqu'un qui t'a déjà répondu : le résultat du calcul sera peut etre faux mais il sera le meme sur toutes les machines avec la meme architecture.
[^] # Re: 1024, 2048, etc
Posté par Aurélien Jarno (site web personnel) . Évalué à 3.
Oui, mais il y a un avantage s'il y a moyen de savoir que la clé est compromise (scellé dans le monde réel par exemple). Si tu te rends compte que la clé est compromise, tu peux toujours en envoyer une autre, alors que si c'est le message qui est compromis, c'est trop tard...
[^] # Re: 1024, 2048, etc
Posté par lhardy philippe (site web personnel, Mastodon) . Évalué à 2.
BAh tu vas a la fnac du coin tu achete un vieux CD en double.
T'en donnes un a un pote et vous utilisez son contenu pour envoyer 600 Mo de donnees en les comibant par un algorithme a la con totalement public.
Biensur c'est mieux si le CD est rempli avec des vraies donnees aleatoires, mais est-ce que ca existe ?
Ah oui au fait ce type de cryptage est interdit.
[^] # Re: 1024, 2048, etc
Posté par Spadone Pascal . Évalué à 7.
Oui exactement. Ce type de clef est basé sur le fait qu'il est très difficile de factoriser le produit de deux grands nombres premiers. Par exemple, si ma clef est 35, il n'est pas trop dur de voir que c'est 5*7. La polémique sur la taille des clefs consiste à savoir si quelqu'un peut factoriser un nombre de 1024 bits, avec quels moyens, etc.
# les clefs de cryptages
Posté par kael . Évalué à 10.
il nous dit que la nsa aurait un budjet de 5 milliard (san preciser de source) et qu'elle a les moyen de se payer un systeme de cassage de clef qui coute au moins 1 miliard....
je suis pas doué en compta mais passer 1/5 du budget pour casser une clef ca me parait pas tres judicieux, meme pour un americain, donc y'a un des deux chiffre qui est bidon
je dis pas que la nsa a pas les moyen de casser une clef, je dis juste que l'article est a priori completement bidon :-)
[^] # Re: les clefs de cryptages
Posté par PLuG . Évalué à 9.
reste que toutes ces affirmations sont un peu gratuites effectivement.
[^] # Re: les clefs de cryptages
Posté par kael . Évalué à 2.
je serait par contre plus d'accord avec la theorie de kalahann (voir en dessous) concernant un algorithme digne de ce nom, ce a quoi je rajouterais des machines dedié mais pas aussi chere que ce que precise l'article...
bref va faloir trouver une autre methode de cryptage.....
[^] # Re: les clefs de cryptages
Posté par kalahann . Évalué à 10.
Perso je m'inquiète pas de leurs machines, aussi puissantes soient-elles. Par contre, je m'inquiéterai plus des algorithmes que leurs mathématiciens ont pu développer, vu que c'est à la NSA qu'il y a le plus de mathématiciens (et les meilleurs)
Si ça se trouve il existe un algo pour casser toute clé en qq secondes, et ils l'ont trouvé... personne n'est à l'abri d'une évolution majeure dans la théorie des grands nombres.
[^] # Re: les clefs de cryptages
Posté par zeiram . Évalué à 10.
Au chapitre qui traite de l'algorithme DES, Bruce Schneier explique que la NSA a apporté des modifications à l'algorithme tel qu'il a été développé par les concepteurs de base. Pendant longtemps on s'est demandé pourquoi ces modifications avaient été apportées. Vingt ans après la "création" de l'algorithme, la réponse est apparue. Un nouveau type d'attaque avait été trouvé par un chercheur universitaire : la cryptographie différentielle (utiliser des bouts de différents messages et les comparer entre eux pour trouver des failles). Il s'est alors avéré que les modifications apportées au design du DES par la NSA rendait l'algorithme quasiment invulnérable à des attaques différentielles. Et la modification apportée était le strict minimum pour rendre l'algorithme invulnérable. Alors que le design original était quant à lui très vulnérable à ce type d'attaque. Conclusion : la NSA connaissait déjà les méthodes d'attaques différentielles lors de la création du DES. Ils avaient donc au moins vingt ans d'avance sur le reste du monde pour les algorithmes de déchiffrement.
Maintenant, on peut se poser la question de savoir si cette avance a diminué, augmenté ou est restée à la même différence... À mon avis, elle n'a en tout cas pas diminué (mais je ne base cela sur aucun fait).
[^] # Re: les clefs de cryptages
Posté par Mathieu Dessus (site web personnel) . Évalué à 7.
Puisqu'on parle de Schneier, voici un document publié il y a qq années, mais le tableau à la fin résumant le temps nécessaire pour decrypter un message chiffré en fonction du matériel est trés intructif : http://www.counterpane.com/keylength.html(...) .
[^] # si c'est un universitaire qui l'avait trouvé
Posté par Ice Lion . Évalué à 1.
[^] # Re: si c'est un universitaire qui l'avait trouvé
Posté par zeiram . Évalué à 5.
Mais étant donné les modifications apportées par la NSA à l'algorithme DES, on en arrive à la conclusion que le déchiffrement différentiel avait déjà été trouvé par la NSA au moins vingt ans plus tôt. Et bien sûr, classé secret défense comme tout ce qui touche à la NSA.
[^] # [HS] Budget NSA
Posté par Def . Évalué à 3.
Although, of course, the actual NSA budget is top secret (estimates put it at $30 billion).
http://www.theregister.co.uk/content/55/21047.html(...)
# Le logiciel libre vers le chaos...
Posté par c_55555 . Évalué à -8.
Et de FreeBSD en plus !
Alors qu'il y a deja Net et Open BSD qui sont deja des fork de Free...
Evidement, à chaques fois, cela saigne les équipes de développeurs. Peut être même qu'ils divorce parce qu'ils se detestes vraiment. En tout cas les développements vont ralentir.
C'est probablement l'avenir de tout les projets libres : apres une phase de forte croissance ou les développeurs sont unis, une phase ou les desacords s'intalle et ou le model libre s'effondre dans le fork et la pagaille...
Tout les softs vont etre gelés peu a peu...
Ce qui nous feraient revenir à des developpement plus traditionnel, controlés et administrés par une boite compétante.
Ce qui du même coup montre que le probléme n'est pas le brevet logiciel, mais plutôt comment motiver assez les developpeurs du libre pour qu'ils acceptent de travailler encore ensemble malgré leur ressentiment.
C'est sur que travailler dans la haine, c'est pas évident, surtout si t'es pas payé... C'est de l'esclavage là...
[^] # Re: Le logiciel libre vers le chaos...
Posté par spim . Évalué à 1.
Alors qu'il y a deja Net et Open BSD qui sont deja des fork de Free...
Faudrait se renseigner un peu avant de balancer ce genre de conneries ...
# Le logiciel libre vers le chaos...
Posté par c_55555 . Évalué à -10.
Et de FreeBSD en plus !
Alors qu'il y a deja Net et Open BSD qui sont deja des fork de Free...
Evidement, à chaques fois, cela saigne les équipes de développeurs. Peut être même qu'ils divorce parce qu'ils se detestes vraiment. En tout cas les développements vont ralentir.
C'est probablement l'avenir de tout les projets libres : apres une phase de forte croissance ou les développeurs sont unis, une phase ou les desacords s'intalle et ou le model libre s'effondre dans le fork et la pagaille...
Tout les softs vont etre gelés peu a peu...
Ce qui nous feraient revenir à des developpement plus traditionnel, controlés et administrés par une boite compétante.
Ce qui du même coup montre que le probléme n'est pas le brevet logiciel, mais plutôt comment motiver assez les developpeurs du libre pour qu'ils acceptent de travailler encore ensemble malgré leur ressentiment.
C'est sur que travailler dans la haine, c'est pas évident, surtout si t'es pas payé... C'est de l'esclavage là...
Ou du sado masochisme...
[^] # Je crois en l'esprit libre
Posté par Cedric L'HOMME . Évalué à 5.
Si c'est reelement ce que tu penses :
Fait coder un gars (ou une fille bien sur) sur un projet qui ne l'interesse pas sans le remunerer, ce sera deja bien s'il code ...
Fait coder une fille (ou un gars bien sur) sur un projet avec moins de monde, moins de moyen mais ou elle (il) s'eclate, fait ce qu'elle semble bien, adhere au projet et tu obtiendras une brique pour construire un joli mur.
J'espere que tu as compris ce que je voulais dire.
Bien qu'il est plus simple de croire dans le logiciel libre quand on a vecu les deux cas.
A++
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.