Le fil des geeks informatiques

[poney]

Avec windaube ?

[Malky]

Vérifie dans le bios si tu as le boot activé sur l'usb, les lecteurs de SD sont souvent techniquement des adaptateurs SD->USB intégrés

[Eriul]

C'est un Ubuntu dessus. Je vais regarder dans le BIOS.

[poney]

Oui, tu dois dire à ton BIOS de lancer en priorité ta carte SD.

 

 

[Yozz]

Windows aussi, OS X je suis pas sûr par contre

M'étonnerait pour OS X.

[Theor]

A mon tour d'avoir une question. J'ai un NAS x86 (Linux custom) qui habrite des backups et des données volumineuses, et auquel j'accède soit par SSH (déplacement), soit en lecteur virtuel (local).

 

Je souhaite crypter le volume data, et de la façon dont je le perçois, deux solutions s'offrent à moi :

- un fichier TrueCrypt servant de conteneur pour un volume virtuel, à monter manuellement au (re)démarrage du NAS. Possibilité de crypter avec Serpent ou Twofish.

- encFS sur le partage CIFS

 

Naturellement, la deuxième solution est infiniment plus pratique et "dependable", mais j'ai quelques doutes sur sa sécurité. Avez-vous de l’expérience avec encFS et à votre avis est-ce que je peux lui faire confiance ? Ca m'arrangerait de ne pas devoir passer par TrueCrypt.

[Malky]

M'étonnerait pour OS X.

 

Après vérif rapide, de DMG d'installation de Lion peut démarrer une version bootable depuis une carte SD. Jamais testé perso cela dit.

[Malky]

A mon tour d'avoir une question. J'ai un NAS x86 (Linux custom) qui habrite des backups et des données volumineuses, et auquel j'accède soit par SSH (déplacement), soit en lecteur virtuel (local).

 

Je souhaite crypter le volume data, et de la façon dont je le perçois, deux solutions s'offrent à moi :

- un fichier TrueCrypt servant de conteneur pour un volume virtuel, à monter manuellement au (re)démarrage du NAS. Possibilité de crypter avec Serpent ou Twofish.

- encFS sur le partage CIFS

 

Naturellement, la deuxième solution est infiniment plus pratique et "dependable", mais j'ai quelques doutes sur sa sécurité. Avez-vous de l’expérience avec encFS et à votre avis est-ce que je peux lui faire confiance ? Ca m'arrangerait de ne pas devoir passer par TrueCrypt.

 

EncFS peut utiliser AES, en 256bits ça fait quand même une bonne protection, par contre il encode les fichiers séparément donc certaines choses sont visibles sans décrypter (taille approximative, permissions, date de dernier accès etc)

[Eriul]

Ok, le boot USB était désactivé.

Merci liborg !

[Noob]

C'est souvent comme ça avec les machines achetées complètes.

[Eriul]

C'est un Lenovo. J'en suis très satisfait.

 

Ça change de Packard pouBell.

[Noob]

C'est vrai que c'est une bonne marque, le seul défaut que je trouvais aux miens, c'est le niveau plutôt élevé de bruit du ventilateur. (t43p et t400)

C'est à dire que je n'avait jamais l'impression d'avoir un truc vraiment silencieux même en le laissant avec l'écran de veille.

[neuneu2k]

A mon tour d'avoir une question. J'ai un NAS x86 (Linux custom) qui habrite des backups et des données volumineuses, et auquel j'accède soit par SSH (déplacement), soit en lecteur virtuel (local).

 

Je souhaite crypter le volume data, et de la façon dont je le perçois, deux solutions s'offrent à moi :

- un fichier TrueCrypt servant de conteneur pour un volume virtuel, à monter manuellement au (re)démarrage du NAS. Possibilité de crypter avec Serpent ou Twofish.

- encFS sur le partage CIFS

 

Naturellement, la deuxième solution est infiniment plus pratique et "dependable", mais j'ai quelques doutes sur sa sécurité. Avez-vous de l’expérience avec encFS et à votre avis est-ce que je peux lui faire confiance ? Ca m'arrangerait de ne pas devoir passer par TrueCrypt.

 

Je travaillerai en iSCSI (tunnelé pour l'acces distant) avec truecrypt en local, pas de truecrypt coté NAS (sauf que du coup, c'est un SAN ).

[h16]

A vérifier, mais tu dois pouvoir utiliser truecrypt en bas niveau et dans ce cas, il n'y a rien à monter.

[Theor]

Je travaillerai en iSCSI (tunnelé pour l'acces distant) avec truecrypt en local, pas de truecrypt coté NAS (sauf que du coup, c'est un SAN ).

 

De la tuerie, et aucun souci à tunneler par Putty. Et dire que je m'embêtais avec CIFS / SFTP...

 

Du coup, autre question : mon i7 dispose d'une accélération matérielle pour AES; le chiffrage est 10x plus performant que Serpent (que je pensais utiliser). Intéressant, sauf qu'en toute logique j'imagine que des attaquants disposeront aussi d'une accélération matérielle pour craquer du AES, ce qui ne sera pas forcément le cas pour Serpent, moins utilisé.

 

Que recommanderais-tu, donc : AES256 accéléré matériellement, ou Serpent ?

[Noob]

Oui enfin bon c'est pas l'accélération de AES sur leur hardware qui devrait leur donné un hedge sur tes données.

Le principe d'un système de crypto fiable, c'est que ça mette un temps fixe à encoder, et des millénaires à brute forcer.

Quand tu accélères la procédure d'encodage / décodage d'un facteur 10, même si tu passes de plusieurs millénaires à plusieurs siècles à la limite tu 'ten fout un peu non ?

La question c'est plutôt la qualité de ta clé et la robustesse de l'algorithme.

 

[h16]

Oui, AES256 est aussi sûr que ta clé.

[neuneu2k]

Je ne suis pas un cryptanalyste professionnel, juste un amateur, mais j'ai bien plus confience en AES qu'en tous les systèmes asymétriques, que ça soit Rindjael ou ses concurrents, tous passent haut la main toutes les attaques théoriques connues a partir du moment ou on a assez de rounds (et entre une attaque théorique et une application pratique en temps réaliste, il y a un monde), meme dans l'hypothese ou les oracles quantiques ne sont pas de la branlette (je refuse de leur donner le nom d'ordinateur, on ne fera jamais de calculs avec, ça sera, au mieux, un coprocesseur "oracle" pour guider certains algos), ça ne donne pas d'aventage significatif contre un systeme multi-round, il faudrait un oracle aussi profond que le nombre de rounds (aka: ouille, non seulement un round, c'est de la théorie fumeuse, mais 14 !)

 

In AES I trust (l'algo, pas forcément l'implémentation ), il ne faut pas oublier que la NSA a deux tetes, une essaye d'avoir acces à toutes les données, en clair, l'autre a pour mission de certifier la sécurité des systemes militaires et commerciaux américains, le travail q'ils ont fait avec IBM dans la préhistoire sur DES montre qu'ils sont sainement paranoiaques et qu'ils supputent à l'ennemi la capacité maximale (autrement dit, ils les supposent meilleurs qu'eux), donc un algo d'origine publique, vérifié par toute la communauté des cryptanalystes publics ET validé et tuné publiquement par la NSA, j'ai confience.

 

La PKI par contre, j'ai toujours des doutes, je suis pret a risquer pas mal sur RSA 4096, pour l'instant, mais pas forcément des trucs que je souhaite garder secret plus de 10 ans contre une attaque un peu ciblée.

[Theor]

Excellent. Je pars sur AES256, avec un hash en SHA512.

NAS linux + SSH en accès restreint (pour le tunnel) + lun iSCSI + CHAP + formatage NTFS + TrueCrypt en AES256... je pense que je devrais pouvoir stocker mes données avec plus de confiance.

[Yozz]

Je ne suis pas un cryptanalyste professionnel, juste un amateur, mais j'ai bien plus confience en AES qu'en tous les systèmes asymétriques, que ça soit Rindjael ou ses concurrents, tous passent haut la main toutes les attaques théoriques connues a partir du moment ou on a assez de rounds (et entre une attaque théorique et une application pratique en temps réaliste, il y a un monde), meme dans l'hypothese ou les oracles quantiques ne sont pas de la branlette (je refuse de leur donner le nom d'ordinateur, on ne fera jamais de calculs avec, ça sera, au mieux, un coprocesseur "oracle" pour guider certains algos), ça ne donne pas d'aventage significatif contre un systeme multi-round, il faudrait un oracle aussi profond que le nombre de rounds (aka: ouille, non seulement un round, c'est de la théorie fumeuse, mais 14 !)

 

In AES I trust (l'algo, pas forcément l'implémentation ), il ne faut pas oublier que la NSA a deux tetes, une essaye d'avoir acces à toutes les données, en clair, l'autre a pour mission de certifier la sécurité des systemes militaires et commerciaux américains, le travail q'ils ont fait avec IBM dans la préhistoire sur DES montre qu'ils sont sainement paranoiaques et qu'ils supputent à l'ennemi la capacité maximale (autrement dit, ils les supposent meilleurs qu'eux), donc un algo d'origine publique, vérifié par toute la communauté des cryptanalystes publics ET validé et tuné publiquement par la NSA, j'ai confience.

 

La PKI par contre, j'ai toujours des doutes, je suis pret a risquer pas mal sur RSA 4096, pour l'instant, mais pas forcément des trucs que je souhaite garder secret plus de 10 ans contre une attaque un peu ciblée.

Tu as lu Crypto de Steven Levy j'imagine? Très chouette bouquin qui se lit comme un roman d'espionnage racontant l'histoire de la crypto. Pas un bouquin de technique, un bouquin fun.

[Malky]

Rindjael

 

Rijndael, ces salauds de belges ont tout fait pour que 95% de la population se plante en l'écrivant

[neuneu2k]

Rijndael, ces salauds de belges ont tout fait pour que 95% de la population se plante en l'écrivant

 

LOL, c'est encore un coup des gelbes ?

[Malky]

L'algorithme Rijndael a été conçu par Joan Daemen et Vincent Rijmen, deux chercheurs belges, dans le but de devenir un candidat à l'Advanced Encryption Standard (AES) du NIST. Après avoir réussi à se classer dans les six premiers, Rijndael a été choisi comme standard en 2000, prenant la place du premier véritable standard de la cryptographie : le DES (amélioré entre-temps par le Triple DES).

 

[Yozz]

LOL, c'est encore un coup des gelbes ?

Ouais, deux belges, Rijmen et Daemen, et apparemment ils ont collé leurs noms ensemble histoire de tout embrouiller

[Malky]

Applied Cryptography de Bruce Schneier a été un de mes livres de chevet pendant quelques temps

[h16]

Applied Cryptography de Bruce Schneier a été un de mes livres de chevet pendant quelques temps

 

Très bon début.

[Malky]

Oui, maintenant il fait plutôt partie des ouvrages d'histoire de la cryptographie, même si certaines chapitres restent d'actualité. A l'époque le fait d'avoir assimilé applied crypto et une bonne partie du TAoCP de Donald Knuth donnait de sérieuses bases.

[0100011]

Non mais j'ai que des windows-32 sous la main : la différence de qualité d'analyse avec une version 64 bits est frappante. BIen sûr je peux attendre une demi heure et j'aurais le même résultat qu'en 3 min. A vue de nez ça fait 100pts elo de différence (voir le classement CCRL 40/40 : http://www.computerchess.org.uk/ccrl/4040/rating_list_all.html

), c'est quand même palpable. 

 

  Concrètement pour trouver un mat en 18 il me faut 2h contre 1/4 d'heure sur le mac book pro d'un collègue. Ce que je veux c'est pouvoir bidouiller la position et avoir assez rapidement des résolutions de mat pour éliminer certaines configurations. 

 

 

  Comme notre petit projet avance bien on a réussi à motiver des gens de grid5000. Bref la puissance de calcul n'est plus le souci principal Dans quelques semaines il pourrait bien y avoir des résultats... surprenants.

[0100011]

Applied Cryptography de Bruce Schneier a été un de mes livres de chevet pendant quelques temps

  

  J'en ai une version sur ma dropbox  Ca sert toujours pour trouver des références et idées rapidement dans le domaine. Très accessible également. 

[Theor]

Suite aux révélations que MS communique aux gouvernements ses failles de sécurité avant qu'elles ne soient patchées, je n'ai plus autant confiance en mon 7 pro.

Je songe à migrer à Linux en OS principal mais je suis à mon compte et mon portable est ma machine de prod, avec énormément de VM (linux et windows) et de programmes dessus.

 

Je n'ai pas de temps à perdre avec l'OS, ça doit marcher aussi bien que Windows (sans besoin de prier avant chaque apt-get upgrade), et je ne souhaite pas réinstaller une nouvelle version tous les six mois. La sécurité et la fiabilité doivent aussi être impeccables.

Par habitude personnelle, je m'oriente vers une Debian stable avec les repos backports, et un gros usage de VirtualBox pour tout ce que j'avais sous Windows (Office, compta, Photoshop).

Je considère aussi LMDE ou Debian testing, mais elle ne reçoivent pas de mises à jour de sécu fréquentes comme Deb stable.

CentOS serait un autre choix, mais trop lourde à mon goût, pas assez desktop, et difficile à migrer pour les gros changements de version.

 

D'autres ont-il été confronté à ce cas, migrer votre machine de prod vers Linux ? Qu'avez-vous choisi comme distrib, et/ou à quoi songeriez-vous dans le cas évoqué ?