Reprise du message précédent :

Eh bien si tu regardes l'article de loi encore une fois, tu vois qu'il n'est fait a aucun moment mention de la posession de l'original.
Il y a juste ecrit que la propriete intellectuelle ne peut pas etre une raison pour interdire la copie si l'usage de cette copie est prive. C'est tout ce qu'il y a ecrit.
Aucune reference a l'original, on dit juste que tu as le droit general de faire une copie.
 
Et pour le cas ou il y aurait le moindre doute (le legislateur aurait voulu preciser que ct seulement si tu avais l'original mais il a oublie), tu as dans le meme alinea la precision que pour les logiciels, tu n'as le droit de faire une copie que si tu as l'original. Ce qui s'il y avait le moindre doute, et il n'y en avait pas (quand on dit qqch en tte generalite, c'est general), ca montrerait bien que le cas de l'oeuvre d'art s'applique si tu n'as pas l'original aussi, sinon il n'y aurait pas eu besoin de preciser le contraire pour le logiciel.
 
Bref, limpide comme article.
Et d'ailleurs, c'est cet article qui t'autorise  a enregistrer la tele, alors que tu n'as pas l'original.

Je suis pas vraiment dans ce domaine-là mais enfin je comprend le problème: les données écrites 4 passages après sont bien plus rémanentes que celles recherchées et 5 fois encore plus etc ...
 
J'avais lu 11 ou 13 fois sur un site lu par des admins concernés par la sécurité mais enfin sinon voilà 1 lien vers un beau pavé, très intéressant mais pas tourné vers l'utilisateur lambda "que faire", c'est universitaire et complexe)
Il donne pas un nombre précis mais la manière selon le média de tout effacer (les 0 et 1 sur un DD ne sont pas stockés tels quels mais c'est le changement bit n à 0 et bit n+1 à 1 qui est stocké par exemple - le Delta entre 2 bits successifs plutôt que directement les bits)
 
Il évoque sinon plein de trucs intéressants: les services secrets donnent des consignes de sécurité assez lâches ("réécrivez n fois" ) car ils savent relire un truc réécrit n+3 fois et pour eux-même ils sont bien plus stricts (n+5 fois par exemple). Ca c'est compréhensible quand on est un service secret, ce genre d'intox
 
Sinon le lien (27) est assez dingue: sniffer le réseau spécifiquement pour les partages NFS avec changement à la volée    
son conseil: ne jamais écrire les clés de cryptage où que ce soit, les stocker en mémoire avec des logiciels qui savent gérer ça. Puis (là j'hallucine) effacer la Ram aux adresses utilisées et aux adresses physiquement voisines car comme tout composant électronique, la Ram "volatile" est pas si volatile que ça une fois éteinte ( ).
 
 
http://www.cs.auckland.ac.nz/~pgut [...] e_del.html

Je vais lire ca alors, mais deja, ca a l'air sympa rien que d'apres ton histoire d'effacage manuel de la ram.

Pour la Ram, des suites de 0 et de 1 suffisent contrairement aux DD d'après lui ...
Enfin je sais pas avec quel OS on peut faire tourner des préceptes pareils mais c'est    

 
   
 
sais tu qu'un juriste a rarement l'indulgence des juges    
 
DV

C clair, et c'est normal, mais bon, en meme temps, avec les noms, numeros de portable et planque de tous les membres d'Al Qaida qui traine sur mon pc, heureusement que c'est crypte...

 
       
 
 
 
DV

Bon en gros:
je prends un petit serveur sous Linux (vieux PIII avec 256Mo de RAM, pas de clavier ni d'écran) avec
un ou plusieurs gros disques. Je fait crée un fichier de xx Go crypté (en n fois 256 bits) que j'appelle "TestFile1".
Je boote, je rentre le mot de passe, je "monte" le fichier à la main (rien d'automatique surtout) pour rendre son contenu accessible. Prévoir un onduleur et éviter de rebooter trop souvent.
Pour faire bonne mesure, un petit script du genre
#!/bin/sh
echo "Testing drive write capability"
date
dd if=/dev/urandom of=/chemin/vers/TestFile1 bs=1024 count=$(( xx * 1024)
date
 
pour dire: j'ai voulu mesurer la vitesse d'écriture réelle de mon nouveau système de fichier ReiserFS 4 par rapport
à XFS dans le cas d'un gros fichier de xx Go.
 
EDIT: 1) bien entendu (comme tous les howto le rappellent) je n'écris pas mes données cryptées au tout début du fichier, mais un peu plus loin (offset aléatoire). Sinon, avec les headers du système de fichier on peut exhiber (force brute) une clef ...
2) autre solution parano: insérer du bruit aléatoire au milieu des données, compresser avant cryptage pour augmenter l'entropie, et séparer les méta-données des données (cf ReiserFS 4 et les plugins). Un peu comme
http://jsam.sourceforge.net, mais à-la-volée (pas encore implémenté à ma connaissance).
 
EDIT2: je tiens à préciser qu'il ne faut le faire que pour protéger des données légales que l'ont possède (chez moi, mon carnet d'adresse, mes documents personnels, rapports, photos, etc.). Par exemple pour se protéger des intrusions/virus/vers/spyware ...