Forum général.cherche-logiciel améliorer l'entropie pour chiffrement

Posté par ElectronLibre le 11 juillet 2010 à 13:03.

Étiquettes : aucune

juil.

2010

Bonjour à tous,

Je suis en train de changer mes deux DD externes. Passage au 2*1 To.

Voici les étapes que je fais :

dd obs=10M count=1100G if=/dev/random of=/dev/sda

Puis formatage avec sous-couche de chiffrement, via l'utilisateur GNOME

En parallèle de l'exécution de la commade 'dd', je fais, de temps à autres, des :

cat /boot/vm*

cat /boot/vm* > /dev/dsp

find /

Mais c'est pas forcément le top, car ça fait mouliner les disques.
J'ai vu 'reseed', qui utilise un site web qui récupère le bruit issu de l'atmosphère et qui est donc un True Random Number Generator (voir http://www.random.org/).

Je me pose deux questions :

1/ Comment améliorer l'entropie sans se casser la tête et faire mouliner le système comme un fou pendant les longues heures d'exécution de la commande 'dd' ? 'reseed' est-il fiable ? Car si ce sont des pirates qui, en connaissant l'une des sources qui génèrent les graines, peuvent craquer plus facilement les clefs, ce n'est pas le top. Je suppose que /dev/random et /dev/urandom utilisent aussi /dev/dsp ? Aquel cas, est-ce que brancher un micro et faire recracher ce signal dans les HP peut aider à améliorer l'entropie ?

2/ Ensuite, deuxième question, quel est le paramètre optimal 'obs', de la commande 'dd' ?
Car je suppose que - prenons deux cas extrêmes -, si on prend 'obs=1ko' ou 'obs=1Go', ça ne sera pas très performant...

Merci !

# Visualitation de la qualité de l'entropie

Posté par ElectronLibre le 11 juillet 2010 à 13:27. Évalué à 4.

Hey,

La commande ci-dessous permet de voir la qualité de l'entropie instantanée :

watch -n 1 sysctl kernel.random.entropy_avail

Je viens de l'utiliser, tout d'abord sans rien faire, puis en faisant un find / et aussi cat /boot/vm* > /dev/dsp. Mais je ne vois aucune différence...

+
- [^] # Re: Visualitation de la qualité de l'entropie
  
  Posté par ElectronLibre le 12 juillet 2010 à 13:15. Évalué à 2.
  
  J'ai trouvé des moyens d'améliorer grandement l'entropie :
  
  https://bmearns.net/wwk/view//dev/random
  
  Simple, élégant, performant, robuste, fiable. Parfait !
  
  +
# frandom

Posté par solsTiCe (site web personnel) le 11 juillet 2010 à 23:44. Évalué à 4.

houla, il te faut combien de temps pour faire 2 To ? 4 jours ? déjà /dev/urandom devrait aller plus vite ?

j'utiliserais frandom même si c'est peut-être pas du random de haute qualité, ils annoncent sur leur site que c'est quand même pas mal, en plus d'aller vite (f = fast) !

/dev/frandom est un /dev/urandom plus rapide sans trop sacrifié à la qualité

http://www.billauer.co.il/frandom.html
- [^] # Re: frandom
  
  Posté par Octabrain le 13 juillet 2010 à 02:44. Évalué à 1.
  
  Le site recommande de ne pas utiliser ça comme aléatoire cryptographique.
# DSP ?

Posté par chimrod (site web personnel) le 12 juillet 2010 à 09:49. Évalué à 2.

Pourquoi /dev/dsp ? Je crois qu'il s'agit du driver audio géré par OSS, mais cela n'a rien à voir avec l'entropie du système.

En faisant un man random je ne vois non plus aucune référence à ce périphérique…

Lors d'une lecture, /dev/urandom renverra autant d'octets qu'on en demande. Toutefois, s'il n'y a plus assez de bits disponibles dans le réservoir d'entropie, les valeurs renvoyées pourraient être théoriquement vulnérables à une cryptanalyse basée sur l'algorithme employé par le pilote. Il n'existe pas de documentation sur ce type d'attaque dans la littérature publique actuelle, mais cela n'élimine pas le risque théorique. Si ce risque est important pour votre application, utilisez plutôt /dev/random à la place.
# données écrasées = données effacées

Posté par Old Geek le 12 juillet 2010 à 11:24. Évalué à 2.

Quelqu'un aurait-il un article m'expliquant en quoi c'est plus
sécurisé que de faire un "dd if=/dev/zero of=/dev/sda" ?,

J'ai toujours pensé à un hoax, le fait que les données soient
lisibles après Xx écritures ...,

Qui serait capable de récupérer les données "mémoires" ?,
à part avec un microscope ou je ne sais quoi et bit par bit ?,
en comptant un bit sur deux de faux !!!,

Merci pour cet éclairage ...

Nicolas
- [^] # Re: données écrasées = données effacées
  
  Posté par TheBreton le 12 juillet 2010 à 12:10. Évalué à 4.
  
  Non c'est une réalité, quand on positionne un bit sur une surface magnetique il prend une orientation. Quand on le positionne à l'autre valeur il prend une autre position qui n'est pas tout a fait celle d'origine.
  On a ici un phénomene d'hystérésis, la tete de lecture lit un niveau analogique du champ et en déduis si grosso-modo c'est un '1' ou un '0'.
  Après une remise à '0' de tout le disque on peut récupérer 100% de son ancienne valeur (en sortant les disques magnétique et en changeant les seuils de la tête de lecture).
  Nota: Pour un client dans l'armé la régle est d'écrire 5 fois des valeurs aléatoires sur le disque avant de l'envoyer en broyage.
  - [^] # Re: données écrasées = données effacées
    
    Posté par Kerro le 12 juillet 2010 à 16:24. Évalué à 2.
    
    Comme l'indique Nicolas, ça reste encore à prouver. Les dernières tentatives publiées dans ce domaine ont montré qu'on ne tire rien de rien, à part quelques ridicules suites de bits ici et là _et_ manuellement.
    
    Alors bien sûr, la CIA, les chinois (du FBI ou pas), les martiens...
    - [^] # Re: données écrasées = données effacées
      
      Posté par barmic le 12 juillet 2010 à 17:48. Évalué à 3.
      
      Outre tout cela tu peut avoir besoin de remplir ton disque avec de l'aléatoire quand tu veut crypter ton disque afin qu'un attaquant ne puisse pas connaître la taille et la localisation des données.
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: données écrasées = données effacées
        
        Posté par Kerro le 12 juillet 2010 à 20:53. Évalué à 3.
        
        C'est de mon point de vue le meilleur argument: plausible deniability (on traduit comment ? Excuse plausible ? Déni plausible ? Dénégation acceptable ?).
        Par exemple j'ai mes données vraiment secrètes (photos de mon chien à poil) que j'ai dans un volume caché à la fin d'une partition. Et j'ai mes données pseudo-secrètes (photos de mon canari à plume) que j'ai dans un volume au début de la partition.
        
        Si on me torture pour avouer, je donne le code pour le canari.
        Si l'attaquant n'est pas trop con, il va se demander à quoi servent les gigas non exploités en fin de partition. Re-torture. Pas bon.
        
        La méthode depuis pas mal de temps est que le "faux" volume prenne toute la place. Si on écrit dedans, ça risque d'écraser le vrai volume, mais cela "prouve" qu'on n'a rien à cacher.
        
        La contre-attaque est de se rendre compte que le volume chiffré n'utilise qu'une faible partie du total, que les données sont exclusivement située en début de volume, et que les dates d'écriture sont anciennes.
        Pour contrer cela il faudrait un mécanisme de cartographie des secteurs afin de pouvoir ouvrir les deux volumes en même temps, et d'écrire dans le volume pseudo-secret régulièrement.
        Il me semble qu'un très célèbre logiciel le fait. Je ne l'ai jamais utilisé.
  - [^] # Re: données écrasées = données effacées
    
    Posté par benoar le 12 juillet 2010 à 18:48. Évalué à 4.
    
    La sécurité c'est toujours une histoire de compromis : je pense qu'une personne « normale » peut se dire qu'un simple passage à zéro suffit vu la difficulté de l'attaque que tu décris (franchement, à part l'armée, je ne vois pas qui d'autre irait jusque là ; je pense que même pour les pédophiles ils ne vont pas aussi loin).
# Nicky Larsen

Posté par Axioplase ıɥs∀ (site web personnel) le 12 juillet 2010 à 12:17. Évalué à 3.

>> Aquel cas, est-ce que brancher un micro et faire recracher ce signal dans les HP peut aider à améliorer l'entropie ?

Ça va surtout générer un beau larsen « facile » à regénérer, ça, non ?
- [^] # Re: Nicky Larsen
  
  Posté par ElectronLibre le 12 juillet 2010 à 13:13. Évalué à 1.
  
  Hi,
  
  Evidemment, en mettant le son au minimum et le micro pas trop près.
# Pourquoi /dev/urandom ?

Posté par khivapia le 12 juillet 2010 à 16:47. Évalué à 3.

qui est un générateur d'aléa "vrai" (fait pour être imprédictible, avec ajout d'entropie régulièrement etc.) plutôt que la sortie d'un chiffrement à flot initialisé avec une bonne clef ?

L'intérêt est que c'est aussi sûr qu'un générateur d'aléa vrai si la clef est proprement détruite, et surtout que la sortie est *beaucoup* plus rapide.
- [^] # Re: Pourquoi /dev/urandom ?
  
  Posté par X345 le 12 juillet 2010 à 20:33. Évalué à 1.
  
  C'est justement ce que fait frandom (Il me semble qu'il utilise RC4), et effectivement il est plus rapide.
  
  Après, quand à déterminer si c'est aussi sur ou non, je n'ai pas les compétences mathématiques pour le faire mais je pense qu'on peut dire que c'est raisonnablement sécurisé.
- [^] # Re: Pourquoi /dev/urandom ?
  
  Posté par Octabrain le 13 juillet 2010 à 02:46. Évalué à 1.
  
  Je ne suis pas sûr d'avoir bien compris, tu crées une clef depuis une source "vraie", et tu chiffres quelque chose avec cette clef, et le résultat est aléatoire ? Mais que chiffres-tu ?
  - [^] # Re: Pourquoi /dev/urandom ?
    
    Posté par khivapia le 13 juillet 2010 à 18:05. Évalué à 3.
    
    Le chiffrement à flot sort une suite de bits dite suite chiffrante. Elle est supposée connue dans toutes les attaques cryptographiques, c'est-à-dire que si le chiffrement à flot est sûr, tu chiffres tout simplement des zéros avec, le résultat est un aléa imprévisible si on n'a pas la clef.

Suivre le flux des commentaires

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