malheureusement les clés OneTimePad sont trop gourmandes en taille pour crypter de gros FS (mais suffit largement à crypter des fichiers textes compressés comme un répertoire d'emails)
par contre il a été démontré mathématiquement que OTP est le seul algo qui peut résister à un adversaire qui possède une puissance de calcul illimité
OK j'ajoute que je viens de trouver un document du printemps 2003 d'Intel (membre de TCG) qui explique clairement que chaque composant (component) de l'ordinateur dont un hash est stocké dans le PCR peutr faire l'objet d'une demande d'identification lors de laquelle le hash stocké dans le PCR est communiqué et signé pour qu'il soit infalsifiable
ce document parle aussi de consituer une base de donnée de tous les hashs de tous les composants
la preuve est faite: la seule fonction originale de TCG est l'identification à distance par un tiers de chacun des composants (hard et soft) de mon ordinateur
Voilà pourquoi je refuse dès aujourd'hui d'utiliser des softs et du hardware compatibles TCG !
en fait je crois que tu n'as pas compris la notion de chain of trust:
TCG hashe le BIOS, qui hashe le premier boot loader (bootloader spécialement écrit pour TCG, c'est ça que tu n'as pas compris je pense) et qui hashe le programme suivant du boot et ainsi de suite jusqu'à l'OS, de façon à pouvoir prouver, hashes à l'appui, que l'OS booté est bien un Windows TCG
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.
Ca ne sert a rien de discuter avec une personne qui ne sait pas de quoi elle parle du tout
je te trouves bien prétentieux !
Je pense avoir de très bonnes connaissances en informatique (DEA avec mention très bien), mais en effet je n'ai certainement pas autant de connaissances que le grand universitaire Ross Anderson qui étudie depuis longtemps la crypto et le libre, et TCG depuis plusieurs années (TCG est le nom officiel de TCPA depuis + d'un an, il faudrait peut-être que tu remettes à jour certaines connaissances !).
voici la dernière version (aout 2003 !) de ses arguments sur TCG: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html(...)
Sois un peu logique: mais alors que fait TCG que ne peuvent faire des softs libres actuellement ?
pourquoi accepterais-je une puce co-conçue par MS (qui fait partie des fondateurs de TCPA) dans mon ordi si elle ne me sert à rien (il me semble logique que MS compte s'en servir eux ! sinon ils n'auraient pas fondé TCPA)
c'est carrément absurde, à écouter ton explication du hashage du boot (qui n'explique aps du tout pourquoi les specs de TCG olbligent à le hasher), on a l'impression que TCG ne sert à rien puisqu'il ne garantit même pas que l'OS n'a pas été modifié entre 2 utilisations d'une clé privée protégée par TCG !
même sans cela il faudrait être idiot pour accepter d'avoir une puce concue par MS (et d'autres) dans son ordinateur qui n'apporte rien de + pour l'utilisateur que ce que peuvent faire déjà des logiciels libres évolutifs !
Emuler uen puce via un logiciel est souvent long,
pour le problème qui nous intéresse (générations des checksums spécifiques à un OS précis) il s'agit surtout de respecter les specs TCG en matière de checksum, pas besoin d'émuler une puce hardware ni même toutes les specs TCG pour celà !
Par nature fiable n'est pas mathématique.
en l'occurence il est facilement démontrable par les math que l'OTP est incassable, quelle que soit la puissance de calcul de l'adversaire (donc même s'il possède un ordinateur quantique avec une puissance phénoménale)
http://www.wikipedia.org/wiki/One-time_pad(...)
je cite: One-time pads are provably secure, in that if all the conditions are met properly (i.e., the keys are chosen randomly, are at least as long as the message, and are never reused), then the ciphertext gives the attacking cryptanalyst no information about the message other than its length.
moi je te renvoie encore aux documents officiels TCPA: In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code.
Heureusement que tu n'es pas homme de loi, tu serais du genre à comdamner des personnes avant même leur procès.
c'est pas ce que tu fais avec moi là ? en fait c'est pire, tu me mets dans la bouche des mots que je n'ai jamais dit !
Si ca n'apporte vraiment qu'une protection inferieure a ce qu'il est deja possible de faire logiciellement alors pourquoi es-tu aussi remonte ?
justement, il y a anguille sous roche ! explique-moi, en dehors du stockage infalsifiable y compris par moi d'un hash de l'OS loader au moment du boot, ce qu'apporte TCG ?
comme l'a fait remarqué un autre lecteur, tous les avantages au niveau sécurité de cette technologie sont faisables et en mieux par des softs libres !
il n'y a qu'une chose qui est la spécificité de TCG cette identification de l'OS par une puce tierce que je ne peux pas falsifier (alors que je peux identifier l'OS au moment du boot avec tripwire et mon matos actuel !)
si ce n'est pas pour identifier l'OS par un tiers, explique moi à quoi sert TCG alors ?
Il fournit une clef publique basee sur le checksum dans une certaine mesure.
c'est carrément incompréhensible ce que tu dis là, et la clé privée associée à cette clé publique elle sort d'où ?
or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile.
ah bon ? et pourquoi ?
TCPA est totalement incapables de faire le checksum d'un ou plusieurs softs.
mesonge !
les specs TCPA prévoient que tout logiciel (que ce soit le BIOS ou un soft lancé par le bios) doit être hashé !
voici un extrait des documents TCPA que je cite plus bas dans une autre réponse:
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code.
lors du boot de l'OS 1, la puce ou le bios stocke un checksum de l'OS loader
l'OS1 peut alors demander à la puce TCG de générer des clés privées (non dévoilées) associés à des clés publiques (dévoilées) qui ne seront utilisables pour décrypter que si l'OS qui le demande avait lors du boot la même signature que l'OS 1
tout autre OS ne peut donc pas y accéder, ce qui est inquiétant pour les OS alternatifs !
Alors que aujourd'hui, avec des softs libres et sans matos TCG, il est tout à fait possible d'utiliser des algos de crypto mieux considérés + fiables que le RSA de TCG (AES ou des algos symmétriques car pour cet usage précis on a pas besoin de crypto assymétrique) et des clés de taille supérieure ( limitation de taille de l'ordre de 1024 bits dans TCG) pour interdire à quelqu'un de booter sur ta machine et d'accéder à tes données s'il n'a pas ta clé (cela lui interdit aussi d'accéder aux données s'il emporte ton disque dur)
extraits de documents maintenant retirés du site officiel TCPA (les anciennes adresses sont fournies, des copies existent, et de nombreux témoins les ont lu)
lire ma conclusion tout en bas
www.trustedcomputing.org/docs/14_industry_1.pdf
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.
---------------------------------------------
1.2.5 Initial Program Loader (IPL)
Start of informative comment:
This is the code that executes during the Post-Boot state. The purpose of this code is to load the
Post-Boot environment.
End of informative comment
page 9 du pdf PC
-------------------------
www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf
Entities to be Measured:
· Each IPL that is attempted and executed.
page 20 du pdf
---------------------------
2.1.2 Transferring Control
Prior to transferring control an executing entity MUST measure the entity to which it will transfer
control.
pdf PC
------------
page 24 PC
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code. The BIOS MUST not hash any data areas.
---------------------------------------------------
tout cela sert à stocker un checksum de l'OS loader qui pourra ensuite être signé par la la puce TCG et envoyé à un tiers pour qu'il soit sûr de l'OS qu'on utilise actuellement (j'ai deja donné l'algo exact utilisé tout à l'heure dans des réponses à cet article)
si les périphériques USB (aujourd'hui majoritaires) ne sont pas encore pris en compte par TCG, cela ne fait que simplifier la base de données des checksums des OS et matériels qui permettront d'identifier ta plateforme
De toutes façons les périphériques USB non encore pris en compte permettront uniquement de copier des fichiers audio/video...
Or ce qui m'inquiète, ce n'est pas la possibilité (qu'on aura toujours en analogique de toutes façons) de copier des musiques ou des vidéos, c'est surtout la possibilité d'identifier un OS pour interdire à des OS alternatifs d'accéder à certains contenus ou certains programmes (cf les serveurs d'identification de Office 2003)
On a une vraie menace pour notre liberté de continuer à utiliser des OS que l'on peut controler et modifier soi-même !
pour être + précis: tu peux avoir sans TCG, et uniquement si tu le désires, des données protégées qui seront accessibles à plusieurs OS, à condition que tu fournisses la passphrase (et/ou une clé sur USB/floppy/cdrom) à chacun de ces OS lors du boot
Alors que TCG prévoit que les données qu'ils protègent (par exemples des fichiers/progarmmes protégés par DRM ou par Office2003 security server) ne seront pas accessibles à des OS différents de celui qui a stocké ces données.
Ni d'ailleurs sur d'autres matériels si ton ordinateur tombe en panne et que tu veux lire les données de ton disque dir sur un autre PC.
Combiné à l'identification à distance de l'OS par TCG, on a une vraie menace pour notre liberté de continuer à utiliser des OS et des matériels que l'on peut controler et modifier !
déjà c'est bien, par rapport à nos longues discussions précédentes, que tu reconnaisses implicitement que la seule fonctionalité de TCG non faisable par des softs libres est l'identification à distance de mon OS et de mon matériel par un tiers qui ne fait pas forcément partie de mes amis...
il y a cependant 2 points qui me genent dans ton raisonment:
1. tu considères que la puce TCG ne peut pas fournir et signer "séparément" le checksum du bootLoader, celuis du bios, et les numéros d'identification TCG des modèles des matériels. pourquoi ? apparemment tu considères, sans raison apparente, que seul un checksum signé de l'ensemble de ces checksums est obtensible (ce qui est déjà très grave )
2. en admettant que tu as raison au 1., qu'est-ce qui empeche de faire un programme assez simple qui calcule tous les checksums possibles étant donné qu'il y aura toujours un nombre forcément non illimité d'OS TCG, bios TCG et matériels compatibles TCG ?
Il n'y a pas forcément besoin, contrairement à ce que tu suggère, d'avoir sous la main tous ces softs et matériels, seul les checksums qui leur sont caractéristiques sont suffisants pour ensuite calculer le checksum de l'ensemble de ces checksums !
J'ajoute que si une passphrase est trop petite à ton gout, tu peux en + utiliser d'énormes clés (bien plus grosses que celles de taille fixe qui sont dans la spec tcpa) stockées sur disquette/cdrom/cléUSB, et avec l'algo de cryptage de ton choix (plutot que celui qui est fixé une fois pour toutes dans les specs TCG, ce qui fait qu'il sera peut-être obsolète trop vite pour continuer à protéger des données ultra confidentielles)
non car il est possible de faire la meme chose (protéger l'accès à certains fichiers même si un cambrioleur a un accès physique au disque dur) en protégeant ces fichiers/dossiers/partitions par une passphrase qui est demandée lors du boot !
rien n'empeche de crypter /etc ou /etc/passwd de la sorte, voir même le disque ou la partition sur laquelle ils se trouvent !
Si j'ai bien tout compris, on forme un groupe avec des gens qu'on connaît et en qui on a confiance, ces même gens pouvant eux-même être membres d'autres groupes.
tu as presque tout bien compris: en + de tout ça, un mécanisme de forwarding anonyme permet à quelqu'un qui est membre de 2 binomes (car les groupes que tu décris sont en fait des binomes) de faire passer des documents d'un binome à l'autre sans révéler ni l'identité ni l'IP des autres memebres des 2 binomes.
Je veux en venir qu'avec un routage amélioré (Waste a bien-sûr encore des progrès à faire, comme Freenet d'ailleurs) Waste me semble + fiable (je ne communique directement qu'avec des gens de confiance) et + anonyme (seuls mes amis de confiance savent que j'utilise Waste, et ils ne savent pas avec quels autres amis de confiance je l'utilise)
tu n'es pas très constructif: si elle te gène rédige une nouvelle version de cette news et envoie là aux modérateurs
de +, si on sait lire entre lignes au lieu de jouer sur les mots, tout le monde peut comprendre le sens de cette news et les dangers encourus par nos libertés
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 1.
par contre il a été démontré mathématiquement que OTP est le seul algo qui peut résister à un adversaire qui possède une puissance de calcul illimité
[^] # PREUVE IRREFUTABLE VENANT DE INTEL
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
[^] # PREUVE IRREFUTABLE QUE TCG=identification à distance VENANT DE INTEL !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
https://linuxfr.org/comments/280780.html(...)
[^] # PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
ce document parle aussi de consituer une base de donnée de tous les hashs de tous les composants
la preuve est faite: la seule fonction originale de TCG est l'identification à distance par un tiers de chacun des composants (hard et soft) de mon ordinateur
Voilà pourquoi je refuse dès aujourd'hui d'utiliser des softs et du hardware compatibles TCG !
[^] # chain of trust TCG
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
TCG hashe le BIOS, qui hashe le premier boot loader (bootloader spécialement écrit pour TCG, c'est ça que tu n'as pas compris je pense) et qui hashe le programme suivant du boot et ainsi de suite jusqu'à l'OS, de façon à pouvoir prouver, hashes à l'appui, que l'OS booté est bien un Windows TCG
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
je te trouves bien prétentieux !
Je pense avoir de très bonnes connaissances en informatique (DEA avec mention très bien), mais en effet je n'ai certainement pas autant de connaissances que le grand universitaire Ross Anderson qui étudie depuis longtemps la crypto et le libre, et TCG depuis plusieurs années (TCG est le nom officiel de TCPA depuis + d'un an, il faudrait peut-être que tu remettes à jour certaines connaissances !).
voici la dernière version (aout 2003 !) de ses arguments sur TCG:
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html(...)
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
pourquoi accepterais-je une puce co-conçue par MS (qui fait partie des fondateurs de TCPA) dans mon ordi si elle ne me sert à rien (il me semble logique que MS compte s'en servir eux ! sinon ils n'auraient pas fondé TCPA)
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
même sans cela il faudrait être idiot pour accepter d'avoir une puce concue par MS (et d'autres) dans son ordinateur qui n'apporte rien de + pour l'utilisateur que ce que peuvent faire déjà des logiciels libres évolutifs !
Emuler uen puce via un logiciel est souvent long,
pour le problème qui nous intéresse (générations des checksums spécifiques à un OS précis) il s'agit surtout de respecter les specs TCG en matière de checksum, pas besoin d'émuler une puce hardware ni même toutes les specs TCG pour celà !
[^] # Re: il est conseillé de compresser avant
Posté par free2.org . En réponse au sondage La crypto c'est sympa pour chiffrer. Évalué à 3.
en l'occurence il est facilement démontrable par les math que l'OTP est incassable, quelle que soit la puissance de calcul de l'adversaire (donc même s'il possède un ordinateur quantique avec une puissance phénoménale)
http://www.wikipedia.org/wiki/One-time_pad(...)
je cite:
One-time pads are provably secure, in that if all the conditions are met properly (i.e., the keys are chosen randomly, are at least as long as the message, and are never reused), then the ciphertext gives the attacking cryptanalyst no information about the message other than its length.
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
c'est pas ce que tu fais avec moi là ? en fait c'est pire, tu me mets dans la bouche des mots que je n'ai jamais dit !
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
justement, il y a anguille sous roche ! explique-moi, en dehors du stockage infalsifiable y compris par moi d'un hash de l'OS loader au moment du boot, ce qu'apporte TCG ?
comme l'a fait remarqué un autre lecteur, tous les avantages au niveau sécurité de cette technologie sont faisables et en mieux par des softs libres !
il n'y a qu'une chose qui est la spécificité de TCG cette identification de l'OS par une puce tierce que je ne peux pas falsifier (alors que je peux identifier l'OS au moment du boot avec tripwire et mon matos actuel !)
si ce n'est pas pour identifier l'OS par un tiers, explique moi à quoi sert TCG alors ?
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
c'est carrément incompréhensible ce que tu dis là, et la clé privée associée à cette clé publique elle sort d'où ?
or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile.
ah bon ? et pourquoi ?
TCPA est totalement incapables de faire le checksum d'un ou plusieurs softs.
mesonge !
les specs TCPA prévoient que tout logiciel (que ce soit le BIOS ou un soft lancé par le bios) doit être hashé !
voici un extrait des documents TCPA que je cite plus bas dans une autre réponse:
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code.
[^] # limitations de TCG par rapport aux softs libres
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
l'OS1 peut alors demander à la puce TCG de générer des clés privées (non dévoilées) associés à des clés publiques (dévoilées) qui ne seront utilisables pour décrypter que si l'OS qui le demande avait lors du boot la même signature que l'OS 1
tout autre OS ne peut donc pas y accéder, ce qui est inquiétant pour les OS alternatifs !
Alors que aujourd'hui, avec des softs libres et sans matos TCG, il est tout à fait possible d'utiliser des algos de crypto mieux considérés + fiables que le RSA de TCG (AES ou des algos symmétriques car pour cet usage précis on a pas besoin de crypto assymétrique) et des clés de taille supérieure ( limitation de taille de l'ordre de 1024 bits dans TCG) pour interdire à quelqu'un de booter sur ta machine et d'accéder à tes données s'il n'a pas ta clé (cela lui interdit aussi d'accéder aux données s'il emporte ton disque dur)
[^] # identification de l'OS : les preuves
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
lire ma conclusion tout en bas
www.trustedcomputing.org/docs/14_industry_1.pdf
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.
---------------------------------------------
1.2.5 Initial Program Loader (IPL)
Start of informative comment:
This is the code that executes during the Post-Boot state. The purpose of this code is to load the
Post-Boot environment.
End of informative comment
page 9 du pdf PC
-------------------------
www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf
Entities to be Measured:
· Each IPL that is attempted and executed.
page 20 du pdf
---------------------------
2.1.2 Transferring Control
Prior to transferring control an executing entity MUST measure the entity to which it will transfer
control.
pdf PC
------------
page 24 PC
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code. The BIOS MUST not hash any data areas.
---------------------------------------------------
tout cela sert à stocker un checksum de l'OS loader qui pourra ensuite être signé par la la puce TCG et envoyé à un tiers pour qu'il soit sûr de l'OS qu'on utilise actuellement (j'ai deja donné l'algo exact utilisé tout à l'heure dans des réponses à cet article)
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
De toutes façons les périphériques USB non encore pris en compte permettront uniquement de copier des fichiers audio/video...
Or ce qui m'inquiète, ce n'est pas la possibilité (qu'on aura toujours en analogique de toutes façons) de copier des musiques ou des vidéos, c'est surtout la possibilité d'identifier un OS pour interdire à des OS alternatifs d'accéder à certains contenus ou certains programmes (cf les serveurs d'identification de Office 2003)
On a une vraie menace pour notre liberté de continuer à utiliser des OS que l'on peut controler et modifier soi-même !
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
Alors que TCG prévoit que les données qu'ils protègent (par exemples des fichiers/progarmmes protégés par DRM ou par Office2003 security server) ne seront pas accessibles à des OS différents de celui qui a stocké ces données.
Ni d'ailleurs sur d'autres matériels si ton ordinateur tombe en panne et que tu veux lire les données de ton disque dir sur un autre PC.
Combiné à l'identification à distance de l'OS par TCG, on a une vraie menace pour notre liberté de continuer à utiliser des OS et des matériels que l'on peut controler et modifier !
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.
il y a cependant 2 points qui me genent dans ton raisonment:
1. tu considères que la puce TCG ne peut pas fournir et signer "séparément" le checksum du bootLoader, celuis du bios, et les numéros d'identification TCG des modèles des matériels. pourquoi ? apparemment tu considères, sans raison apparente, que seul un checksum signé de l'ensemble de ces checksums est obtensible (ce qui est déjà très grave )
2. en admettant que tu as raison au 1., qu'est-ce qui empeche de faire un programme assez simple qui calcule tous les checksums possibles étant donné qu'il y aura toujours un nombre forcément non illimité d'OS TCG, bios TCG et matériels compatibles TCG ?
Il n'y a pas forcément besoin, contrairement à ce que tu suggère, d'avoir sous la main tous ces softs et matériels, seul les checksums qui leur sont caractéristiques sont suffisants pour ensuite calculer le checksum de l'ensemble de ces checksums !
[^] # meilleure sécurité avec softs de cryptage libres évolutifs qu'avec hardware et specs fixés une fois pour toutes
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
rien n'empeche de crypter /etc ou /etc/passwd de la sorte, voir même le disque ou la partition sur laquelle ils se trouvent !
[^] # Re: noeuds publiques et liste des adresses IP publiques
Posté par free2.org . En réponse à la dépêche Faiblesse des protocoles P2P. Évalué à 1.
tu as presque tout bien compris: en + de tout ça, un mécanisme de forwarding anonyme permet à quelqu'un qui est membre de 2 binomes (car les groupes que tu décris sont en fait des binomes) de faire passer des documents d'un binome à l'autre sans révéler ni l'identité ni l'IP des autres memebres des 2 binomes.
Je veux en venir qu'avec un routage amélioré (Waste a bien-sûr encore des progrès à faire, comme Freenet d'ailleurs) Waste me semble + fiable (je ne communique directement qu'avec des gens de confiance) et + anonyme (seuls mes amis de confiance savent que j'utilise Waste, et ils ne savent pas avec quels autres amis de confiance je l'utilise)
[^] # faq TCPA/Palladium v 1.1 de aout 2003
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
voici le document original v 1.1 en anglais de Ross Anderson et mis à jour en aout 2003 ( notamment pour TCG)
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html(...)
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.
de +, si on sait lire entre lignes au lieu de jouer sur les mots, tout le monde peut comprendre le sens de cette news et les dangers encourus par nos libertés
[^] # EUCD
Posté par free2.org . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 1.