Bar Le Linux BAR - Discussion de tout et de rien

[theocrite]

Hm.

Le bar était déserté depuis quelque temps. Mais il se reconvertit maintenant en bookmark/freepost land. Spa vraiment top.

Allez une info (histoire de tenter de parler de quelque chose de consistant et d'éviter le freepost) : Une asso libre du Québec attaque le gouvernement en justice pour une attribution d'un marché (important) à MS sans passer par l'appel d'offres.

[Compte_supprime_74291]

Tiens, question-à-la-con... quelqu'un saurait me dire avec quel genre d'algo kwallet chiffre-t-il ses mots de passes ?

... je n'arrive à trouver ça nul part... pas très engageant, surtout pour un bouzin qui est déjà de l'ordre du cache-misère...

[lorinc]

Je viens de mater le code, et le vainqueur est.... Blowfish ! tadam !

Le svn contient un sha et un bf, le sha à l'air d'être utilisé pour hasher le pass du portefeuil et le bf pour chiffrer le contenu du portefeuil :

http://websvn.kde.org/trunk/KDE/kdelibs/kwallet/backend/

extrait

BlowFish _bf;
CipherBlockChain bf(&_bf);
int blksz = bf.blockSize();
if ((encrypted.size() % blksz) != 0) {
	return -5;	   // invalid file structure
}

// Decrypt the encrypted data
passhash.resize(bf.keyLen()/8);
password2hash(password, passhash);

bf.setKey((void *)passhash.data(), passhash.size()*8);

if (!encrypted.data()) {
	passhash.fill(0);
	encrypted.fill(0);
	return -7; // file structure error
}

int rc = bf.decrypt(encrypted.data(), encrypted.size());
if (rc < 0) {
	passhash.fill(0);
	encrypted.fill(0);
	return -6;	// decrypt error
}

Heureusement que c'est libre, on peut zieuter

[windu.2b]

Je viens de mater le code, et le vainqueur est.... Blowfish ! tadam !

Le svn contient un sha et un bf, le sha à l'air d'être utilisé pour hasher le pass du portefeuil et le bf pour chiffrer le contenu du portefeuil :

http://websvn.kde.org/trunk/KDE/kdelibs/kwallet/backend/

extrait

BlowFish _bf;
CipherBlockChain bf(&_bf);
int blksz = bf.blockSize();
if ((encrypted.size() % blksz) != 0) {
	return -5;	   // invalid file structure
}

// Decrypt the encrypted data
passhash.resize(bf.keyLen()/8);
password2hash(password, passhash);

bf.setKey((void *)passhash.data(), passhash.size()*8);

if (!encrypted.data()) {
	passhash.fill(0);
	encrypted.fill(0);
	return -7; // file structure error
}

int rc = bf.decrypt(encrypted.data(), encrypted.size());
if (rc < 0) {
	passhash.fill(0);
	encrypted.fill(0);
	return -6;	// decrypt error
}

Heureusement que c'est libre, on peut zieuter

[Mode jvachez=on]

Mais alors... si le code est libre, ça veut dire qu'on peut facilement casser les mots de passe ?!?

[Mode jvachez=off]

Edit : petit lien ici

Modifié le 18 mars 2008 par windu.2b

[Compte_supprime_74291]

Je viens de mater le code, et le vainqueur est.... Blowfish ! tadam !

Le svn contient un sha et un bf, le sha à l'air d'être utilisé pour hasher le pass du portefeuil et le bf pour chiffrer le contenu du portefeuil :

http://websvn.kde.org/trunk/KDE/kdelibs/kwallet/backend/

Par contre, sha1 pour le mot de passe maître ... c'est faible... d'autant pour un truc qui "protège" justement des passes (enfin, on pourrait tout autant dire expose ... vu que les applis viennent chercher les passes, plutôt qu'ils ne soient distribués activement aux applis par le wallet, à son ouverture, comme ce serait idéal qu'ils soient)...

Dommage qu'ils ne relèguent pas ça à gnupg ou cie, plutôt que de faire à leur sauce, pour le hash (et même le chiffrement)...

Modifié le 18 mars 2008 par Aefron

[lorinc]

tu voudrais les chiffrer avec ta clé publique pour ête le seul à pouvoir les décoder ? Remarque, peut-être simplement qu'il manque une lib unifiée de crypto qui pourrait avoir plusieurs backend (cryptoapi, gnupg, etc...)

[aurielle]

A tout hasard, y a t'il des personnes d'île de France intéressée pour faire de la promotion du logiciel libre, le 23 mai dans le cadre de la fête de l'internet de façon bénévole?

[Compte_supprime_74291]

tu voudrais les chiffrer avec ta clé publique pour ête le seul à pouvoir les décoder ?

Les chiffrer avec l'une de mes clés publiques, non, pas forcément... par contre, être le seul à raisonnablement pouvoir les déchiffrer (une passphrase longue et solide met déjà les risques de brute-forcing hors de "l'usuel"), ça me paraît un minimum...

... et pour ça, un autre minimum éventuel serait de hasher le pass avec quelque chose qui tient la route, et pas une sombre cochonnerie obsolète comme sha1...

D'ailleurs, en se basant sur un backend éprouvé et versatile, en sus d'utiliser le chiffrement que l'on veut, avec le hash que l'on veut, on bénéficierait au moins d'un audit sérieux sur la crypto... parce que là, déjà qu'il faut aller fouiller dans le code pour savoir ce que ça utilise, alors de là à ce que kwallet ait été audité sur ce plan...

Bref, kwallet, ça ne casse pas trois pattes à un canard... dommage...

Pourtant, quelque chose du genre qui serait carré niveau crypto, et qui débloquerait lui-même les mots de passe (m'est avis que ça aurait été un meilleur design, vu que kwallet ne gère que les applis kde... il devrait pouvoir contrôler les applications, plutôt que d'attendre qu'elles viennent y piocher les mots de passe en clair comme elles veulent, sur un plateau d'argent), ce serait tip-top...

Bon, je critique (j'espère au moins constructivement), mais après, je ne sais pas coder... donc...

[theocrite]

Mouais, ce n'est pas comme si sha1 était mort non plus.

La meilleure attaque à ma connaissance, c'est l'attaque basée sur le paradoxe des anniversaires (améliorée). Avec cette attaque, sha1 est moins couteuse qu'un bruteforce sur MD5 (d'un facteur 2), mais ce n'est pas pour autant que c'est à la portée de tout le monde (il faut beaucoup de grosses machines).

Mais bon, c'est sûr qu'utiliser du sha256, ce n'est pas du luxe.

En tout cas pour blowfish, mon préféré

[Compte_supprime_74291]

Mais bon, c'est sûr qu'utiliser du sha256, ce n'est pas du luxe.

Plus ça va, plus sha1 est déconseillé... certes, ce n'est pas à la portée de tout le monde de le casser, mais le proof of concept est là...

... ce que je trouve vraiment dommage là-dedans, c'est de ne pas laisser le choix du chiffrement et du hash, avant toute chose (et aussi le fait que je n'aime pas trop le concept d'un wallet ouvert à tout vent une fois qu'on l'a déchiffré, bien que ça n'ait pas grand chose à voir avec ma question initiale)...

... faudrait que je zieute le bts de KDE, et que je formule la demande, au besoin...

[windu.2b]

... faudrait que je zieute le bts de KDE, et que je formule la demande, au besoin...

vois aussi s'il n'y a pas un framework de prévu pour KDE4, à ce sujet... Les types se sont tellement lancés dans plein d'idées, que ça m'étonnerait que personne n'ait pensé à proposer cela : un framework de crypto destiné à centraliser les algos pour toutes les applis le nécessitant (donc pas de redondance de code), voire carrément accessible même pour les applis non-KDE (là, faudrait peut-être en toucher un mot à freedesktop.org).

Mais malgré toutes mes recherches sur KDE 4, je ne me souviens en tout cas pas d'avoir entendu parler de ça, ce qui est tout de même curieux

Edit : je me contredis : je viens de voir qu'il existe QCA (Qt Cryptographic Architecture). Ça n'est pas un framework de KDE, mais c'est un bon début...

[lorinc]

bon, je suis quand même allé fouiller dans le svn de KDE4, donc s'il y avait un bout de projet là dessus, ça se serait vu...

Dans le code, je me rappelle avoir croisé un bout de commentaire disant grosso merdo que pour la prochaine release ce serait bien d'utiliser sha256. Cela dit, c'est vrai qu'un vrai framework qui servirait de glue pour les applis KDE à un backend éprouvé (un peu comme phonon en quelque sorte), ce serait vraiment un plus.

[Compte_supprime_74291]

Ca a l'air d'être sympa, QCA ... c'est un peu ce qu'il faudrait à toutes les applis qt usant de chiffrage...

[Compte_supprime_74291]

Juste un petit message pour dire du bien d'un projet bien sympathique pour ceux qui en ont raz-plein-de-trucs de cumuler les télécommandes et de jouer le clown jongleur avec... : Concordance ...

Concordance (enfin, Harmony, pour l'instant, mais la prochaine version 0.20 qui doit sortir bientôt, en plus d'amener un split entre librairie et frontend, apporte un changement de nom) est un projet permettant de configurer une télécommande logitech harmony (pas toutes, mais peu ou prou apparemment tout ce qui est "moins über-classe" que les 890) à partir de linux.

Le tout se base sur libusb, et, bien que très jeune (petit background en langue angloise), marche plutôt pas mal...

Pour l'instant, la version stable (pas tant que ça, puisqu'une régression dans la 0.13 m'empêche de mettre à jour la config de ma 555, bien que ça fonctionne bien dans la 0.12... bon, le CVS est très actif, apparemment) ne permet que d'uploader à la télécommande une configuration effectuée sur le site des possesseurs de télécommandes harmony (sur lequel il faut donc s'inscrire, ce qui permet d'accéder à une grosse base de données constructeur... en gros, on rentre son modèle d'appareil, on programme les macros pour certaines actions, et en résulte un fichier à télécharger et à uploader via Concordance), de répondre au test de connection du-dit site, d'apprendre de nouveaux codes non présents dans la base logitech...

Que ça ? Bah oui... reste encore un point noir... le firmware... ma télécommande était livrée avec un firmware plus vieux que celui qu'il faut pour utiliser le site en ce moment, et nécessitait donc une mise à jour de celui-ci... ce que Concordance (enfin, Harmony... enfin... euh, bref) ne sait pas encore faire... cependant, à la lecture de la mailing-list, ça a l'air d'être la fonctionnalité la plus travaillée en ce moment, avec le split en une lib et un frontend... il y a donc bon espoir qu'une prochaine release permette de se passer d'os redmondien ou autre propriété (il me semble que ça marche aussi sur macos) pour mettre à jour le firmware (non libre, mais distribué aux inscrits par logitech) de la télécommande...

Enfin, bref, un petit projet qui ne demande que les sources de libusb pour être compilé en deux coups de cuiller à pot, qui ne marche pas trop mal pour un truc encore tout jeune, et qui mérite bien qu'on dise du bien de lui... voilà, c'est fait

[Dark26]

/ ma vie on /

226 Transfer complete.

731835552 bytes sent in 7.11 secs (100468.7 kB/s)

ftp>

7 secondes pour tranférer 1 DIVX de vacances.

je suis un peu limité du côté de la workstation ( 80giga maxtor 40 Mo/s ) , mais bon une fois que le fichier est en RAM

de l'autre coté raid0 sur 3 disques dur

15 minutes pour faire fonctionner cette saloperie de ftp . Et oui en voulant mettre de l'openldap, ça complique enormément ce qui est simple .

edit : ou ben en fait mon raid 0 est pas performant seulement 95Mo /s. quelle idée aussi de mettre les partitions du raid à la fin des disques durs ( j'aurais le double si les partitions étaient au début).

/ ma vie off /

Modifié le 20 mars 2008 par Dark26

[Dark26]

bon une colle pour les prox du système :

serveur:~# ln -s /sys/devices/platform/it87.656 /sys/bus/i2c/devices/it87.656

ln: création d'un lien symbolique `/sys/bus/i2c/devices/it87.656' vers `/sys/devices/platform/it87.656': Aucun fichier ou répertoire de ce type

Pourquoi ça ne fonctione pas

PS : gkrellm va lire les sondes dans /sys/bus/i2c/devices alors qu'elles sont dans /sys/devices/platform/it87.656

[tyrann27]

Et l'arborescence "/sys/bus/i2c/devices/" existe déjà bien sur ?

Sinon il sait pas créer le lien

[Dark26]

Et l'arborescence "/sys/bus/i2c/devices/" existe déjà bien sur ?

Sinon il sait pas créer le lien

oui "/sys/bus/i2c/devices/" existe bel et bien

il y a peut être des retsrictions pur les lien dans le répertoires /sys

[tyrann27]

C'est une possibilité mais je doute quand même...

Surtout quand je vois l'erreur...

Et t'as essayé de te mettre dans /sys/bus/i2c/devices/ et de faire un

ln -s /sys/devices/platform/it87.656

[Dark26]

C'est une possibilité mais je doute quand même...

Surtout quand je vois l'erreur...

Et t'as essayé de te mettre dans /sys/bus/i2c/devices/ et de faire un

ln -s /sys/devices/platform/it87.656

non j'ai pas essayé.. sutout que je pensais qu'il fallait absolument source et destination dans la commande.

[theocrite]

Le message d'erreur est sur /sys/devices pas sur /sys/bus.

[tuXXX]

C'est surtout que de toute façon y'a pas le droit de créer quoi que ce soit dans /sys/ (comme /proc/ en fait), ce sont des systèmes de fichiers "virtuels" qui sont gérés directement par le noyau.

[moitrux]

Héhé c'est avec plaisir que je vous annonce mon passage a linux (que sur mon 2eme pc pas ma config dans la signature), j'ai installé ubuntu 7.04, je risque de soliciter vos connaissances car la j'avoue etre un peu paumé (trop habitué a windows) !

[Dark26]

C'est surtout que de toute façon y'a pas le droit de créer quoi que ce soit dans /sys/ (comme /proc/ en fait), ce sont des systèmes de fichiers "virtuels" qui sont gérés directement par le noyau.

c'est ce qui me semblait ... . c'est bête que le chemin soit en dur dans gkrellm ( ou alors pas trouver ou le changer ) ..

j'avais le même problème avec fan control , mais le chemin était dans le script de démarrage donc plus facile à le changer...

peut être du à mon installation "non officielle" avec la version batarde de debian avec le kernel 2.6.24

la télécommande de mon terratec cynergy t2 fonctionne avec xmms

je suis en train de monter mon serveur web pour vous montrer les photos de la bête

[tyrann27]

Ah ben j'aurais cru qu'on pouvait !

Mais il doit y avoir une solution quand meme non ?