Concours distributed.net RC-5, a l aide!!!

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
14
jan.
2001
RC5
Je viens de jeter un coup d oeil sur les stats du concours RC5-64. L'équipe linuxfr est en perte de vitesse et serieusement menacée par des equipes qui lui collent aux baskets. Alors à vos bécanes! Ne nous laissons pas faire!
Téléchargez le client adapté à votre bécane (linux evidemment :)) et roulez jeunesse :). On a besoin de vous!

Aller plus loin

  • # Question!

    Posté par  . Évalué à 1.

    C'est quoi ce truc ?

    • [^] # Re: Question!

      Posté par  . Évalué à 1.

      Le but de distributed.net est de créer un réseau de calcul distribué. Tu récupères un client sur leur site, le client récupère des blocs, les calculent et renvoie le résultat.
      Pour plus d'infos sur d.net, http://www.distributed.net(...)

  • # Tsss

    Posté par  . Évalué à 1.

    Le plus amusant c'est de voir dans les stats:
    8 The Amiga RC5 Team effort

    Pas mal pour une machine que tout le monde dit morte et enterree, a croire que ces bonnes vieilles machines sont encore bien vivantes et respirent la sante.

    • [^] # Re: Tsss

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

      oui enfin il faudrait voir quelle machine tourne derriere ...

      • [^] # Re: Tsss

        Posté par  . Évalué à 1.

        Des amigas évidemment, quelle question ...

        • [^] # Re: Tsss

          Posté par  . Évalué à 1.

          Je vais lancer la CPC 464 Team... Ca en jette aussi comme nom :-)

  • # et A/UX?

    Posté par  . Évalué à 0.

    Y'a meme pas de client pour A/UX.... Et le client mac plante serieusement le finder de A/UX...

  • # Et les sources ?

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

    Question peut-être stupide, mais pourquoi n'y a-t-il que des binaires à télécharger ?

    • [^] # Re: Et les sources ?

      Posté par  . Évalué à 1.

      Probablement pour éviter que des petits malins ne modifient le code pour gonfler leurs résultats... Ou en tout cas pour leur compliquer la tâche.

    • [^] # Re: Et les sources ?

      Posté par  . Évalué à 1.

      Ils le disent sur leurs sites, c'est pour éviter que des petits malins se trafiquent un client qui envoie des blocs validés qui ne sont pas calculés (sachant qu'il y a des sous pour le gagnant du concours rc5, il faut prendre des précautions).

      • [^] # Re: Et les sources ???

        Posté par  . Évalué à 0.

        Ouais mais du coup, ça veut dire qu'on ne sait pas ce qui est calculé, finalement...

        logiquement, si l'on suit ce principe, le code source d'aucun logiciel ne devrait etre délivré, si ça le rend vulnérable. Par exemple, ne pas distribuer apache, car, selon ce raisonnement, la disponibilité rend plus facile le traffic, les magouilles, et donc affaibli la sécurité.

        Alors ?

        Je ne comprend plus : ainsi vous voudriez (comme selon les discussions générales, par exemple sur les systèmes de vote informatisés) que les sources soient disponible tout le temps sauf là ?


        Y'a comme une incohérence, non ?

        Distributed net comme windows : on ne donne pas le source pour éviter qu'on y voie les failles ???

        • [^] # Re: Et les sources ???

          Posté par  . Évalué à 0.

          tout a fait d'accord.

        • [^] # Re: Et les sources ???

          Posté par  . Évalué à 0.

          tu vois que t pas si bete :)

          • [^] # Re: Et les sources ???

            Posté par  . Évalué à 0.

            « tu vois que t pas si bete :) »

            c'est gentil à toi. Pourquoi incite t-on ici à y participer alors ?

        • [^] # Re: Et les sources ???

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

          Il n'y a pas d'incoherence...

          reflechit un peu plus longtemps a ce que fait exactement un client distributed.net

          La programmation d'un client open-source qui ne permet pas facilement de tricher est un challenge interessant. Mais je n'ai strictement aucune idée de comment faire...

          Les jeux reseaux on en partit resolue le probleme de la triche en mettant toute la gestion coté serveur. C'est impossible pour distributed.net

          • [^] # Re: Et les sources ???

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

            La question est :
            comment le serveur peut etre _sur_ que le client a bien effectué les calculs ?

            Bonne chance.

            • [^] # Re: Et les sources ???

              Posté par  . Évalué à 0.

              donc la sécurité de distributed.net est faite pas l'ignorance.

              comme celle de NT server...

              sympathique.

              comment ? je ne suis pas developpeur mais je pense qu'en y réflechissant bien, on pourrait aboutir à quelque chose :

              on pourrait imaginer l'attribution d'un caractère particulier (non connu) à chaque client compilés et distribués par distributed.net qui seraient les seuls à pouvoir envoyer les infos aux serveurs distributed.net. Les clients compilés par soi-meme (ailleurs que sur les machines de distributed.net donc, pas ceux distribués) ne marcheraient pas sur les serveurs de distributed.net mais pourraient etre étudié pour les failles et pour les autres projets du meme type.
              C'est une idée venue en 1 minute, en cherchant bien, on doit pouvoir trouver plein plein de possibilités...

              • [^] # Re: Et les sources ???

                Posté par  . Évalué à 0.

                Rien ne prouve que le binarie du client compilé est alors bien a partir des sources fournis.
                D'autre part, un diff sur le binaire proposé et le binaire compilé soit-meme resous facilement le probleme.

                • [^] # Re: Et les sources ???

                  Posté par  . Évalué à 0.

                  Ben si le binaire est modifié, il n'est pas le meme que celui du serveur... donc le serveur le vérifie et envoie chier le client.

                  C'était une idée en passant, une idée d'une minute. Je pense qu'on doit pouvoir trouver bien bien mieux.

                  Je ne veux pas débattre sur cette proposition, elle n'a aucune importance, ce n'est qu'une illustration. Débattons du fond : le libre à donc des limites en terme de sécurité ?

                  Si le code du GNU/linux est libre, pourquoi n'est-il pas si facile de faire des intrusions dans ces machines ?

                  • [^] # Re: Et les sources ???

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

                    > Ben si le binaire est modifié, il n'est pas le
                    > meme que celui du serveur... donc le serveur
                    > le vérifie et envoie chier le client.

                    Bonne idée!
                    Bon... Comment tu fais pour vérifier que le client est le meme que celui d'origine? Tu lui demande?

                    > Si le code du GNU/linux est libre, pourquoi
                    > n'est-il pas si facile de faire des intrusions
                    > dans ces machines ?

                    Tu fais un amalgame entre "facilité de trouver des failles dans un logiciel" et "facilité de determiner si un client n'est pas en train de m'envoyer des infos erronées"

                    • [^] # Re: Et les sources ???

                      Posté par  . Évalué à 1.

                      tu calcule le md5sum ... et hop ..c'est bon ..

                    • [^] # Re: Et les sources ???

                      Posté par  . Évalué à 0.

                      T'oublies les dernières phrases de mon message, c'est génant : je ne désire pas discuter d'une technique. La technique, ça se cherche, ça se trouve.

                      Soit le libre est viable dans toutes conditions, soit pas.

                  • [^] # Re: Et les sources ???

                    Posté par  . Évalué à 1.

                    La vérification de la validité d'un calcul et une trou de sécurité n'est peut-être pas la même chose.

                    La vérification du calcul peut être une solution technique à un problème de sécurité.
                    Or, dans le cas en présence, je ne pense pas que cette solution soit pertinente.

                    Comment vérifier que le résultat transmis en correcte sans recalcul ?


                    Hormis ce point technique, c'est aussi une question de confiance et de motivation personnel.
                    Si on préfère le calcul distribué publiquement pour une exploitation publique des résultats à une solution privée et élitiste, alors distributed.net s'impose.

                    Philou

            • [^] # Re: Et les sources ???

              Posté par  . Évalué à 0.

              J'ai rencontré le concepteur de Seti At Home, on lui a posé la même question, il a répondu qu'il faisait faire les calculs deux fois par deux machines aux hasard. Pour RC5 je pense que ca doit etre le meme topo parceque sinon y'a pas moyen d'etre _sur_ que personne ne triche

              • [^] # Re: Et les sources ???

                Posté par  . Évalué à 0.

                Exactement. Tu introduis un peu de redondance, et si les résultats sont différents, tu mènes l'enquête, et tu quand tu as trouvé le fraudeur tu lui remets son compteur à zéro et tu supprimes son compte. En général ça calme les petits malins.

          • [^] # Re: Et les sources ???

            Posté par  . Évalué à 0.

            Ce que tu dis, c'est que le fait que si le client était ouvert, on pourrait plus facilement le détourner..

            Le problème c'est qu'avec un client fermé, finalement on ne peut meme pas vraiment savoir ce que fais notre machine. backdoor et tout ça, pourquoi pas ?

            Pourquoi ne pas faire en sorte que le serveur ait des attentes particulières de la part du client qu'il fasse qu'il doive etre conforme à ce qu'on attends de lui.. ?


            Il y'a toujours une incohérence : comment clamer que le libre permet une fiabilité supérieure au proprio si pour une opération sensible on ne lui fait plus confiance ?

            Ton discours remet en cause la fiabilité de tout les systèmes libres (openssh etc...).

            • [^] # Re: Et les sources ???

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

              Mais tu mélange tout !

              Dans ce cas précis, et seulement dans ce cas, la diffusion des sources pose un problème de tricherie, mais en aucun cas un problème de sécurité.

              C'est une technique habituelle que de mélanger les propos, pour faire croire à un raisonnement.
              ;-)

              • [^] # Re: Et les sources ???

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

                Dans mes bras !

              • [^] # Re: Et les sources ???

                Posté par  . Évalué à 0.

                une tricherie, n'est ce pas l'exploitation d'une faille dans le modèle de sécurité ?

                exemple, tricher aux cartes, c'est exploiter les failles dans la vigilance (le modèle de sécurité) de l'adversaire.

                « C'est une technique habituelle que de mélanger les propos, pour faire croire à un raisonnement. »

                Avant de vouloir évaluer mes raisonnement, essaye de mesurer le sens du terme « propos ».
                (sans smiley, na !)

            • [^] # Re: Et les sources ???

              Posté par  . Évalué à 1.

              >> Il y'a toujours une incohérence : comment clamer que le libre permet une fiabilité supérieure au proprio si pour une opération sensible on ne lui fait plus confiance ? <<

              Qui a clame que le libre permet une fiabilité supérieure au proprio et pour une opération sensible ne lui fait plus confiance ?
              Personne ici il me semble. Envoies ta question a distributed.net si ils ont clame cela.
              Maintenant, je ne vois pas ce que la fiabilite vient faire dans le debat. Je croyais qu'on parlait de securite de l'utilisateur...

          • [^] # Re: Et les sources ???

            Posté par  . Évalué à 0.

            alors, on fait pas.

            • [^] # Re: Et les sources ???

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

              Evidement... si tu es un intégriste tu peux rejeter en bloc tout ce dont tu n'as pas les sources. Le bios de ton PC ou le controleur de ta machine a laver par example.

              Bon... J'arrete mes commentaires sur cette news. Le site de distributed explique clairement pourquoi les sources ne sont pas dispo. Ils indiquent aussi que cet obscurantisme n'est pas une solution au probleme de triche. Ca rend juste la triche plus difficile. Propose-leur un client securisé open-source qui reponde a leur problème, ils seront tres heureux.

              • [^] # Re: Et les sources ???

                Posté par  . Évalué à 0.

                « obscurantisme », « intégrisme », des mots qui deviennent creux à force d'etre usités à tout bout de champ.

                Le bios de mon PC et ma machine à laver ne produisent rien de particulier qui ne me serve.

                Distributed.net, pour reprendre mon exemple (un peu gros) peu servir à tout et n'importe quoi : armement bactériologique, clonage etc... Choses que je ne désire pas cautionner ou aider.

                « Ca rend juste la triche plus difficile » : donc la triche sous NT est plus dure que sous GNU/Linux.
                Soit.
                Donc distributed.net, c'est comme les cartes bleues, la sécurité c'est l'ignorance.

                Au lieu de vouloir faire des calculs dans tout les sens, peut etre pourraient-ils chercher à créer un système fiable. Système qui profiterait d'ailleurs à tout les projets équivalents.

                Une fois de plus tu ne réponds pas à la question : les logiciels libres ne sont-ils pas un gage de sécurité.
                Tu fais effectivement peut-etre bien de t'arreter là. Ca devient lassant de poser toujours la meme question et de la voir toujours ainsi évitée.

                • [^] # Re: Et les sources ???

                  Posté par  . Évalué à 1.

                  >>la triche sous NT est plus dure que sous GNU/Linux.
                  Soit.

                  Je crois que tu te méprends sur certains points :
                  Le but de la sécurité des applications est en général d'empêcher une intrusion. Dans ce type de système, il y a des utilisateurs auxquels on fait 'aveuglément' confiance (l'administrateur par exemple), ceux qui ne sont pas censés avoir de droits particuliers, et ceux qui ne doivent pas avoir accès aux données.
                  Et c'est justement ces données que le système d'exploitation doit protéger. Donc, si le code source des programmes est dévoilé mais qu'il ne pose pas de problèmes de sécurité évident, les données seront protégées.
                  Le problème est tout autre pour des projets du type de distributed.net, car tout ceux qui ont un client peuvent envoyer des données. Il faut donc éviter que ces données puissent être générées par une source qui n'est pas digne de confiance (le type qui a trafiqué les sources), et qu'elles soient presqu'à coup sûr originaires du client non modifié.
                  Une solution pratique est donc de cacher les sources, même si ce n'est pas forcément la meilleure. A partir de là, tu choisis soit de participer, soit de ne pas participer, soit de monter ton projet Open Source.

                  En espérant avoir répondu à ta question.

                  • [^] # Re: Et les sources ???

                    Posté par  . Évalué à 0.

                    pour répondre à la question, il aurait fallu que tu répondes aux postes ci-dessous.

                    je ne vois pas ce que vient foutre le sacro-saint « fait toi-meme là dedans ».

                    (« j'aime pas trop peete sampras - fais le toi meme ! »)

                    • [^] # Re: Et les sources ???

                      Posté par  . Évalué à 1.

                      Excuses-moi, je ne peux répondre qu'aux posts au-dessus de ma réponse.
                      Je ne t'ai pas demandé de tout faire toi-même, je t'ai juste proposé différentes options. Personnellement je n'ai rien à voir avec Distibuted.net, si tu as un problème avec leur client tu peux aussi les contacter pour leur proposer une meilleure solution. Pas forcément le code, même les idées sont sûrement les bienvenues.

                      >> (« j'aime pas trop peete sampras - fais le toi meme ! »)
                      Encore une fois, Pete Sampras n'a sûrement strictement rien à faire de ton avis sur lui. Si tu ne l'aimes pas, tu peux lui écrire pour lui demander qu'il change les points qui ne te conviennent pas chez lui, même si je doute fortement qu'il soit intéressé. Ou sinon supporter quelqu'un d'autre ou même devenir toi-même champion de tennis :p

                      • [^] # Re: Et les sources ???

                        Posté par  . Évalué à 0.

                        Pour continuer sur la lignée de peete sampras, (mais on pourrait parler du présentateur de qui veut gagner des millions pour donner un exemple plus « palpable »), évidemment qu'il s'en branle de mon avis.
                        Mais j'ai le droit d'en avoir un sans moi meme etre champion de tennis... et sans meme chercher à le devenir ou m'investir dans des actions inutiles (lui écrire).

                        Pour distributed.net, je pense qu'ils ont déjà du etre confrontés à ces questions. Apparement ils ont tranchés. J'ai le droit de dire que leur choix ne me plait pas, qu'il fait que je ne participerait pas à leur truc et que je n'inciterai personne à le faire.

                        C'est quoi le libre sinon faire des choses qui n'était pas possible avant ... ? Faire un système de calcul distribué clair, ça en serait un... peut-etre meme plus interessant qu'un challenge de cassage de clé

                        • [^] # Re: Et les sources ???

                          Posté par  . Évalué à 1.

                          >>Pour distributed.net, je pense qu'ils ont déjà du etre confrontés à ces questions. Apparement ils ont tranchés.

                          Je ne crois pas qu'ils aient eu le choix. Il fallait que les données qui sont traitées sur les machines participantes donnent un résultat cohérent, c'est à dire qui puisse être considéré fiable. Le problème, c'est que si tu libères les sources, des personnes "mal intentionnées" pourraient étudier beaucoup plus facilement la façon dont sont envoyées les données et par là même détourner le sytème en se créditant de beaucoup plus de temps de calcul que ce qu'ils ont réellement effectué.Evidemment, cacher les sources ne résout pas le problème, mais il le diminue fortement.
                          Ceci n'est pas vrai pour les logiciels qui fonctionnent dans l'autre sens, à savoir le client fournit la matière première et le serveur fournit les données après traitement en fonction des paramètres.

                          >> Mais j'ai le droit d'en avoir un
                          Je ne conteste pas ton droit d'avoir un avis

                          >> C'est quoi le libre sinon faire des choses qui n'était pas possible avant ... ? Faire un système de calcul distribué clair, ça en serait un... peut-etre meme plus interessant qu'un challenge de cassage de clé

                          Entièrement d'accord. S'il est possible de réaliser un tel système, je le soutiendrais volontiers.

        • [^] # Re: Et les sources ???

          Posté par  . Évalué à 0.

          Rendre les sources disponibles et resoudre le probleme de tricherie est assez complique. Certaines personne disent (sans trop reflechir): "il n'y a qu'a calculer un md5"

          Cette solution ne marche pas. Que fait-on du md5 des blocs renvoyes par les participants? On les compare a quoi? il n'y a pas de reference. Il faudrait recalculer le bloc par un client a qui l'on fait confiance et comparer le md5. Evidemment, recalculer les blocs des participant perds tout l'interet d'un projet distribue.

          Meme si fournir les binaires n'est pas un solution parfaite (il est theoriquement possile de fait du reverse ingineering), ca limite fortement les cas de triche.

          distributed n'ignore pas ce probleme, il est decrit en details ici:
          http://www.distributed.net/source/specs/opcodeauth.html(...)

          distributed envoie periodiquement des "pseudos" blocs aux participants (seulement un fraction des blocs reels). distributed connait la reponse attendue pour cest pseudo blocs et peut donc detecter in client qui n'effectue pas les calculs attendus.

        • [^] # Re: Et les sources ???

          Posté par  . Évalué à 1.

          > le code source d'aucun logiciel ne devrait etre délivré, si ça le rend vulnérable
          Vulnerable a quoi? Le code source va le rendre vulnerable au bidouillage de son utilisateur, tout comme Apache peut devenir vulnerable si tu le bidouilles toi-meme.

          > ainsi vous voudriez que les sources soient disponible tout le temps sauf là ?
          Non, les codes sources devrait etre dispos MEME dans ce cas ci, afin de mieux en proteger les utilisateurs. Autrement dit, dans ce cas ci, tu dois faire confiance a distributed.net comme tu fais confiance a MS. C'est le choix de chacun.

          Tu te demandes pourquoi les sources ne sont pas dispos. C'est parce que le but n'est pas de proteger l'utilisateur du logiciel mais de proteger le logiciel de ses utilisateurs. Autrement dit, cela ne remet en rien en question les qualites de l'open-source en matiere de protection de l'utilisateur.

          Si le logiciel avait ete open-source, alors la securite de l'utilisateur aurait sans doute ete mieux assuree, et distributed.net aurait utilise d'autres methodes pour s'assurer des resultats. Il s'avere que ce n'est pas la solution qu'ils ont retenue, quelles qu'en soient les raisons.

          • [^] # Re: Et les sources ???

            Posté par  . Évalué à 0.

            Apparement, t'as pas vraiment saisi que je défendais la meme idée que toi, mais c'est pas trop grave :))

            • [^] # Re: Et les sources ???

              Posté par  . Évalué à 1.

              Si je l'ai saisi :-)
              Mais comme tu te fais l'avocat du diable, j'essaie de relever le challenge ;-)

    • [^] # Re: Et les sources ?

      Posté par  . Évalué à 1.

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

    • [^] # Re: Et les sources ?

      Posté par  . Évalué à 0.

      Les sources sont disponibles, il y a un lien sur le site :))

  • # allez !

    Posté par  . Évalué à 0.

    j'ai 10 machines qui tournent en permanence avec
    dnetc dessus :)

    • [^] # Re: allez !

      Posté par  . Évalué à 0.

      en gros, t'as dix machines qui font quelque chose que tu ne controlles pas. Pas mal.

      • [^] # Re: allez !

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

        Les gens de distributed.net (ceux qui participent a des projets de crypto interessant depuis plusieurs années, qui en ont remporté et que tu peux rencontré si ca te chante) peuvent effectivement decider de faire faire des calculs pas bien a ta machine.

        Si tu as peur pour tes données personnelles, tu peux executer le client avec un chroot.

        • [^] # Re: allez !

          Posté par  . Évalué à 0.

          Ce n'est pas la question des données personnelles.

          Personnellement, je ne voudrais pas que ma machine serve à faire quelque chose que je ne puisse vérifier. Par exemple, de la recherche dans les armements.

          Tu tiens décidement à répondre à tout les points mais tu fuis le débat essentiel : le libre n'est-il pas une source de sécurité. Selon toi, non. Puisque la connaissance du code permet sa perversion.

          • [^] # Re: allez !

            Posté par  . Évalué à 0.

            Vous savez, il existe des compilateurs certifiants. Ils assurent que le code généré correspond bien au code source. C'est une fausse excuse de ne pas vouloir fournir le code ! Ils sont peut-etre de bonne "volonté" chez distributed.net mais on en sait rien. Personnellement, je fais tourner le client car finalement qu'est-ce qu'on a cacher ! De plus il tourne sous un simple user sans privilèges particuliers.

            • [^] # Re: allez !

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

              Ca a l'air interessant, mais... (ya toujours un mais)

              Les serveurs de distributed ne voient de leurs clients que ce que ceux ci leur envoient par le reseau. Ils n'ont _aucun_ controle sur la plateforme qui execute le code, le compilateur utilisé, etc...

              Quelqu'un a une URL expliquant ce que certifie exactement un compilateur certifiant, et dans quelles conditions ?

          • [^] # Re: allez !

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

            Pour le premier point : Comme le client est effectivement fermé, tu fais confiance aux gens de distributed quand a l'utilisation de ta machine. Perso, je pense que distributed.net utilise ses clients pour chercher des clés rc5 et des regles de coulombs optimales vu qu'ils en trouvent.

            Ensuite...
            Le libre est une source de securité. Le fait de diffuser les sources t'oblige a ne pas te reposer sur des solutions bidons pour assurer la securité de tes applications.

            Je n'ai jamais dit le contraire. J'essaie juste de rester dans le sujet de la news qui incitent les gens a participer au projet RC5 de distributed.net

            Leur but est de montrer la puissance d'un calcul massivement distribué en participant à des concours de calcul. Pas de chercher des solutions pour effectuer des calculs sécurisés dans un environnement non securisé.

            Le cas de distributed ne peut pas etre pris comme example pour un debat sur la securité entre les systèmes ouvert/fermé. La première chose à faire pour sécuriser une solution est de bien identifier les participants (les machines misent en oeuvre) et d'etre sur qu'ils ne sont pas corrompus. Cette premiere etape n'est pas possible pour le projet distributed.net. Multiplier les solutions bidons de type "cacher les sources" est un pis-aller qui semble pour l'instant suffisant dans leur cas.

            Comment preserver la solution quand les clients ne sont pas identifiable ?

            Napster&consors peuvent bannir les gens qui cherchent à faire tomber le système en renommant des mp3 de chantal goyat en "ACDC - ballbreakers.mp3"

            Sur Freenet, le controle du contenu galleux devrait etre automatique puisque au fur et a mesure ou on se rend compte de l'inninteret d'un truc, il se preopage de moins en moins.

            Pour distributed.net, ces solutions ne sont pas possible car bien que les calculs soient distribués, le control reste central et ne peut vérifier l'intégrité de tout ce qu'il recoit. (sinon ils feraient les calculs eux-meme :D )

            • [^] # Re: allez !

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

              Et puis en passant... Tu semble reduire le debat libre/fermé a un seul aspect : la sécurité.

              Yen a plein d'autre...
              - rapidité de dev grace aux possibilités de re-utilisation sans contraintes de codes existant.
              - facilitation de l'interoperabilité, et donc solution plus perene.
              - etc, etc...

  • # Calculs utiles...

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

    Moi je préfère consacrer mes machines à la recherche des Aliens avec Seti@Home, c'est quand même plus utile :-)

    Je trouve que le but du challenge RC5-128 qui était de prouver qu'un cryptage 128 bits n'était pas assez fort car facilement craquable est quand même largement raté ! Ca fait plusieurs années que des centaines de milliers de machines y travaillent sans y arriver ! Ca semble prouver que 128 bits sont suffisants (pour l'instant), non ?


    Autant travailler à faciliter la rencontre du 3 ème type :-)

    Allez, pour les ceusses qui ne connaitraient pas déjà, voici l'adresse du site de ce projet, plus sérieux qu'il n'y parait :

    http://setiathome.ssl.berkeley.edu/(...)

    • [^] # Re: Calculs utiles...

      Posté par  . Évalué à 0.

      La vitesse des processeurs est multiplée par 2 tous les 1,8 ans (qlque chose comme ca non). Donc, il faut actuellement 4 ans pour le craquer ms dans 8 ans. Ms ds 1,8 ans 2 ans, ds 3,6ans en 1an, ds 5,4 en 6mois ds 7,2ans en 3mois et ainsi de suite ! Je crois que t'a compris que ton raisonnement ne tient pas ! On est un tres petit nbr à utiliser des clients. Il y a des organisations (on ne les citera pas) qui ont des moyen + importants que nous !
      De plus, il s'agit d'une attaque brute force ici, donc rien d'intelligent, avec des méthodes un brin plus sophistiquée on peut esperer des résultat + convaincant encore...

      • [^] # Re: Calculs utiles...

        Posté par  . Évalué à 1.

        >Donc, il faut actuellement 4 ans pour le craquer
        >ms dans 8 ans. Ms ds 1,8 ans 2 ans, ds 3,6ans en
        >1an, ds 5,4 en 6mois ds 7,2ans en 3mois et ainsi
        >de suite.

        C'est toi qui t'exprime mal, ou c'est moi qui n'ais rien compris ?

        • [^] # Re: Calculs utiles...

          Posté par  . Évalué à 0.

          Je tape vite sans me relire Troll ! Mais bon si tu as du temps à perdre tu peux corriger...

      • [^] # Re: Calculs utiles...

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

        J'ajouterais meme que pour le challange DES (le troisieme je crois), c'est un supercalculateur qu i a gagne la mise, en 22h, juste devant distributed.net et ses 100.000 machines.


        http://www.rsasecurity.com/news/pr/990119-1.html(...)
        http://www.eff.org/descracker.html(...)

        • [^] # Re: Calculs utiles...

          Posté par  . Évalué à 0.

          EFF utilisait hardware specialise pour le DES (DES Cracker "Deep Crack" custom microchip) ce qui explique qu'il ai cracke le code plus rapidement que 100.000 PCs (photos du chip http://www.eff.org/descracker.html(...)).

          A ma connaissance, personne ne s'est amuse a faire la meme chose avec RC5.

          • [^] # Re: Calculs utiles...

            Posté par  . Évalué à 0.

            A ta connaissance...

            Tout le problème est là... Un chip spécialisé pour ce genre de traitement ne coûte rien comparé au budget du NSA (non, je l'ai pas dit). Et le construire à des milliers d'exemplaires guèes plus.

            Malgré tout, dnet reste à mon avis le concours de celui qui fait pipi le plus loin (et oui, je me porte pas trop mal en terme de distance ;) )

            • [^] # Re: Calculs utiles...

              Posté par  . Évalué à 1.

              > Un chip spécialisé pour ce genre de traitement ne coûte rien comparé au budget du NSA

              Des chiffres ! Des chiffres ! :-)

    • [^] # Re: Calculs utiles...

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

      Mais c'est super-utile distributed.net : La premiere fois que j'ai entendu parler de linuxfr, c'etait en voyant leur stats au projet RC5.

      Par contre Seti c'est tres dangereux : Si on trouve d'autre forme de vie intelligente, y'aura toujours 2-3 personnes qui voudront rentrer en communication avec eux. Et alors ils sauront qu'on existe et ils vont venir nous laseriser pour pas qu'on prenne le control de l'univer a leur place.

      --
      Thomas, qui fremit a chaque fois qu'il voit un client Seti@home tourner.

    • [^] # Re: Calculs utiles...

      Posté par  . Évalué à 0.

      J'suis d'accord avec Serge.
      Je dirais même qu'il y en a qui doivent se marrer à la NSA et ailleurs.
      Amha, la NSA a les moyens de cracker plus d'une clef de 128 bits par jour, et ça doit même être largement plus rapide.

      • [^] # Re: Calculs utiles...

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

        C'est aussi pour ça que je préfère Sétiser.

        Le challenge RC5-128 (j'ai participé au RC5-64, au DES et au début du RC5-128) n'ont prouvé qu'une chose : l'attaque par la force brute du RC5-128 est trop longue par les moyens traditionels pour présenter un problème de sécurité.

        Je suis également persuadé que la NSA a autre chose que "des moyens traditionel".

        Je préfère donc faire travailler mes machines sur des problèmes moins terre à terre :-)

        Pour Seti, j'annonce : 15467 blocs postés, 19 ème au classement Français et 871 ème mondial (sur
        2 682 000 participants :-)

      • [^] # Re: Calculs utiles...

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

        C'est aussi pour ça que je préfère Sétiser.

        Le challenge RC5-128 (j'ai participé au RC5-64, au DES et au début du RC5-128) n'ont prouvé qu'une chose : l'attaque par la force brute du RC5-128 est trop longue par les moyens traditionels pour présenter un problème de sécurité.

        Je suis également persuadé que la NSA a autre chose que "des moyens traditionel".

        Je préfère donc faire travailler mes machines sur des problèmes moins terre à terre :-)

        Pour Seti, j'annonce : 15467 blocs postés, 19 ème au classement Français et 871 ème mondial (sur
        2 682 000 participants :-)

    • [^] # Re: Calculs utiles...

      Posté par  . Évalué à 0.

      mais t'es fouuuuuuuuuuuuuuu, t'a pas vu Independance Day? (je peux pas te le reprocher va...) ils vontnous faire koi les aliens quand on aura établi le contact a ton avis? NOUS DETRUIRE! (j'ai pas reussi a regarder tout le film, mais j'ai vu que ca pétait bien, surtout contre nous)
      alors hein, moi, Seti@Home, que dalle...

  • # stats RC5 et graphs

    Posté par  . Évalué à 0.

    Creez vos graphs RC5 perso avec le script Perl/gnuplot disponible a cette URL:

    http://dominique.pelle.free.fr/rc5_stats.html(...)

  • # icone RC5 linuxfr

    Posté par  . Évalué à 0.

    J'ai ete voir les stats de l'equipe linuxfr (http://stats.distributed.net/rc5-64/tmsummary.php3?team=5053(...)). L'icone RC5 linuxfr a disparue. Dans le source de la page, je vois <IMG src="http://linuxfr.org/images/rc5.jpg">(...) mais le fichier jpg n'existe pas.

  • # Interet de rejoindre l'equipe?

    Posté par  . Évalué à 0.

    ça sert à quoi de faire partie d'unbe equipe?

  • # C fait

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

    Bon ca y est j'ai rejoint l'equipe.

    • [^] # Re: C fait

      Posté par  . Évalué à 0.

      direct 28eme, pas mal!

  • # Tout le monde s'en fout mais...

    Posté par  . Évalué à 1.

    Je suis 25ème sur plus de 400 dans l'équipe, et juste derrière Nat Makarevitch :-)

    • [^] # Re: Tout le monde s'en fout mais... en fait c'est parlant

      Posté par  . Évalué à 0.

      casser les clés, je sais pas si ça sert à la science, mais en tout cas ça à jouer à qui à la plus grosse..


      aussi, pourquoi ces angoisses de tricheries s'il n'y avait pas d'interet pécunier ? Les gens sont donc convaincu de l'utilité de distributed.net parce qu'il y'a du fric à la clé ?! De bien profondes et sincères convictions !!

      Bon, je veux pas accuser quelqu'un ici, je ne pense pas que des gens ici espèrent se faire des thunes par ce moyen, mais qui cherche à se faire des thunes sur distributed.net ? Personne, sinon des gens qui sont des possibles tricheurs.

      Bien entendu, dans le cas d'un travail, la rémunération fait partie des motivations : distributed.net n'est pas un travail (c'est censé ne rien couter !), il n'y a donc aucune raison d'etre rémunéré pour celà, aucun effort n'est fourni.

      • [^] # Re: Tout le monde s'en fout mais... en fait c'est parlant

        Posté par  . Évalué à 1.

        L'argent qui est à la clé ne provient pas directement de Distributed.net
        C'est la société qui propose le concours qui offre cet argent. Distributed en redistribue une partie au gagnant (s'il utilise son client bien sûr !).

        >>distributed.net n'est pas un travail
        Oui, tu as raison, c'est un concours.
        Et comme dans tous les concours, y'a quelque chose à gagner.
        Certains le font peut être pour l'argent.
        D'autres (et c'est mon cas) pour démontrer la puissance du calcul distribué.

        Chacun a ses motivations pour participer...

        Rug'

        • [^] # Re: Tout le monde s'en fout mais... en fait c'est parlant

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

          Sauf qu'effectivement le plus gros problème du calcul distribué (à mon avis), c'est la confiance que tu peux avoir dans le résultat. Or si tu instaure une relation marchande, comme c'est le cas ici, tu perds de suite cette confiance...
          J'imagine (je sais, c'est arbitraire) que la plupart des gens qui participent l'auraient fait également si cet intéressement n'était pas à l'ordre du jour. Et les problèmes de triches auraient quasiment disparu avec.

  • # RC5 ou CSC

    Posté par  . Évalué à 1.

    Le problème de la baisse de régime peut venir du fait que les nouveaux clients par défaut travaillent sur le challenge CSC...

  • # Inscription ?

    Posté par  . Évalué à 0.

    J'ai voulu rejoindre l'équipe LinuxFR mais il me demande un login/mot de passe or je n'ai pas vu de formulaires d'inscription sur leur site... On fait comment ?

    • [^] # Re: Inscription ?

      Posté par  . Évalué à 0.

      Tu dois configurer le client avec ton adresse mail (option 1 - 1).

      Ensuite, dans qq jours, distributed t enverras ton login et ton mot de passe pour enfin rejoindre notre equipe :))

Suivre le flux des commentaires

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