TPE ?

• [^]Re: TPE ?

  Posté par Loic Jaquemet (page perso, ) le 04/06/2002 à 07:50. (lien). Évalué à 15.

  En gros il ajoute de la securité sur le path des binaires.
  
  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 (page perso, ) le 04/06/2002 à 07:59. (lien). Évalué à 37.

    Non, c'est pas ca. TPE, ca interdit l'éxécution en dehors de path définis à l'avance.
    
    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 () le 04/06/2002 à 07:56. (lien). Évalué à 25.

  Le TPE permet de n'executer que les binaires étant dans des répertoires dont root est le propriétaire et qui ne sont pas ouverts en écriture à tout le monde.
  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 () le 04/06/2002 à 08:08. (lien). Évalué à 14.

    apparement (je viens de lire les liens que j'ai posté en dessous), TPE fait ce que tu dis effectivement. De plus il garde une liste de user qui ont le droit d'executer des binaires et a chaque lancement l'UID est cherché dans la liste.
    
    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 (page perso, ) le 04/06/2002 à 09:02. (lien). Évalué à 27.

      Non, noexec ne sert à rien du point de vue de la sécurité. Pour un script shell, on peut faire :
      
      /bin/sh /tmp/vilain_script.sh
      
      Pour un binaire :
      
      /lib/ld-linux.so.2 /tmp/vilain_binaire

      • [+] [^]Re: TPE ?

        Posté par PLuG () le 04/06/2002 à 09:21. (lien). Évalué à -2.

        oups mea culpa, j'avais oublié cette astuce ...

    • [^]Re: TPE ?

      Posté par Jerome Alet (page perso, ) le 04/06/2002 à 11:31. (lien). Évalué à 0.

      Mais non !
      
      La meilleure solution pour éviter la casse est de monter /home /tmp et /var en READONLY.
      
      :-))

• [^]Re: TPE ?

  Posté par PLuG () le 04/06/2002 à 07:57. (lien). Évalué à 27.

  TPE est apporté sur OBSD par les patch "stephanie" décrits ici: http://c0ke.kaizo.org/mirrors/stephanie/(...)
  
  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 (Jabber id, ) le 04/06/2002 à 08:05. (lien). Évalué à 6.

    trustedbsd ...
    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 () le 04/06/2002 à 09:00. (lien). Évalué à 28.

      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..)

      
      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.
      
      

      Zeiram

      • [^]Re: j'en ai oublié un - cassage de clés

        Posté par zeiram () le 26/07/2002 à 16:54. (lien). Évalué à 1.

        Bon, puisque personne ne l'a fait et que je viens de retrouver l'information, je vais me répondre à moi-même (car je n'aime pas laisser des questions en suspens).
        
        

        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 ?

        
        
        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.
        
        

        Zeiram

        
        
        [1] 1 MIPS.an correspond à 2^45 opérations élémentaires.

    • [^]Re: j'en ai oublié un

      Posté par Spadone Pascal (page perso, ) le 04/06/2002 à 09:01. (lien). Évalué à 15.

      Attention aux amalgames !
      
      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 (Jabber id, ) le 04/06/2002 à 09:07. (lien). Évalué à -3.

        Merci
        je l'avais sans doute déja lue reste a s'en rappeler ;)

    • [^]Re: j'en ai oublié un

      Posté par vjm () le 04/06/2002 à 14:17. (lien). Évalué à 4.

      Raaaaaah faut arrêter de voir des forks partout !
      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 !)

      --
      vjm

      • [^]Re: j'en ai oublié un

        Posté par vjm () le 04/06/2002 à 14:27. (lien). Évalué à 3.

        tiens et pendant que j'y suis, je tiens à signaler que bien que peu connu, FreeBSD possède depuis déjà quelques temps son propre projet de source auditing.
        
        http://www.freebsd.org/auditors.html(...)

        --
        vjm

[+] Troll a donf.....

• [+] [^]Re: Troll a donf.....

  Posté par earxtacy (Jabber id, ) le 04/06/2002 à 08:17. (lien). Évalué à -4.

  j'arrive pas a trouvé de trace de ce fork,
  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

• [^]Re: pour résumer

  Posté par DaFrog () le 04/06/2002 à 08:21. (lien). Évalué à 16.

  Pas tout à fait:
  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 (page perso, ) le 04/06/2002 à 08:31. (lien). Évalué à 11.

    Je parlais des fonctionnalités, pas de la manière dont c'est distribué.
    
    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 (page perso, ) le 04/06/2002 à 08:38. (lien). Évalué à 15.

      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.
      
      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 () le 04/06/2002 à 09:14. (lien). Évalué à 6.

  MicroBSD semble etre un environnement (aka distribution sous linux). TrustedBSD est un projet fonde par le DARPA pour ajouter des extensions a FreeBSD qui seront rajoute par la suite. Je pense d'ailleurs que la plupart des extensions arrivent dans FBSD 5

1024, 2048, etc

• [^]Re: 1024, 2048, etc

  Posté par Salica () le 04/06/2002 à 08:32. (lien). Évalué à 21.

  D'un point de vue théorique, si tu considères que ton algorithme de chiffrement est parfait, la 'sécurité' du chiffrage ne dépend que de la longueur de la clef.
  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 () le 04/06/2002 à 08:52. (lien). Évalué à 10.

    le one time pad est pas parfait nom plus:
    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 () le 04/06/2002 à 12:57. (lien). Évalué à 6.

      C'est vrai que le gros problème du One Time Pad c'est l'échange des clefs.
      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 () le 04/06/2002 à 15:46. (lien). Évalué à 1.

        >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.
        
        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 () le 04/06/2002 à 18:58. (lien). Évalué à 1.

          Eh oui, et le procédé, utilisé aussi par l'armée francaise s'appellait TAREC, pur ceuxes qui ont fait leur armée dans des temps préhistoriques.
          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 () le 04/06/2002 à 09:37. (lien). Évalué à 12.

    Pas complètement d'accord là.
    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

    --
    Kha
    root est un privilège, pas un droit !

    • [^]je ne comprends pas

      Posté par Ice Lion (page perso, ) le 04/06/2002 à 11:13. (lien). Évalué à 6.

      > 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).
      
      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 () le 04/06/2002 à 17:09. (lien). Évalué à 2.

        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...
        
        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.

        --
        Kha
        root est un privilège, pas un droit !

    • [^]Re: 1024, 2048, etc

      Posté par PLuG () le 04/06/2002 à 11:35. (lien). Évalué à 4.

      pour le one time pad, tu peux utiliser des cartes que tu pioches dans un chapeau.
      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 (Jabber id, page perso, ) le 04/06/2002 à 11:46. (lien). Évalué à 5.

      Tout ca pour dire que ton One-Time-Pad je vois pas bien comment ca marche.
      
      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 (page perso, ) le 04/06/2002 à 13:41. (lien). Évalué à 3.

        - 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.
        
        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 (page perso, ) le 04/06/2002 à 15:10. (lien). Évalué à 2.

      One Time PAD :
      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 (page perso, ) le 04/06/2002 à 08:46. (lien). Évalué à 7.

  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 ?
  
  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

• [^]Re: les clefs de cryptages

  Posté par PLuG () le 04/06/2002 à 08:15. (lien). Évalué à 9.

  A la lecture je me suis fait la meme reflexion que toi, puis je me suis dit qu'avec un budget de 5M, on peut en investir 4% pendant 5 ans pour obtenir le resultat escompté ...
  
  reste que toutes ces affirmations sont un peu gratuites effectivement.

  • [^]Re: les clefs de cryptages

    Posté par kael () le 04/06/2002 à 08:44. (lien). Évalué à 2.

    ben meme ca ca reste enorme!, surtout que ils ont quand meme pas que ca a financer!
    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 () le 04/06/2002 à 08:31. (lien). Évalué à 10.

  s/cryptage/chiffrement
  
  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 () le 04/06/2002 à 09:14. (lien). Évalué à 16.

    Effectivement, la NSA peut avoir déjà de tels algorithmes. Pour se convaincre que ce n'est pas de la paranoïa, une lecture de l'excellent livre Applied Cryptography (désolé, je ne sais pas quel est son titre en français bien que je sache qu'il a été traduit) de Bruce Schneier en apporte une preuve.
    
    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).
    
    

    Zeiram

    • [^]Re: les clefs de cryptages

      Posté par Mathieu Dessus (page perso, ) le 04/06/2002 à 10:35. (lien). Évalué à 7.

      En français le titre est Cryptographie appliquée tout simplement.
      
      
      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 (page perso, ) le 04/06/2002 à 11:16. (lien). Évalué à 1.

      pourquoi seule la NSA aurait été au courant ? ce n'est pas cohérent...

      • [^]Re: si c'est un universitaire qui l'avait trouvé

        Posté par zeiram () le 04/06/2002 à 11:45. (lien). Évalué à 5.

        L'universitaire qui l'a trouvé n'a fait cette découverte que vingt ans après la sortie du DES. Lorsque le DES a été conçu, l'algorithme de déchiffrement différentiel n'existait pas pour le grand public.
        
        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.
        
        

        Zeiram

• [^][HS] Budget NSA

  Posté par Def () le 04/06/2002 à 09:00. (lien). Évalué à 3.

  Le budget de la NSA est secret (voir la FAQ sur http://www.nsa.gov/about_nsa/faqs_internet.html(...) ), il n'y a donc aucune source officielle. Au niveau des estimations, the register parle de 30 milliards de $.
  
  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...

• [^]Re: Le logiciel libre vers le chaos...

  Posté par spim () le 04/06/2002 à 12:32. (lien). É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...

• [^]Je crois en l'esprit libre

  Posté par Cedric L'HOMME () le 04/06/2002 à 11:58. (lien). Évalué à 5.

  Si tu postes ca pour flooder ou troller, je pense que tu n'as pu le faire que deux fois car apres tu as eu un ecran bleu ...
  
  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++