Vérifiez votre droit ! Donc tais-toi!!!

Retro-ingénierie != spec ouvertes

• [^]Re: Retro-ingénierie != spec ouvertes

  Posté par gege (page perso, ) le 22/10/2001 à 09:37. (lien). Évalué à 4.

  Il ne faut pas confondre filer une clé de décryptage et documenter un protocole.
  
  La documentation de protocole n'interfère en rien avec une confidentialité : PGP est un standard ouvert offrant une bonne sécurité !

  • [^]Re: Retro-ingénierie != spec ouvertes

    Posté par Annah C. Hue (page perso, ) le 22/10/2001 à 09:53. (lien). Évalué à 9.

    Tant que les entreprises croiront que garder le secret de leurs protocoles propriétaires leur assure un quelconque avantage, elles ne vont sûremement pas te donner les spécifications.C'est le même problème que pour les trous de sécurité, certains croient que le fait de pas les divulguer augmentera la sécurité de leurs produits.
    
    Et PGP et DeCCS n'on pas grand chose à voir : autant il est possible d'assurer la confidentialité d'une communication entre deux parties, autant crypter une émission diffusée en broadcast (comme Canal sat, ou un DVD) à destination d'un nombre important de clients relève de l'utopie Pour cette raison la non divulgation du protocole de cryptage met un frein (léger) au piratage. Ce n'est pas demain que C+ te filera les spec completes de son décodeur.

    • [^]Re: Retro-ingénierie != spec ouvertes

      Posté par jcs (page perso, ) le 22/10/2001 à 13:47. (lien). Évalué à 2.

      Ce n'est pas demain que C+ te filera les spec completes de son décodeur
      Mais alors, il n'est pas brevete. En effet, pour deposer un brevet il faut fournir les specs completes de ton produit. Une personne n'il connaissant rien doit pouvoir en fabriquer un.
      
      Comme tout systeme de cryptage, sa force reside dans la clef et non le systeme. C'etait d'ailleurs la faiblesse d'Enigma le systeme de cryptage allemand pendant la seconde guerre mondiale.
      (cf http://www.enseignement.polytechnique.fr/profs/informatique/Jean-Ja(...) )
      
      Le procede Nagravision servant a crypter les emissions de C+ est connu de tous.
      
      Pour ceux interesse par les problemes de TV a peage un bon livre :
      European Scrambling Systems de John McCormac.

      --
      Hurd will be out in a year (or two, or next month, who knows)
      -- Linus Benedict Torvalds, 1991

    • [^]Re: Retro-ingénierie != spec ouvertes

      Posté par Eric Leblond (page perso, ) le 22/10/2001 à 15:05. (lien). Évalué à 2.

      Le fait de donner les spécifications n'est pas forcément suffisant. J'en prends pour exemple le protocole IPMI (Intelligent Platform Management Interface) développé par Intel qui permet de récupérer les informations des senseurs des cartes mères serveurs :
      Des Specs complètes (plus de 350 pages) ont été publiées et sont accessibles quasi-librement depuis le web.
      Des projets libres ont donc vus le jour (notamment à l'initiative de VA Linux). Et tous s'est bien passé jusqu'à il y a 4 mois où toutes les nouvelles machines sorties des usines ne réagissait plus correctement au soft développés.
      La raison : il y avait 10 Lignes dans les 350 pages qui laissait au constructeur la lattitude de faire ce qu'il voulait à un certain endroit (structure de données libres). Intel s'y est engouffré une fois son protocole fortement implanté et tous les projets libres sont devenus inutilisables.

      • [+] [^]Re: Retro-ingénierie != spec ouvertes

        Posté par Anonyme () le 22/10/2001 à 15:12. (lien). Évalué à -1.

        10 lignes obscures == non documentation ! Ceci démontre donc le contraire de ce que tu voulais expliquer...

• [^]Re: Retro-ingénierie != spec ouvertes

  Posté par PLuG () le 22/10/2001 à 09:42. (lien). Évalué à 1.

  Pourtant cette clef de decryptage il vont bien la filer (vendre) aux fabricants d'appareils domestiques, et autres editeurs de logiciels.
  
  Ce qui est fondamentalement mauvais dans la protection des médias (cd audio, dvd, k7...) c'est que la fonction meme de ces média est de livrer les données à l'utilisateur final. crypter ces données c'est aussi donner les moyens de les décrypter pour les utiliser, ce qui ramène obligatoirement à la case départ: l'utilisateur à accès aux données qu'il vient d'acheter, et le cryptage n'a servi à rien [sinon vendre des clefs :-))].
  
  Microsoft n'est pas obligé de filer les specs de ses modifications du protocole kerberos ( ? ,c'est une question !), si il ne veut pas que les autres machines puissent communiquer avec les siennes (par contre, on pourrait interdire à MS d'utiliser le terme kerberos dans la mesure ou il s ne sont pas 100% clients kerberos), par contre la RIAA ne vends pas les apareils de lecture, il faut donc bien qu'elle vende des clefs de decryptage !!

  • [^]Re: Retro-ingénierie != spec ouvertes

    Posté par nodens (page perso, ) le 22/10/2001 à 10:22. (lien). Évalué à 3.

    Microsoft n'est pas obligé de filer les specs de ses modifications du protocole kerberos ( ? ,c'est une question !), si il ne veut pas que les autres machines puissent communiquer avec les siennes
    
    Il n'est pas obligé, mais alors il ne peut t'empêcher de faire du reverse engineering pour faire communiquer tes logiciels avec les siens, ni de rendre tes résultats publics (quoique je soit pas sûr à 100% là-dessus, qqn pour confirmer/infirmer ?), ni de distribuer une application/bibliothèque/autre pour permettre aux gens de communiquer de la même manière avec les logiciels de MS.

    --
    Clément Hermann (nodens)
    - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
    Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
    GPG : pgp.mit.edu - 0xEBD1399D

    • [^]Re: Retro-ingénierie != spec ouvertes

      Posté par Anonyme () le 22/10/2001 à 11:13. (lien). Évalué à 6.

      en fait MS utilise pour on ne sais quoi un octet qui était marqué "pour utilisation future" dans le protocole kerberos. Bien sûr ils n'ont pas documenté ni expliqué le besoin qui ne peut donc pas être ajouté dans le protocole kerberos officiel.
      Résultat: si le serveur kerberos est celui de MS, les clients kerberos habituels fonctionnent (sans cet octet) et les clients MS aussi (avec cet octet).
      si le serveur est une machine unix, les clients MS ne fonctionnent plus.
      
      L'équipe kerberos avait émis la possibilité d'utiliser cet octet pour autre chose histoire de rendre les protocoles completement incompatibles et couper l'herbe sous le pied de MS ... ils ne l'ont pas fait.
      
      Dans cette affaire, ce qui m'horripile le plus c'est que quand MS utilise un protocole ouvert et documenté ... il s'arrange pour s'octroyer le marché des serveurs quand même !!

      • [^]Re: Retro-ingénierie != spec ouvertes

        Posté par gwenn cumunel (page perso, ) le 22/10/2001 à 11:56. (lien). Évalué à 7.

        c'est justement dans ce cas précis que le reverse-ingeenering s'avère nécessaire.
        
        Cet exemple montre bien :
        1- l'intérêt d'avoir accès au source (de quelque manières que ce soit).
        2- comment krosoft s'y prend pour phagocyter un standard ouvert et tenter de le transformer en standard porpiétaire...
        
        Le reverse-engeenering permettra de découvrir que l'octet en question ne sert à rien si ce n'est à faire planter les clients MS quand il n'est pas là ! (bon là j'extrapole complétement :)))

      • [^]Re: Retro-ingénierie != spec ouvertes

        Posté par pasBill pasGates () le 22/10/2001 à 17:23. (lien). Évalué à 1.

        Quedalle, MS utilise le champ "Vendor defined", et vu le nom, je te laisse deviner a quoi sert ce champ: justement ce que MS a mis dedans, des trucs definis par le vendeur, dans ce cas MS.

        • [^]Re: Retro-ingénierie != spec ouvertes

          Posté par Anonyme () le 22/10/2001 à 20:13. (lien). Évalué à 0.

          Ca ne change rien au probleme. Si les clients MS ont besoin qu'il soit conforme à une spec non documentée de MS, c'est une propriétarisation de la norme.

          • [^]Re: Retro-ingénierie != spec ouvertes

            Posté par pasBill pasGates () le 22/10/2001 à 21:38. (lien). Évalué à 1.

            Ben vois-tu, le probleme est que MS devait stocker quelque part les ACL de Windows, qui ont pas vraiment la meme gueule que les permissions Unix, ils les ont mis la, car c'etait le meilleur endroit pour ca.
            
            Je vois pas vraiment ce qu'ils auraient pu faire d'autre, rien d'autre n'est prevu dans Kerberos pour cela.

            • [^]Re: Retro-ingénierie != spec ouvertes

              Posté par Anonyme () le 22/10/2001 à 22:57. (lien). Évalué à 0.

              Je vois pas vraiment ce qu'ils auraient pu faire d'autre, rien d'autre n'est prevu dans Kerberos pour cela.
              
              Kerberos ne concernait que les OS dignes de ce nom ?
              
              MS en a détourné l'utilisation, si tu ajoutes des choses à une norme tu la propriétarises, point. Si Windows n'est pas capable d'utiliser Kerberos en le respectant, c'est le probleme de Windows.

              • [^]Re: Retro-ingénierie != spec ouvertes

                Posté par pasBill pasGates () le 23/10/2001 à 01:05. (lien). Évalué à 1.

                Ah bon...
                
                Ben va voir comment les autres OS avec des ACL font, ils font la meme chose.
                
                Renseignes toi sur Kerberos avant de dire n'importe quoi...

    • [^]droit au reverse et publication

      Posté par B. franck () le 22/10/2001 à 12:46. (lien). Évalué à 4.

      ce droit tu l'as pour l'instant
      
      tant que les brevets ne seront pas passé
      en Europe.
      
      Après celà, ce sera comme aux us: procès en cascade, découragement, pressions, prison, amendes, etc.

• [^]mais bien sur que SI ! il faut abuser

  Posté par B. franck () le 22/10/2001 à 12:39. (lien). Évalué à 2.

  autant il ne faut pas abuser et demander les spécifications d'un protocole fermé (on va pas demander à la RIAA de nous filer la clé de décryptage)
  
  Et notre droit à la copie de sauvegarde
  qu'est-ce que tu en fais!?
  
  Aussi bien pour la PS2 que pour les dvd quasi illégalement zonés, tu as le droit de péter toutes les clefs que tu veux puisque c'est dans un but
  de copies (3) de "sauvegarde", légalement autorisées.
  
  Que dire du petit producteur qui sort son film (zoné 1) qui ne PEUT (sans rétribuer les distributeurs de la zone 2) nous montrer son oeuvre ?
  J'appelle ça un scandale, une sous-culture, big brother, la peste; le tout réuni.
  
  En instaurant cette clef, on nous a retiré ce droit à la copie.
  
  ps: la prochaine étape : les brevets pour protéger cette clef...

  • [^]Re: mais bien sur que SI ! il faut abuser

    Posté par Anonyme () le 22/10/2001 à 17:00. (lien). Évalué à 1.

    En fait, si j'ai tout bien compris ce que m'a explique mon prof de droit, le droit de copie de sauvegarde ne signifie pas que tu a le droit de faire tes propres copies de sauvegardes. Simplement, si l'editeur t'interdit la possibilite de les faire toi-meme, cela signifie qu'il s'engage implicitement a te fournir une nouvelle copie lorsque tu lui adresse une demande motivee (genre un support endommage...)
    
    En tout cas, les cours de droits informatique en ecole d'ingenieur, c'est une bonne chose : tu te rends compte a quel point les avocats peuvent te mettre dedant simplement en jouant sur les mots lorsqu'ils ont la loi contre eux.
    
    Et tu te rend compte egalement que dans certaines licences (genre M$ pour ne pas les cites), une bonne partie des clauses sont nullescar contrraire au droit francais. Ils le savent parfaitement mais ils les laissent pour faire peur aux 99,9% des utilisateurs qui ne sont pas au courantdes textes de loi OU qui ne comprennent pas leur implication en informatique

pour le modérateur: paradoxe

• [^]Re: pour le modérateur: paradoxe

  Posté par Annah C. Hue (page perso, ) le 22/10/2001 à 12:39. (lien). Évalué à 7.

  Un standard peut etre fermé. Exemple : certains protocoles utilisés par H323 (téléphonie sur IP) suivent les recommandations ITUT qui sont des documents payants, donc non ouverts.

• [^]Re: pour le modérateur: paradoxe

  Posté par Gaël (page perso, ) le 22/10/2001 à 12:39. (lien). Évalué à 0.

  Un peu trollesque, mais tellement vrai...
  
  Effectivement, un standard fermé, ça fait bizarre.

• [^]Re: pour le modérateur: paradoxe

  Posté par gle () le 22/10/2001 à 13:19. (lien). Évalué à 3.

  Etre un standard, celà signifie être l'implémentation de référence, la plus répendue, celle qui est incontournable. Ca ne veut pas dire que cette implémentation est documentée.
  
  Par exemple, le format .doc est le standard de fait en matière de fichiers issus de traîtement de textes, ce qui ne veut pas dire que l'ensemble des fonctionnalités soient documentées.
  
  Et même lorsque le standard est documenté, ça ne veut pas dire que la documentation est en libre accès. Par exemple, si tu veux un exemplaire du standard ISO des langages C ou SQL, il faudra payer (et c'est cher!).
  
  A contrario, les RFC sont des exmples de standards ouverts: en général un RFC décrit un standard, et il est librement consultable.

  • [+] [^]Re: pour le modérateur: paradoxe

    Posté par Anonyme () le 22/10/2001 à 15:47. (lien). Évalué à -1.

    Bah non, le standard *doit* etre ouvert. Les .doc, c'est pas standard.

    • [^]Re: pour le modérateur: paradoxe

      Posté par dcp (page perso, ) le 22/10/2001 à 15:59. (lien). Évalué à 2.

      Je pense que tu confonds norme et standard.
      Une norme spécifie un certains nombre de règles permettant à quiconque de l'implémenter (TCP/IP, HTML, XML...). Une norme à bien pour volonté de devenir un standard. Par contre, un standard n'est pas obligatoirement une norme. c'est un état de fait: mon produit ou mon format de fichier est extremement répandu et utilisé par la grande majorité des gens. La nuance n'est pas si mince...
      
      Denis

      • [^]Re: pour le modérateur: paradoxe

        Posté par Anonyme () le 22/10/2001 à 20:20. (lien). Évalué à 1.

        Il y a une différence entre norme et standard, mais ce n'est pas celle là.
        
        Une norme n'est pas forcément un standard dans le sens où n'importe qui peut s'amuser à en faire une, ouverte et tout, mais s'il est le seul à l'utiliser et que les autres ne savent pas où la trouver et qu'il n'existe pas de logiciel approprié pour l'utiliser, elle ne sert pas à grand chose. Dans ce cas ce n'est pas un standard.
        
        Un standard est lui lié à une norme. La norme associée doit etre suffisamment ouverte, répandue (spec connue, logiciels l'exploitant). Le .doc n'est pas standard parce qu'il n'est pas lisible partout, il manque des logiciels sur certaines plateformes et les specs ne sont pas toutes données rendant certains documents illisbles pour d'autres logiciels que Word. Le PDF par exemple, meme s'il est moins répandu, a les memes caractéristiques + des logiciels partout et une spec totalement ouverte. Lui, est standard.
        
        Donc je pense, pour ma part, que tu confonds standard et répandu. L'aspect "répandu" jouant néanmoins beaucoup sur le caractère standard.