Just Another Geek

Aller au contenu | Aller au menu | Aller à la recherche

Une image de moi

Archive du blog de Nicolas Bareil · restaurée à partir d’Internet Archive · commentaires fermés

mercredi 23 août 2006

Got pwned?

La killer-app de gajim [archive] par rapport aux autres clients Jabber est qu'il est potentientellement plus difficile d'exploiter ce client pour la simple raison qu'il est écrit en Python.

En effet, si on regarde les vulnérabilités publiques de gaim [archive] (logiciel écrit en C), elles touchent toutes à des débordements de buffers ou autres joyeusetés des langages des années 80 :)
Bien sûr, gajim a sûrement des bugs de sécurité, algorithmiques, mais ça signifie que les chercheurs devront se passer de grep et compagnie... On est tranquille :)

Rien que pour ça (et aussi un peu pour ton support natif d'OpenPGP), gajim, malgré ta lenteur, je te garde!

mardi 22 août 2006

On peut mémoriser 10 passwords en 100 secondes, mais on peut pas mémoriser 100 passwords en 10 secondes!

L'article How to Memorize 100 Passwords in 10 Seconds [archive] (via fr.misc.cryptologie [archive]) approche le problème de génération des mots de passe et la multiplication des logins/mots de passe différents.
La solution proposée par Jean-Philippe Aumasson est intéressante et doit ressembler à quelque chose comme ça (à vérifier dans les sources):

 
int passwords[maxpasswords][lenpassword]; /* avec lenpassword = lenpassword/4 */
int i, j;

srand(masterkey);

for (i=0; i < maxpassword; i++) {
  for (j=0 ; j < lenpassword ; j ++)
       passwords[i][j] = rand();

  srand(passwords[i][0]);
}

Ce tableau indexé correspond à n mots de passe disponibles. L'intérêt d'utiliser exclusivement rand() permet de ne pas compromettre p[n+1] ou p[n-1] si p[n] était découvert (car les passwords sont en ASCII, donc chaque octet généré est modulo la taille de l'alphabet). Notons que cela est vrai si et seulement si le PRG est considéré sûr et que la taille de l'alphabet est assez grande.

L'intérêt, face aux gestionnaires de keyring comme pwsafe [archive] ou revelation [archive], est que cet algorithme vous permet de ne pas avoir à vous balader avec votre keyring partout, vous avez juste besoin du programme, votre master key en tête... et d'une liste qui associe pr0nwild.com à l'index n de votre table de mot de passe.

Tout ça pour dire que je n'ai toujours pas trouvé un gestionnaire de mots de passe correct avec les fonctionnalités suivantes :

  • Chiffrement standard (cad déchiffrable dans openssl) du keyring,
  • Frontend graphique,
  • Frontend console,
  • Pas constamment cassé comme revelation dans Debian,
  • Plus fonctionnel que pwsafe;

Update quelques heures plus tard : En fait, je ne sais pas ce qui est le mieux ; une taille d'alphabet grande ou petite ? Plus elle est grande, plus les caractères du password seront aléatoires, mais la difficulté de retrouver le mot de 32 bits à partir du modulo sera diminué... Enfin je me comprends...

jeudi 10 août 2006

Free kevin!

Une chose est sûre, si je dois acheter un nouvel ordinateur, le chipset sera Intel après l'annonce faite sur LKML : Announcing free software graphics drivers for Intel i965 chipset [archive].

Ou alors on attends les résultats du rachat d'ATI par AMD [archive]...

mercredi 9 août 2006

On efface tout et on recommence

Comme je l'avais indiqué dernièrement, j'ai changé d'adresse mail ainsi que de clef GnuPG et il est temps que je me sépare de l'ancienne clef (0x09223052 [archive]) en faveur de deux clefs, l'une perso [archive] et l'autre professionnelle [archive].

Pensez à "truster" ma clef pour ceux qui l'ont déjà fait pour l'ancienne, une preuve que c'est bien moi est d'avoir signé la page d'explication de la révocation et les nouvelles clefs [archive].

% wget http://chdir.org/~nico/revocation-gpg-0x09223052.txt
% gpg --verify revocation-gpg-0x09223052.txt

2006/08/09

Configuration d'xpdf

J'avais jamais pensé à configurer xpdf, voila qui est fait.

% cat ~/.xpdfrc
psPaperSize A4
initialZoom width
antialias yes
errQuiet yes

Les options intéressantes sont errQuiet et initialZoom en fait.

mercredi 2 août 2006

Le noyau kibboutz tout seul

Pourquoi réimplémenter le support des filesystems dans les bootloaders (tel que Grub) alors qu'ils sont déjà disponibles dans le noyau Linux ? C'est en partant de cette problématique que les développeurs de kboots [archive] ont développé un bootloader basé sur... le noyau Linux lui-même.

Le fonctionnement idéal de kboots est qu'une fois le stage1 chargé, il lance le noyau trafiqué avec son propre initramfs contenant une mini distribution basée sur µlibc et busybox. Dès lors, le menu de sélection peut s'afficher (qui tourne en userspace). Jusqu'ici, rien d'extraordinaire, mais voyons plutôt le potentiel de ce genre de bootloader :

  • Support natif de tous les filesystems (et il n'y a alors plus le support b0rken d'XFS comme dans Grub) de base,
  • Accès à toutes les fonctionnalités du noyau Linux et de la mini-distribution integrée. Par exemple, vous pouvez faire tourner un sshd (ok, c'est un dropbear) dans le bootloader ce qui est pratique si vous vous êtes complétement foiré dans la configuration de votre noyau hebergé dans une salle aux USA.
  • Vous pouvez booter n'importe quel device supporté par Linux : Firewire, USB, Flash, etc.
  • Et même par le réseau : FTP, HTTP, TFTP, etc.

Je pense qu'il y a un vrai potentiel à kibboutz [archive]^Wkboots. Après essai (et la compilation pendant une heure de tout ce qu'il fallait dans une petite VM), ca marche bien mais :

  • C'est tout de même lent : il faut attendre le temps de boot d'un noyau Linux classique, donc au moins 30 secondes, puis le vrai noyau est lançé via kexec donc encore 30 secondes d'attente
  • C'est testé sur x86 only :(
  • Il n'y a pas encore le support de système autre que Linux
  • Le stage1 n'est pas encore implémenté ! Donc en gros, il faut lancer kboot via votre bootloader favori. Pas glop mais ca marche très bien.

Même si certains médisants du bureau ne prennent pas au sérieux cette solution, je trouve ça très prometteur et j'envisage d'utiliser kboots sur des serveurs lointains...