• # Re: RC5 : on va casser du 72 bits...

    Posté par  . Évalué à 6.

    Et si vous préférez contribuer à un projet utile, vous pouvez aussi regarder du côté du Folding@home, ou de Genome@home (le client est le même, on peut choisir son projet ou contribuer aux deux) :

    http://folding.stanford.edu/(...)
    http://genome-www.stanford.edu/(...)

    Il y a aussi une équipe linuxfr : http://folding.stanford.edu/cgi-bin/teampage.detailed?q=11269(...)

    • [^] # Re: RC5 : on va casser du 72 bits...

      Posté par  . Évalué à 3.

      RC5 me semble pas si inutile que ca.
      Il permet qd mm d'avoir une idee de la solidite de certains cryptages...

      • [^] # Re: RC5 : on va casser du 72 bits...

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Si c'est nul, même nmap le dit :-)


        
$ grep 2064 /usr/share/nmap/nmap-services
        
distrib-net-losers 2064/tcp  # A group of lamers working on a silly closed-source client for solving the RSA cryptographic challenge.  This is the keyblock proxy port.



        Blague dans le coin, c'est vrai qu'on peut débattre longtemps sur l'utilité de casser du code alors que l'Humanité a sans doute plus besoin du projet Genome et Foldin par exemple. Il reste néamoins que Distributed.net a pu tester ainsi une méthode de calcul distibué qui a fait ses preuves. (et on a pu jouer pendant 3 ans à celui qui avait le plus gros zizi^H^H^H^Hpc )

        • [^] # Re: RC5 : on va casser du 72 bits...

          Posté par  . Évalué à 1.

          Personellement, je préfère casser du RC5 que du génome.
          Le RC5, c'est défendre la liberté.
          Par contre, décoder du génome pour qu'une obscure boite américaine dépose un brevet sur le gène en question, non.

          Ils ne passeront pas par moi.

          • [^] # Re: RC5 : on va casser du 72 bits...

            Posté par  (Mastodon) . Évalué à 0.

            Juste un truc, t'as pas du te renseigner beaucoup avant de te faire ce genre d'opinions sinon tu saurais qu'il ne s'agit pas de décoder des génomes, que le projet est mené par une université, et que les résultats sont publics.

      • [^] # Re: RC5 : on va casser du 72 bits...

        Posté par  . Évalué à 7.

        Je ne vois pas en quoi une attaque par la force brute donne une idée de la robustesse d'un code de chiffrement. Si on se contente d'essayer des clés les unes après les autres, alors à un facteur près (lié à la complexité des calculs), tous les algoritmes se valent... Enfin ça permet toujours de savoir si une taille de clé donnée est adaptée aux capacitées de calculs, à un moment donné (mais on connait déjà la réponse : oui). Mais on ne m'enlèvera pas de l'idée que ça sert avant tout à prouver la supériorité de sa config sur celle de ses copains.

        A la limite, le OGR25, toujours chez distributed.net, c'est déjà un peu plus utile puisque ça a quelques applications. Le Seti@home c'est un peu différent, il y a une dimension philosophique là dedans. Mais sincèrement, si on cherche un projet vraiment utile, je ne vois d'autre chose que folding/genome@home. Seul problème par rapport aux autres : les statistiques ne sont pas aussi raffinées, les options de téléchargement des blocs sont moins nombreuses, et moins de plateformes sont supportées.

        • [^] # la robustesse par les maths, c'est plus dur !

          Posté par  . Évalué à 1.

          En effet, à part le OneTimePadding (OTP), je ne connais pas d'algorithme de chiffrement dont on a démontré qu'il est impossible de trouver un algorithme ingénieux pour le casser très rapidement.

          Prouver qu'un algo est résistant à la force brute (tous le sont en augmentant la taille des clés) ne nous protège pas d'attaques + intelligentes effectuées par des mathématiciens (qui sont nombreux dans le monde du renseignement).

          L'OTP supposant le renouvellement d'une énorme clé secrète stockée sur un support physique (CDR,disque dur,...), il ne peut être utilisé que pour communiquer avec des amis que l'on peut rencontrer physiquement de temps en temps. Il en est de même pour une stegano efficace.


          PS. Les réseaux p2p où on ne se connecte directement qu'à nos amis, sont les seuls actuellement à pouvoir garantir la confidentialité et la discrétion: http://free2.org/p/(...)

      • [^] # Re: RC5 : on va casser du 72 bits...

        Posté par  . Évalué à -1.

        RC5-56 a été utile, mais après, c'est juste des maths pour extrapoler le temps nécessaire pour craquer la clé.

        donc bon...

    • [^] # Re: RC5 : on va casser du 72 bits...

      Posté par  . Évalué à 1.

      Folding@home, c'est vachement OpenSource !!??

      cf. http://folding.stanford.edu/license.txt(...)

      Restrictions:

      You may use this software on a computer system only if you
      own the system or have the permission of the owner.

      You may not alter the software or associated data files.

      You may only use unmodified versions of Folding@home obtained
      through authorized distributors to connect to the Folding@Home
      servers. Use of other software to connect to the Folding@home
      servers is strictly prohibited.

      Distribution of this software is prohibited. It may only be
      obtained by downloading from http://folding.stanford.edu.(...)

      • [^] # Re: RC5 : on va casser du 72 bits...

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Et alors ?
        Pour la première clause, je suis tout à fait d'accord avec eux. Avoir un ordinateur allumé et qui use du temps CPU coûte en électricité et donc en argent. Il me semble donc normal que seul le propriétaire de la dite machine soit le seul à autoriser l'utilisation d'un tel programme.

        La deuxième clause me semble aussi tout à fait normal. On parle ici du décryptage du génome et pas d'une soft pour télécharger des MP3, DIVX et consorts sur le Net, la fiabilité est un point dur sur ce projet. Les enjeux ne sont pas les mêmes que sur les softs habituels, on parle quand même à terme de santé publique. Imagine un peu si quelqu'un publie une modif qui se intervertit un T et un A lors de l'interprétation de la chaine ADN, toute la recherche devient caduque. Il est donc normal que seuls les gens compétents puissent avoir un droit de regard sur le code.

        Enfin, la dernière clause évite en principe la prolifération de chevaux de Troie.

        • [^] # Re: RC5 : on va casser du 72 bits...

          Posté par  . Évalué à 1.

          > Pour la première clause, je suis tout à fait d'accord avec eux. Avoir un ordinateur allumé et qui use du temps CPU coûte en électricité et donc en argent. Il me semble donc normal que seul le propriétaire de la dite machine soit le seul à autoriser l'utilisation d'un tel programme.

          D'autant plus qu'il y a quelques temps, il me semble avoir lu une news sur un administrateur systeme qui avait été condamné pour avoir installé et executé Dnet sur les machines qu'il gérait....
          C'est surtout une clause qui evite les possibles retour judiciaires contre eux au cas ou ce type de condamnation se produise à nouveau.

    • [^] # Re: RC5 : on va casser du 72 bits...

      Posté par  . Évalué à 0.

      heu j'ai essayé de voir un peu les liens proposés... vu que je sétise déjà un peu ... mais est ce normal pour
      http://folding.stanford.edu/(...)
      que pour linux soit proposé un .exe ?

      • [^] # Re: RC5 : on va casser du 72 bits...

        Posté par  . Évalué à 1.

        bah si vraiment ça te gene tu le renome :)
        En fait moi aussi ça m'a fait bizarre, mais c'est bien un binaire linux ...
        Sans doute pour bien monter que c'est un executable ...

    • [^] # Re: RC5 : on va casser du 72 bits...

      Posté par  . Évalué à 1.

      Chez moi le client FAH3Console-Linux.exe segfault gentillement sansen dire plus.
      Dommage.

    • [^] # Re: RC5 : on va casser du 72 bits...

      Posté par  (site web personnel) . Évalué à 2.

      c'est http://gah.stanford.edu/(...) l'URL de Genome@Home.

  • # Logiciel proprietaire...

    Posté par  . Évalué à 2.

    Et oui le RC5 c'est bien gentil mais c'est pas du tout opensource !
    Je pense que c'est qqch qui est qd mm un peu problematique.
    Ils ont beau expliquer en détails toutes leurs bonnes raisons de pas donner les sources, ils avouent que de toute facon c'est pas une solution absolue :

    Honnêtement, la seule distribution des exécutables n'élimine pas toute possibilité de sabotage car il est relativement simple, pour quelqu'un ayant les connaissances suffisantes, de désassembler ou de patcher les fichiers exécutables. C'est dans l'ordre du faisable et c'est pourquoi nous vous encourageons à ne pas essayer. La sécurité par l'obscurité n'est certes pas fiable du tout mais nous ne prétendons aucunement qu'elle le soit.

    Neanmoins, ils essayent de trouver une solution :

    Un des buts principaux de la prochaine génération de clients "v3" est d'implémenter un système d'authentification du code et/ou du noyau et diverses autres vérifications de manière à ce que l'open-source devienne viable.

    En conclusion, ceux pour qui le mot libre a vraiment un sens attendront avant de se mettre au rc5 ...

    • [^] # Re: Logiciel proprietaire...

      Posté par  (site web personnel) . Évalué à 1.

      C'est un beau challenge de vouloir faire un système pour des trucs style RC5 qui soit libre et où il soit difficile de tricher. Plus intéressant que de casser des clés en tout cas :)

      Par contre je ne vois pas trop comment faire... (sauf en ne supportant que du matériel qui execute du code certe libre mais signé... (hum hum))


      --
      Thomas, qui a arrêté tout ses clients RC5 après la fin de RC5-64 et dont les machines respirent un peu.

      • [^] # Re: Logiciel proprietaire...

        Posté par  (site web personnel) . Évalué à 1.

        faire calculer chaque test plusieurs fois et comparer les résultats pour valider ?

        bon, par contre ca ralenti pas mal la découverte de solutions

        • [^] # Re: Logiciel proprietaire...

          Posté par  . Évalué à 3.

          Oui, c'est déjà la solution choisie par seti@home, chaque unité de travail est envoyée au moins à deux clients, s'ils reçoivent deux réponses identiques venant d'utilisateurs différents (et aucune contradictoire) ils considèrent le résultat comme bon et suppriment l'unité de travail.

    • [^] # Re: Logiciel proprietaire...

      Posté par  . Évalué à 2.

      Faute...

      cf http://www.distributed.net/source/(...)

      <quote> Here is where you can download it from:

      * pub-20021029.tar.gz (1585 KB) includes only RC5-72, OGR (released Oct 29 2002)
      * pub-20010416.tgz (2857 KB) last source release that included RC5-64, OGR, DES, CSC (released Apr 16 2001)
      </quote>

      • [^] # Re: Logiciel proprietaire...

        Posté par  . Évalué à 1.

        Par contre ce ne sont pas les sources complètes du client...

        Can I build a working distributed.net client with this source?


        No. Even if these sources comes with buffer updating routines, they are definitely not compatible with buffers generated by the full client.


        Mais bon, personnellement ça ne me dérange pas vraiment de ne pas avoir les sources... ils ont de bonnes raisons pour ne pas les donner et je trouve ça déjà bien qu'ils en donnent une partie (qui doit permettre aux gens de vérifier l'algorithme sans pour autant pouvoir faire un client alternatif potentiellement mauvais)

  • # RC5 : à quand les stats?

    Posté par  (site web personnel) . Évalué à 1.

    Oui, c'est quand qu'elles arrivent, les stats? Parce que pour l'instant, sur http://stats.distributed.net/projects.php?project_id=8(...) c'est pas exactement au point ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.