Ashram de Swâmi Petaramesh - chiffrement - Commentaires

Une clé de contact pour votre portable chiffré - Swâmi Petaramesh

Swâmi Petaramesh — Thu, 12 Jun 2008 07:43:45 +0200

@Julon : Donc, tu nous expliques en substance que tu as essayé d'utiliser un script conçu uniquement pour fonctionner depuis l'initramfs pour monter une racine sur LVM chiffrée, sur une machine dont la racine n'est pas chiffrée et qui n'utilise pas de LVM... Non, rien :-D

Cela dit, il n'est pas bien compliqué de copier l'intégralité de ton système sur un disque externe puis de créer une LVM chiffrée et tout retransférer dessus ;-)

Une clé de contact pour votre portable chiffré - julon

julon — Wed, 11 Jun 2008 22:19:27 +0200

Tout d'abord, merci pour ta réponse rapide!

Pour une raison qui m'échappe, ton bootkeyscript ne fonctionne pas sur ma config - peut-être parce que mes disques cryptés n'ont pas été créés de la même manière que les tiens vu qu'ils sont hérités d'un Fedora 6, sans lvm (le root n'est pas crypté, donc).

Toujours est-il que j'ai résolu le problème en créant un tout petit script taillé pour mes besoins uniquement, en m'inspirant de ton bootkeyscript.

Une clé de contact pour votre portable chiffré - Swâmi Petaramesh

Swâmi Petaramesh — Tue, 10 Jun 2008 23:17:26 +0200

@Julon : Pas bien précise ta description, mais je parie sur un /etc/crypttab foireux, genre double entrée pour la LVM racine...

Une clé de contact pour votre portable chiffré - julon

julon — Tue, 10 Jun 2008 22:53:50 +0200

Bonjour,

Ca l'a été dit plusieurs fois, mais j'imagine que ça n'est jamais superflu: cet article est très intéressant, d'autant plus qu'il correspond exactement à ce que je cherche à faire, et en nettement plus propre que mes propres bidouillages (changement des scripts init etc..).

Cependant, j'ai un petit soucis avec le script bootkeyscript: en effet, j'ai de belles lignes d'erreur au moment du boot me disant qu'il ne trouve pas le fichier /scripts/functions. Après avoir jeté un oeil à bootkeyscript, il y a un appel à ce fichier au tout début - c'est même la première ligne de code.

Je me débrouille un peu sous linux, suffisamment pour avoir une idée de comment tout ça fonctionne, mais les fonctions des scripts d'initialisation, c'est bien au-delà de mes connaissances.

Une idée d'où est le problème? Ma config est un Ubuntu Hardy Heron tout frais.

En espérant que ce billet n'est pas encore dans le cimetierre des blogs, d'avance merci!

Une clé de contact pour votre portable chiffré : Mise à jour - Swâmi Petaramesh

Swâmi Petaramesh — Tue, 03 Jun 2008 15:10:19 +0200

@mitch : La dernière Ubuntu 8.04 que j'ai installée, je l'ai faite avec l'alternate install CD en LVM par-dessus du RAID-1 soft, et ça le fait bien. Mais je n'ai pas tenté le coup "LVM chiffrée" sur celle-là, par contre... Je ne vois pas trop pourquoi ça ne le ferait pas ?

J'ai simplement remarqué à cette occasion (c'était la première fois que je jouais avec le CD alternate) qu'il était beaucoup plus long de le faire ainsi en suivant les systèmes de menus à la con que de préparer tout ça à la main en ligne de commande vite-fait bien-fait mdadm / fdisk / cryptsetup / lvm / mke2fs en utilisant le CD-live ordinaire avant de balancer l'install ordinaire par-dessus...

Donc je continuerai sans doute de tailler mes prochaines machines à la main avec le CD d'install live bête et con ;-)

Une clé de contact pour votre portable chiffré : Mise à jour - mitch

mitch — Tue, 03 Jun 2008 14:57:18 +0200

"Un moyen facile, allez : Le CD Ubuntu/Kubuntu "Alternate Install" permet de faire automatiquement l'installation sur une LVM chiffrée, donc d'avoir une machine entièrement chiffrée (sauf /boot)."

C'est ce que j'ai fait sur un vieux portable, c'est facile en effet.

Une question sinon, est-ce possible d'installer cette lvm chiffrée sur un volume raid c'est à dire en combinant raid, lvm, luks/dm-crypt et ext3 pour installer le système ? Parce qu'avec l'alternate cd, une fois qu'on a configuré le volume raid on a plus accès à l'option chiffrement intégral (qui est plutôt rassurante pour un non spécialiste comme moi).

C'est ce que j'ai en tête pour ma prochaine machine : 3 ou 4 disques identiques en raid5, et faire l'installation sur lvm chiffrée. Mais bon, je mets peut être les pieds dans qqchose de trop technique.

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Mon, 02 Jun 2008 15:03:03 +0200

@ccal : Tu as raison, ça s'appelle une erreur de copié/collé de ma part. J'ai suffixé mes propres clés en .bin ce qui n'est pas nécessaire, je l'ai viré de quelques entrées dans le commentaire ci-dessus pour les raccourcir, et je l'ai oublié dans l'autre... Je vais corriger l'erreur ci-dessus, merci :-)

Retailler à la volée une LVM chiffrée LUKS - ccal

ccal — Mon, 02 Jun 2008 14:56:34 +0200

c'est /etc/keys/.sdb1.key sans l'extention .bin dans /etc/crypttab non ?

Retailler à la volée une LVM chiffrée LUKS - mitch

mitch — Sun, 01 Jun 2008 13:53:55 +0200

Super !!! Merci beaucoup !

M'en vais bidouiller mon EeePC moi ... gnark gnark gnark :-)

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Sun, 01 Jun 2008 08:25:11 +0200

@mitch : Chiffrement de la carte SD du EEEPC d'asus avec luks (montage automatique au boot, inutilisable sans la machine).

C'est ce que je fais sur le mien (la carte SD reste dedans en permanence, me sert de "disque dur étendu" grâce à un jeu de liens symboliques, est montée automatiquement au boot avec l'ensemble du système chiffré).

Rien n'est plus simple. Il suffit de chiffrer la carte SD en LUKS avec un fichier-clé aléatoire que je conserve dans /etc/keys (le root filesystem étant lui-même chiffré, cela ne pose pas de problème), le fichier-clé ayant été initialement généré avec une instruction du genre :

dd if=/dev/random of=/etc/keys/.sdb1.key bs=1 count=512

Avant de chiffrer la carte SD avec :

cryptsetup luksFormat /dev/sdb1 /etc/keys/.sdb1.key

(Ouvrir ensuite manuellement le container et créer un filesystem dedans avec mke2fs.)

Il suffit ensuite de mettre dans /etc/crypttab:

SD_card /dev/sdb1 /etc/keys/.sdb1.key luks,check,checkargs=ext3

et dans /etc/fstab :

/dev/mapper/SD_card /mnt/SD_card ext3 noatime 0 0

C'est tout !

N.B.: Si l'on veut que le montage de la carte SD chiffrée survive à une suspension ou une hibernation du système, il faut utiliser un noyau supportant "USB_PERSIST", c'est-à-dire au moins un 2.6.24. J'utilise celui-ci sur mon EeePC. (Attention, il est vulnérable à l'affreuse faille de "local privilege escalation")

Retailler à la volée une LVM chiffrée LUKS - mitch

mitch — Sat, 31 May 2008 20:13:22 +0200

Nickel, merci pour ce billet technique. Clair, pertinent, qui permet d'apprendre énormément de chose (comme d'hab. quoi!).

Il ne te reste plus qu'à rédiger des billets du style :

Chiffrement de la carte SD du EEEPC d'asus avec luks (montage automatique au boot, inutilisable sans la machine).
Un billet qui explique comment résoudre simplement le bug https://bugs.launchpad.net/gnome-mo... et le quidam moyen pourra chiffrer toute sa production simplement.

Merci encore pour la qualité de tes billets.

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Thu, 29 May 2008 13:53:28 +0200

@Gab : Oui, c'est tout l'intérêt des LVM et systèmes apparentés, que de s'affranchir des limites strictes, bêtes et méchantes qui s'appliquent aux partitions de disques...

Aucun outil libre, à ma connaissance, ne permet de redimensionner une partition autrement que par la fin, aucun outil libre ne permet d'en déplacer le début (sauf à recopier l'ensemble de la partition vers l'avant du disque si on a la place suffisante).

Note que si l'on aime les acrobaties risquées, on peut déplacer une partition vers le début du disque avec un bête "dd" et la partition s'écrasera alors elle-même pendant sa propre copie. Ça marche, c'est sauvage à faire, mais il vaut mieux que rien n'interrompe le processus avant le coup de fdisk final...

Il existe un outil qui permet de retailler, copier et déplacer les partoches dans tous les sens, mais c'est un outil commercial que je ne citerai donc pas ici, et d'autant moins qu'il est très risqué de l'utiliser pour retailler un disque qui a été initialement partitionné avec des outils différents et qui n'avaient pas forcément la même vision de la géométrie du disque. Ah, les différentes visions de la géométrie d'un disque de nos jours, c'est rien que du bonheur... Faut même parfois faire gaffe selon la version de noyau avec laquelle on a booté la machine, je me suis parfois vu obligé de lancer fdisk en forçant manuellement une vision particulière de la géométrie d'un disque pour pouvoir retailler sans casser des trucs qui avaient été faits par gparted sur un live-CD utilisant une autre version de noyau.

Tiens, la machine sur laquelle je suis, là :

Selon le noyau (dmesg) :

[sda] 312581808 512-byte hardware sectors (160042 MB)

Selon fdisk :

# fdisk -l /dev/sda
Disque /dev/sda: 160.0 Go, 160041885696 octets
255 heads, 63 sectors/track, 19457 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes

Selon hdparm :

RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?8?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312581808

Tu noteras peut-être une certaine différence de la vision de la géométrie C/H/S selon qu'on pose la question à fdisk ou hdparm, et je ne préfère même pas savoir ce que le BIOS en pense...

Il y a des cas où ce genre de chose peut avoir des conséquences franchement rigolotes...

Retailler à la volée une LVM chiffrée LUKS - Gab

Gab — Thu, 29 May 2008 13:15:11 +0200

Vu comme ça, certes. Mais j'ai toujours trouvé ça contraignant de devoir avoir de la place //après// pour redimensionner une partition. A ma connaissance il n'y a pas de méthode si on a de la place //avant// ou //ailleurs// (à part avec lvm).
Le cas le plus général, en tous cas que j'ai le plus souvent croisé, est que d'un coup une partition ne sert plus (parce qu'on l'a déplacé sur un disque qu'on vient d'acheter, par exemple), et cette partition n'est pas du tout derrière celle qu'on voudrait agrandir.
Et là, ta méthode ne fonctionne pas, d'où la qualification de 'cas particulier' ;)

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Thu, 29 May 2008 08:27:23 +0200

@gab (re) : A part insister sur le fait que ce que tu présente un cas très particulier

Pour revenir là-dessus, il me semble que ce que tu considères comme un "cas particulier" est le fait d'étendre une partition alors qu'on dispose d'espace libre adjacent. Si tu y réfléchis une seconde, tu t'apercevras que toute extension de partition nécessite au préalable de disposer d'espace disque libre adjacent, et que si l'on n'en a pas, il faut donc en faire ;-)

Il me semble donc que ce "cas particulier" ramène donc bel et bien à un cas général.

D'autre part, s'agissant de l'extension d'une LVM chiffrée sur laquelle est installée tout un système, on n'aura généralement sur le disque pas d'autres partitions qu'un petit /boot et une grosse partition pour la LVM chiffrée. S'il reste de la place, soit elle aura été laissée libre "pour le cas où, un jour...", soit elle aura été utilisée pour des partitions spécifiques, typiquement temporaires, qui peuvent être supprimées sans casse (mon cas), soit elle aura été utilisée pour un quelconque espace de stockage additionnel que l'on pourra sans problème recopier sur un support externe le temps d'effectuer les modifications nécessaires (puisque par définition ce qui n'est pas à l'intérieur de la LVM chiffrée n'est pas vital au fonctionnement du système...).
Et il y a bien sûr aussi le cas de figure de l'extension de la LVM après recopie de l'ensemble du système sur un disque plus gros, situation commune où la présence d'espace libre derrière la LVM coule de source.

Décidément, je trouve ce cas particulier vraiment bien général ;-)

Retailler à la volée une LVM chiffrée LUKS - Le Joker

Le Joker — Wed, 28 May 2008 20:44:58 +0200

charge guruïque .

C'est un truc de sanglier ca !

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 28 May 2008 18:17:00 +0200

Mouarf, c'est pas parce que ça marche que c'est particulier, on n'est pas sous Windows :-D

Retailler à la volée une LVM chiffrée LUKS - Gab

Gab — Wed, 28 May 2008 18:05:43 +0200

@S.A.S. Swâmi

> j'émets quelques légers doutes quant à l'utilité pratique de ton commentaire...

A part insister sur le fait que ce que tu présente un cas très particulier? Aucun :)

Retailler à la volée une LVM chiffrée LUKS - krysalia

krysalia — Wed, 28 May 2008 15:55:18 +0200

Ouais. Mais t'as un système d'exploitation bien rangé qui tourne bien... On ne peut pas tout avoir :D

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 28 May 2008 14:30:09 +0200

@Krysalia : J'adore m'adonner aux trucs les plus débridés, hélas, ma charge guruïque m'en laisse trop peu le loisir :-}

Retailler à la volée une LVM chiffrée LUKS - krysalia

krysalia — Wed, 28 May 2008 14:20:38 +0200

Quoiii ? en ces temps de disette tu t'adonnes au luks le plus débridé ?
y'en a qui ont de la chance ici :}

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 28 May 2008 08:40:10 +0200

Tiens, j'ai eu le plaisir de voir hier soir qu'une corrective que j'ai apportée au package cryptsetup a été acceptée et incorporée aux futurs packages cryptsetup Ubuntu...

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Tue, 27 May 2008 15:45:04 +0200

@ccal : Merci, le typo que tu m'as signalé est corrigé.

> Tu utilises aes-cbc-essiv:sha256 pour chiffrer ?

C'est ce que propose cryptsetup par défaut pour LUKS, mais pour des raisons de performances j'utilise généralement une clé plus courte (AES128 ou 192, surtout pour du swap ou du temp) qui me semblent bien suffisants en termes de sécurité (au rapport du contenu des machines), le "SHA256" ici étant pour les IVs.

Retailler à la volée une LVM chiffrée LUKS - ccal

ccal — Tue, 27 May 2008 15:36:21 +0200

Correction :
- updfate-initramfs -u
+ update-initramfs -u

Tu utilises aes-cbc-essiv:sha256 pour chiffrer ?

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Tue, 27 May 2008 15:02:33 +0200

UNIX Sex: {look; find; talk; grep; touch; finger; find; flex; unzip; mount; workbone; fsck; yes; gasp; fsck; yes; eject; umount; makeclean; zip; split; done; exit}

Retailler à la volée une LVM chiffrée LUKS - Christine

Christine — Tue, 27 May 2008 14:42:25 +0200

@Chompitiarve : c'est vrai, en cherchant bien j'ai trouvé
dur
incorporer
à l'intérieur
à l'extérieur
plus gros
plus drôle
erreur
j'agrandirai le volume physique
manuellement
vraiment terrifiante
montées
changement de taille
truly bad

Finalement, ça peut l'faire ;-))

Retailler à la volée une LVM chiffrée LUKS - Chompitiarve

Chompitiarve — Tue, 27 May 2008 14:07:30 +0200

@Christine
Pourquoi digresser? On est en plein dans le sujet, non ?
Bon, d'accord ça suppose une certaine orientation-objet de nos penchants, un fau(x)con n'y suffira peut-être pas ...

:-)

Retailler à la volée une LVM chiffrée LUKS - Christine

Christine — Tue, 27 May 2008 13:18:52 +0200

Et ben dis donc, pour trouver matière à digression sexuelle, je vais ramer ;-))

Retailler à la volée une LVM chiffrée LUKS - Le Joker

Le Joker — Tue, 27 May 2008 12:57:41 +0200

Tout cela est bel et bien beau mais n'a quand même rien a voir avec les paysages magnifiques de la Patagonie septentrionale surtout vus par l'oeuil d'un Yaka-Faucon en vol, fut-il d'élevage.

Retailler à la volée une LVM chiffrée LUKS - Swâmi Petaramesh

Swâmi Petaramesh — Tue, 27 May 2008 12:50:18 +0200

@Gab : Sauf que ton truc avec fdisk ne marche QUE si les partoches /tmp et swap sont physiquement à côté de la partoche que tu veux redimensionner!

Te ferai-je remarquer que c'était précisé dans le texte ?

> en plus si tu te plante d'un octet lors de la re-création, toute le partoche dégage...

Tu ne peux pas te planter "d'un octet". Tu peux te planter d'un cylindre ;-)

> Bref, un peu dangereuse, cette méthode :)

Te ferai-je remarquer que c'était précisé en gras dans le texte ?

Maintenant, si tu en connais une "pas dangereuse", je suis preneur ; dans le cas contraire, j'émets quelques légers doutes quant à l'utilité pratique de ton commentaire...

Retailler à la volée une LVM chiffrée LUKS - Gab

Gab — Tue, 27 May 2008 12:37:19 +0200

Sauf que ton truc avec fdisk ne marche QUE si les partoches /tmp et swap sont physiquement à côté de la partoche que tu veux redimensionner!
Si elles sont ailleurs, tu vas rien agrandir du tout.
Il faut bien préciser qu'agrandir une partition de cette manière n'est possible que s'il y a de l'espace disque derrière. Et en plus si tu te plante d'un octet lors de la re-création, toute le partoche dégage...
Bref, un peu dangereuse, cette méthode :)

Une clé de contact pour votre portable chiffré : Mise à jour - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 14 May 2008 09:00:04 +0200

@Le Joker : une "page" compilatoire reprenant l'intégrale de cette saga de cryptage de portable ne serait pas du luxe pour celui (ou celle) qui voudrait tout refaire depuis le début.

Beh, y'en n'a pas tant que ça ;-)

Un moyen facile, allez : Le CD Ubuntu/Kubuntu "Alternate Install" permet de faire automatiquement l'installation sur une LVM chiffrée, donc d'avoir une machine entièrement chiffrée (sauf /boot).

Si on veut ensuite ajouter la fonction "clé de contact", il doit suffire de faire cette dernière étape après avoir fait l'install chiffrée "automatique" comme un bon gros bourrin :-}

L'intérêt de mes articles précédents est essentiellement de décortiquer le mécanisme, proposer des solutions alternatives et expliquer la conversion d'une machine d'une installation non chiffrée vers une installation chiffrée.

Une clé de contact pour votre portable chiffré : Mise à jour - Le Joker

Le Joker — Mon, 12 May 2008 20:26:51 +0200

Comme je remarque que personne n'a mis de commentaire, je tiens a préciser que même si ca ne se voit pas, cet article est digne d'intérêt !
Ceci dit une "page" compilatoire reprenant l'intégrale de cette saga de cryptage de portable ne serait pas du luxe pour celui (ou celle) qui voudrait tout refaire depuis le début.

C'est + ca moi que j'dis !

LUKSfile for dummies - Swâmi Petaramesh

Swâmi Petaramesh — Sun, 20 Apr 2008 19:32:27 +0200

@Salan : Bonjour,

Je n'ai en effet pas initialement prévu le sctipt pour une utilisation sur des containers en lecture seule.

Vous pouvez essayer (je n'ai pas testé, donc je ne garantis pas) de copier votre script "lfd" sous le nom "lfd-ro" pour vous en faire "un qui marche en lecture seule" et faire les modifs suivantes (à vue de nez)

A partir de la version 0.97 du script:
Ligne 823, ôtez « -a -w "${cfile}" » du test
Ligne 1237: idem
Ligne 1493, ôtez « -a -w "${cdir}" » du test
Ligne 682, juste après "luksOpen", rajoutez le paramètre « --readonly »
Lignes 942 et 944, juste après "-o ", rajoutez « ro, » en ne laissant pas d'espace entre « ro, » et l'option qui suit.
Ligne 900, remplacez "-p" par "-n"

Avec ces modifs, ça a une bonne chance de marcher. Vous utiliserez le script "lfd-ro" et non plus "lfd" pour monter vos volumes en lecture seule.

LUKSfile for dummies - Salan

Salan — Sun, 20 Apr 2008 19:00:21 +0200

Bonjour. J'utilise votre script depuis quelques temps et je le trouve fort pratique. Merci beaucoup. Comme ceux-ci devenaient encombrants, j'ai commencé à graver des containers cryptés sur CDROM. Hélas, lorsque j'essaie de les monter par "lfd /media/cdrom/test on", j'ai un message me disant que " Le répertoire '/media/cdrom' n'existe pas ou n'est pas accessible en écriture !"... ce qui est vrai ;-) N'y a t-il pas moyen de monter dans ce cas le volume en lecture seule ? Je vais essayer de me plonger dans votre script... mais je ne suis pas très doué ;-)

Merci d'avance et merci d'avoir mis ce script en ligne.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Sun, 02 Mar 2008 23:11:22 +0100

Un commentaire supprimé ci-dessus pour l'ensemble des raisons suivantes :

Sans lien avec le sujet du billet.
Sans lien avec la conversation du fil de commentaires.
Provenant d'un commentateur encore inconnu ici et indiquant comme pseudonyme le nom correspondant à un site.
Commentaire visant simplement à attirer vers la visite d'un site d'opinion tiers.

Quel que soit l'intérêt que présente ou non le site qui était l'objet de ce lien, je rappelle à son auteur que le fil de commentaires d'un blog n'est pas un panneau d'affichage public ou chacun, inconnu, peut se permetttre de débarquer dans le seul but de balancer un lien vers tel ou tel site, telle ou telle cause ou telle ou telle campagne.

En conséquence, je considère et traite ce commentaire comme un simple spam, je le dégomme donc.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Sun, 02 Mar 2008 09:45:19 +0100

@Westmalle : Ah voilà! Je parle de la tête de tes commentateurs-trices, et tout de suite toi c'est les seins que tu veux voir?! : )

C'est juste mon naturel d'irréductible vieux satyre qui revient au galop ;-)

Another brick in the wall - Westmalle

Westmalle — Sun, 02 Mar 2008 09:21:32 +0100

@ swâmi : Ah, j'ai bien cru qu'à force de persuasion je finirais par avoir la photo tant attendue des seins d'Agathe ou de Sarah, mais j'ai pu me brosser, ballon !

Ah voilà! Je parle de la tête de tes commentateurs-trices, et tout de suite toi c'est les seins que tu veux voir?! : )

Pour ce qui est des "connaissances", ceux qui sont le plus susceptibles de vouloir intercepter du mail : "services" divers, employeurs... ont le plus souvent les moyens de le faire.

Merci pour toutes ces explications, j'aime comprendre comment les choses fonctionnent et tu as un vrai talent pour rendre les choses claires, et la patience d'écrire de long messages. ça m'a toujours épatée et ravie à la fois!

Je vais dès la semaine prochaine prendre quelques mesures et me renseigner plus précisément auprès de l'administrateur au boulot.

Merci! Merci! Merci!

Another brick in the wall - wastedtime

wastedtime — Fri, 29 Feb 2008 17:04:29 +0100

@Christine
Dans le même style, on a aussi la loi Olivennes en projet.
lire l'interview instructive d'un membre de eucd.info
En gros, ce ne sera même plus des képis qui sauront tout de ta vie, mais des gentils gars du privé, c'est quand même plus rassurant quand il n'y a pas d'uniformes. On arrête pas le progrès...

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Fri, 29 Feb 2008 14:23:34 +0100

@Ga(i)elle : L'aspect informatique de l'adultère est en effet l'un de ceux nécessitant des précautions particulières :-}

Another brick in the wall - Ga(i)elle

Ga(i)elle — Fri, 29 Feb 2008 14:14:49 +0100

@ Swâmi et Christine : En fait je parlais des deux, une phrase chacun (à écrire trop vite on devient sybillin... Je comprends mieux pourquoi beaucoup de monde croit que sybillin veut dire court, laconique, blitz) !

Donc confirmation que c'est hyper pas pratique de chiffrer directement sur les interfaces de webmail de ce style... voir infaisable pour moi. Ok.
Quand à Thunderbird, je ne l'ai jamais utilisé. J'ose espérer qu'il est meilleur que l'Outlook express dont je disposais à l'époque où mes mails auraient du être bien cachés... et qui s'ouvrait d'office sous ma session ! 'foiré, m'a bien pourri la vie, çui-là. Une séparation qui s'annonçait délicate mais potentiellement "douce" est devenue une vraie galère pendant les mois de cohabitation forcée, chantage affectif, grève du sexe (mais bon...), surveillance permanente avec limite bracelet électronique, la totale. Saleté de "client de messagerie à la con". :o)

Another brick in the wall - Christine

Christine — Fri, 29 Feb 2008 13:56:17 +0100

Les allemands vont avoir une loi autorisant les perquisitions "en ligne". Seulement en cas de projets d'attentats terroristes ;-D Et la police aura pas le droit d'exploiter les données relatives à la vie privée...

La France a un peu de retard mais ça vient. Avec des dispositifs d'écoute permanente. Mais juste pour les pédophiles et les terroristes ;-D

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Fri, 29 Feb 2008 13:33:33 +0100

@Patrick : J'ai rapidement survolé l'abstract en anglais de l'attaque, qu'ils disent effectuer sans matériel particulier sauf une bombe d'air comprimé (faut quand même donc désosser le portable sous tension pour arroser la RAM...) et ils disent ensuite rebooter le bazar sur un device externe (qui doit juste contenir un programme bootable qui effectue un dump sauvage de la RAM).

On peut envisager une protection simplissime contre ça : Coller un mot de passe au BIOS et configurer celui-ci pour qu'il ne boote que depuis le disque dur interne (ce que je fais toujours sur mes machines). Bon, on peut toujours faire péter le mot de passe d'un BIOS (en enlevant la pile), mais ça nécessite de laisser la machine hors-tension suffisamment longtemps pour que sa mémoire CMOS désalimentée "oublie", ce qui prend de plusieurs ordres de grandeur plus longtemps qu'il n'en faudra à la RAM pour alzheimer totalement.

Une autre idée à creuser : Les BIOS modernes sont tous par défaut réglés avec des options "Quick boot" ou "Disable memory test at boot", pour booter plus vite. Mais si l'on met le BIOS en mode "Full memory test", il se paluchera la vérification de toute la RAM avant de booter la clé USB des méchants. Reste à s'assurer que le test (rudimentaire) en question est bien en lecture/écriture sur la mémoire et non pas en lecture seule ; ça doit dépendre des BIOS. M'enfin, celui qui paranote sur cette attaque et est prêt à sacrifier plusieurs minutes de test mémoire à chaque boot peut toujours activer cette option.
les vilains seraient bien marrons avec cette protection à deux balles de voir la machine rebootée :

Commencer par vider consciencieusement sa RAM d'un grand coup de test mémoire ;
Refuser de booter leur clé ou CD bidule, booter l'O.S. d'origine (écrasant donc au moins en partie ce qui pouvait rester de contenu précédent éventuel)

...et ne leur laisser d'autre choix que de dégager la pile de la carte mère machine éteinte (juste le temps qu'elle oublie mille fois tout...), ou de chercher un moyen encore plus tordu pour accéder au système...

Bon, enfin, si on n'a que cette attaque-là à opposer au chiffrement de disque, je crois que je dormirai encore ce soir...

> moins on aura confiance dans ces machines, moins on leur confiera de choses, et donc moins elles serviront de vecteur aux "intrusifs"

Mouais. En même temps, nous avons tous des informations plus ou moins "confidentielles" à stocker, notamment grâce à l'explosion de l'usage d'identifiants / mots de passe pour tout et pour rien... Faut bien les stocker quelque part...

Si les groméchants débarquent, où donc les données seront-elles le plus en sûreté ? Dans un disque dur chiffré dont le chiffrement peut éventuellement peut-être être circonvenu par des méthodes ultra-techniques capillotractées, ou écrites noir-sur-blanc dans un carnet dans le premier tiroir du bureau ?

Se méfier de l'informatique et des risques qu'elle fait courir est sage. Mais il ne faut pas laisser le FUD nous détourner de l'usage de méthodes qui seront, pour la plupart des gens, considérablement plus sûres que toute autre méthode alternative à base plus "traditionnelle"...

À moins de vouloir devenir un champion de la mnémotechnique capable d'apprendre l'annuaire du téléphone par coeur, et de tout garder au chaud dans le ciboulot... Mais y'a pas de backup, et la corruption de données peut aisément s'y produire ;-))

Another brick in the wall - Patrick

Patrick — Fri, 29 Feb 2008 12:49:46 +0100

@Swami : "largement excessif" je m'en doutais un peu mais j'ai pas résisté au plaisir de te lire sur le sujet ;o)

N'empêche : ils cherchent, ils cherchent... en même temps, ça pourrait avoir un "effet de bord" rigolo (j'y crois pas mais ça me fait marrer) : moins on aura confiance dans ces machines, moins on leur confiera de choses, et donc moins elles serviront de vecteur aux "intrusifs" amateurs de nos vies privées. Au rythme où sortent les lois qui s'intéressent à nos ordinateurs, on ne leur confiera plus grand-chose. Dossiers de travail, courriers, suivis bancaires... toutes choses devenues trop sensibles pour être livrées à des machines que le premier képi venu peut "ouvrir". Celles-ci vont très vite revenir au niveau d'utilité des calculettes, mais en nettement plus cher. On devrait donc pas tarder à les débrancher :o)

A défaut, on fera donc la révolution à coup de barricades et de pavés, et on s'enfuira de Paris, assiégé par les Versaillais, en mobylette :o)))

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Fri, 29 Feb 2008 12:15:18 +0100

@Patrick : Oui, on peut trouver des angles d'attaque contre n'importe quoi... Cela dit, la méthode proposée ici repose sur la saisie d'un système sous tension et disques actuellement déverrouillés, clé de chiffrement présente en mémoire. Elle est donc inapplicable à un système éteint ou un disque dur ou clé USB chiffré, etc., saisi isolément, ce qui en limite singulièrement la portée.
De plus la méthode proposée est particulièrement capillotractée et est à mon avis très aléatoire - on a peut-être pu le faire en labo comme "proof of concept", ce qui ne signifie pas que cela soit couramment applicable dans la "vraie vie", il est par exemple possible que ça ne marche que dans un très faible pourcentage de cas, dépendant du type de la machine et de sa mémoire, de la manière dont on compte la rebooter sans en affecter la mémoire vive (nécessité de remplacer le BIOS à la volée ?), etc...

Dans la vraie vie, il faut pouvoir saisir une machine sous tension (imaginons un portable) et la maintenir sous tension (durée de la batterie ? disposition d'un chargeur adéquat ?) le temps de la transférer à un labo adéquat disposant du personnel compétent, du nécessaire de bricolage, du BIOS de remplacement... Bref faut vachement préparer le coup, plus la nécessité de traficoter l'électronique sous tension, ce qui est toujours aléatoire... et espérer que le coup marche... Si ça ne marche pas, y'a pas de deuxième chance.

Si les vilains enfoncent ta porte, ça peut toujours te laisser le temps d'arracher la prise de courant de la machine sur laquelle tu es en train de travailler, et là, l'attaque, c'est ballon.

Il faut peut-être quelques dizaines de secondes à la mémoire vive pour perdre totalement ses données, mais il ne faut que quelques millisecondes pour que celles-ci soient gravement et aléatoirement endommagées dès que son rafraîchissement cesse, ce qui limite extrêmement les chances de pouvoir y localiser et récupérer une clé de chiffrement complète et en bon état.

J'ai donc de gros doutes, d'autant que des systèmes de chiffrement de disques sont capables de refermer automatiquement (timeout) un disque chiffré qui n'a pas été accédé depuis "n" minutes et d'effacer la clé, ce qui serait susceptible de contrer cette attaque saugrenue...

Bref, que cela puisse fonctionner dans quelques cas précis (ou comme "proof of concept") est possible ; que l'on en déduise de manière générale que "le chiffrement des disques durs est cassé" est largement excessif.

Another brick in the wall - Patrick

Patrick — Fri, 29 Feb 2008 11:45:27 +0100

ça s'arrange pas, dites voir...

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Fri, 29 Feb 2008 10:19:53 +0100

@Christine : Il me semble que Ga(i)elle ne parle pas d'utiliser un compte avec Thunderbird mais directement avec un "webmail" de fournisseur.

À noter que le mot de passe général de Thunderbird protège les mots de passe stockés dans Thunderbird, et donc l'accès aux serveurs par ce biais, mais s'il protège l'accès aux mails via Thunderbird, il ne les chiffre pas pour autant. Autrement dit, en allant directement taper dans les fichiers stockés par Thunderbird sur le disque de la machine, on trouvera les mails accessibles en clair et sans protection.

La seule méthode sûre pour protéger l'accès aux mails est de chiffrer ceux-ci.

@Ga(i)elle : si tu vas directement sur g/hot/cara/jesaispasquoi-mail.com, tu ne peux pas crypter tes mails, du coup...

Le mieux est donc de ne pas utiliser ces interfaces... Mais tu peux très bien utiliser ton compte gmail depuis Thunderbird par exemple, et pas depuis leur webmail, donc tu peux parfaitement chiffrer tes mails tout en utilisant gmail.
Les fournisseurs de "mail gratuit" qui proposent uniquement un accès webmail sont à éviter.

Dans le pire des cas, si tu n'as qu'un webmail moisi à ta disposition, tu peux toujours chiffrer, mais ça te force à la pénible tâche de devoir chiffrer ton message à la main dans un notepad par exemple, avant de le copier/coller chiffré dans la fenêtre du webmail, et de déchiffrer de la même manière. C'est lourd et chiant à faire, alors autant utiliser quand on peut un outil adapté possédant les plugins qui permettent d'automatiser ces tâches rebutantes ;-)

Si par contre on utilise un webmail "personnel" ou d'entreprise, beaucoup de webmails libres sont capables de gérer le chiffrement GnuPG en natif ou en y ajoutant des plugins. Squirrelmail ou SqWebMail peuvent le faire par exemple, avec cependant l'inconvénient qui n'est pas mince de devoir installer ses trousseaux de clés sur le serveur (ce qui pose le problème de la sécurité du serveur).

Another brick in the wall - Christine

Christine — Fri, 29 Feb 2008 09:59:40 +0100

@Ga(i)elle : dans thunderbird, tu peux mettre un mot de passe général au lancement du client. Evidemment, faut arrêter et relancer thunderbird à chaque fois que tu quittes le poste ...

Ou alors, chacun-e sa session ?

Another brick in the wall - Ga(i)elle

Ga(i)elle — Fri, 29 Feb 2008 09:52:16 +0100

Et si tu n'as pas de client de courrier, comme tu dis, si tu vas directement sur g/hot/cara/jesaispasquoi-mail.com, tu ne peux pas crypter tes mails, du coup...
Parce que pour avoir déjà utilisé ce genre de client, un autre utilisateur de chez moi pouvait facilement lire mes mails...

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Fri, 29 Feb 2008 08:26:53 +0100

@Lau (allô ?) : Eh bien, la bonne nouvelle est qu'il existe d'excellents logiciels libres qui font ça, à savoir GnuPG pour le "moteur" de chiffrement proprement dit, et différents "plugins" qui permettent de l'intégrer dans différents logiciels de courrier électronique pour en automatiser l'usage.

La deuxième bonne nouvelle est que ces outils sont faciles à utiliser une fois que tu en as compris le principe.

La moins bonne nouvelle est que le principe en est un peu complexe, donc ça nécessite une petite heure de réflexion ;-)

La très mauvaise nouvelle dans tout ça, est que pour chiffrer tes mails avec un correspondant donné, il faut que ton correspondant soit équipé des mêmes outils et sache s'en servir, et en la matière l'expérience démontre hélas que le plus difficile est toujours de convaincre ses correspondants de ses sortir les doigts des fesses et de s'y mettre aussi.

Pour comprendre le principe fondamental du chiffrement, une page de référence reste celle-ci. Elle est cependant très ancienne et obsolète sur les détails (notamment versions de logiciels utilisés), mais elle reste à lire avant toute chose pour comprendre le principe de fonctionnement du truc.

Pour les logiciels, la bonne nouvelle est que si tu es sous GNU/Linux, la plupart des logiciels nécessaires sont disponibles dans toutes les bonnes distributions, et la plupart du temps déjà installés sur le système.

Sous Windows, le plus simple est d'installer le "kit complet" gpg4win qui englobe à la fois le "moteur" GnuPG et des utilitaires annexes.

Si tu utilises Thunderbird comme client de courrier, il suffit d'installer ensuite dedans l'excellent plugin Enigmail, et tu peux alors effectuer toutes les opérations nécessaires (y compris la génération et la gestion des clés) depuis Thunderbird/Enigmail.

Je dirais donc que la méthode la plus simple pour passer au chiffrement (pour un Windowsien) est de :

Lire la doc de base
Utiliser Thunderbird comme client de courrier.
Installer gpg4win et ne plus s'en préoccuper une fois installé (sauf dans un deuxième temps, éventuellement) (ou installer une version légère toute nue de GnuPG).
Installer le plugin Enigmail de Thunderbird
...puis tout faire à partir de là.

Fastoche, non ? ;-)

Another brick in the wall - Lau

Lau — Fri, 29 Feb 2008 01:02:16 +0100

Ben euh... alors concrètement, quand on n'y connait rien? comment fait-on pour tout de même mettre ses cartes postales dans une enveloppe? :-) (désolée d'être aussi manchotte...)

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Fri, 29 Feb 2008 00:18:51 +0100

@Westmalle : Quand tu publies des photos de tes heureuses vacances, je me dis parfois que tu n'es pas à égalité avec tes commentateurs dont tu ne connais pas la tête pour la plupart ...

Ah oui, ô combien cette inégalité est cruelle et profonde, mais pas uniquement picturale quand je m'étale comme un Flanby démoulé sur certains aspects de ma vie très privée - d'ailleurs j'hésite ces derniers temps, mais il faudra que j'y revienne, ce blog est décidément devenu bien trop politique alors que ce n'en était pas du tout l'objet initial, comme son nom l'indique...

Mais il me faut par contre reconnaître que les rencontres que je fis de commentateurs ou -trices ou coblogueurs ou gueuses furent humainement riches et réconciliatrices avec le genre humain...

> Allez, ça laisse place à l'imagination!! : ) et là tout un univers fantasmatique s'ouvre à toi!

Ah, j'ai bien cru qu'à force de persuasion je finirais par avoir la photo tant attendue des seins d'Agathe ou de Sarah, mais j'ai pu me brosser, ballon ! Je sens cependant que tu t'apprêtes à corriger cette insoutenable et frustrante injustice ;-))

> En gros, si j'ai bien tout compris il y une possibilité que l'ensemble des mails soient lus du fait qu'ils transitent par différents points, et qu'il n'y a rien à y faire à part crypter ses messages...ou compter sur le fait qu'ils n'ont pas que ça à foutre..

Voilà. Contrairement à une carte postale qui chemine physiquement sans être recopiée, un e-mail donné transite par copies successives par (généralement au minimum, souvent plus) 5 machines :

Le PC de l'expéditeur
Le serveur mail SMTP du F.A.I. (ou de l'entreprise) de l'expéditeur
Le serveur mail SMTP du F.A.I. (ou de l'entreprise) du destinataire
Le serveur boîtes-aux-lettres (POP, IMAP...) du F.A.I. (ou de l'entreprise) du destinataire
Le PC du destinataire

Sachant que les "serveurs" aux différents niveaux sont le plus souvent des pools ou des cascades de plusieurs machines pour tous les organismes ou F.A.I. d'une certaine importance, le mail peut donc bien souvent transiter par 5 ou 6 serveurs entre l'expéditeur et le destinataire, souvent dans des pays différents et dépendant de législations diverses même si l'expéditeur et le destinataire semblent géographiquement proches.

Les mails transitent en clair d'un serveur à l'autre (souvent d'un bout de la planète à l'autre) dans la majorité des cas (les serveurs sont susceptibles de chiffrer les échanges entre eux, mais bien peu le font - et jamais ceux des F.A.I. "grand public") et sont dans tous les cas stockés en clair sur les disques des serveurs.

Quand ils transitent en clair (un bon 95% des cas), ils peuvent être "sniffés" en chemin sur n'importe quel routeur ou équipement réseau intermédiaire - c'est le genre de chose que font Échelon ou des outils comme Carnivore (U.S.) dont l'équivalent existe aussi chez nous, "on n'est pas plus cons que les autres".

Les serveurs se transmettent une copie des messages, et en théorie détruisent leur propre copie dès que le message a été transmis au relais suivant, mais rien ne les empêche de conserver copie des mails qu'ils transmettent (dans des "fichiers d'audit" par exemple) ou de transmettre des copies supplémentaires invisibles à des "destinataires non prévus" (rappelons que désormais en France la police n'a plus besoin d'un mandat judiciaire pour mettre en place le cas échéant une surveillance des mails d'un individu donné...).

Les mails demeurent enfin sur le serveur "boîte aux lettres" plus longtemps que sur les autres - jusqu'à ce que le destinaire l'ait relevé et supprimé. A ce stade ils sont très susceptibles d'atterrir aléatoirement sur des supports de sauvegarde conservés parfois sans limitation de durée - typiquement, une entreprise sauvegarde le contenu de ses serveurs chaque nuit et expédie périodiquement des sauvegardes "hors-site" où elles peuvent être archivées indéfiniment... avec les mails qui se trouvaient sur le serveur au moment où la sauvegarde a été faite.

> ou encore, je l'espère, que ce n'est pas à la portée de tout le monde, faute d'accès ou de connaissances suffisantes...

Il faut déjà, comme pour une carte postale, être "dans le circuit". Autrement dit, la boulangère a peu de chances de pouvoir lire ta carte postale, mais le facteur ou ton concierge en ont davantage. ...ou celui qui glisse un billet au concierge.

Et ceux qui veulent intercepter un mail donné et en ont les moyens techniques peuvent le faire bien plus facilement que pour une carte postale : une analyse et un tri automatique sont possibles, une copie est instantanée... Intercepter des cartes postales nécessite un travail humain (interception physique, lecture humaine, prise de copie...) à chaque étape. intercepter du mail peut être entièrement automatisé.
Pour ce qui est des "connaissances", ceux qui sont le plus susceptibles de vouloir intercepter du mail : "services" divers, employeurs... ont le plus souvent les moyens de le faire. Ta petite nièce non, mais tu n'as pas grand-chose à redouter d'elle...

Another brick in the wall - Westmalle

Westmalle — Thu, 28 Feb 2008 23:50:34 +0100

J'en veux ! J'en veux ! ;-)

: ) Quand tu publies des photos de tes heureuses vacances, je me dis parfois que tu n'es pas à égalité avec tes commentateurs dont tu ne connais pas la tête pour la plupart ...

Allez, ça laisse place à l'imagination!! : ) et là tout un univers fantasmatique s'ouvre à toi!

Si ça reste dans l'entreprise, c'est à la merci de l'éthique de l'administrateur systèmes

Là dessus je suis pas trop inquiète, pour avoir un peu discuté du sujet avec l'ingénieur informatique des services. Aucun doute sur son intégrité.

Sur l'aspect légal, je n'avais pas de doute (le fameux arrêt Nikon si mes souvenirs sont bons), mais c'est bien sur l'aspect technique que se situaient mes interrogations. En gros, si j'ai bien tout compris il y une possibilité que l'ensemble des mails soient lus du fait qu'ils transitent par différents points, et qu'il n'y a rien à y faire à part crypter ses messages...ou compter sur le fait qu'ils n'ont pas que ça à foutre..ou encore, je l'espère, que ce n'est pas à la portée de tout le monde, faute d'accès ou de connaissances suffisantes..

Quant aux ministères qui n'acceptent pas les messages cryptés ; et bien je dirais .. euh.. tous?

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Thu, 28 Feb 2008 21:16:41 +0100

@Westmalle : les mails, de simples cartes postales s'il ne sont pas cryptés? Alors passe encore pour ma correspondance privée ( encore que.. bon, je vais arrêter d'envoyer des photos de soirées par mail moi..)

J'en veux ! J'en veux ! ;-)

> mais professionnellement j'utilise régulièrement la messagerie , pour transmettre un courrier à un collègue, répondre à un salarié etc..

Si ça reste dans l'entreprise, c'est à la merci de l'éthique de l'administrateur systèmes qui est la seule barrière qui l'empêche de lire ton courrier... modulo les pressions éventuelles qu'il pourrait subir.

> Et là j'éprouve comme une petit fond d'angoisse sur le respect du secret...

Si c'est "de ton boulot vers un salarié d'une autre entreprise", c'est en plus à la merci de tous les intermédiaires techniques (qui d'un autre côté n'ont pas que ça à foutre de lire les mails des gens), des services d'interception automatisés (Échelon) pour tout mail franchissant la frontière d'un pays de l'alliance UKUSA, et surtout et aussi de la discrétion (ou pas) des administrateurs systèmes de l'entreprise du salarié concerné.

La législation française interdit la lecture du courrier personnel d'un salarié dès lors qu'il est identifié comme tel, mais c'est une tarte à la crème puisque n'importe qui peut lire un mail sans s'en vanter pour autant (simplement, il ne pourra pas y faire référence, par exemple en justice, sans dévoiler qu'il a commis un délit...) et d'autre part, le mail que tu envoies à machin@grosseboîte.com qui est à deux kilomètres de ton bureau peut très bien faire le tour du monde avant de lui parvenir, et passer par des serveurs hors-France d'une entreprise, là où ces serveurs et personnels ne sont absolument pas soumis aux restrictions de la législation française.

Quand de mon domicile j'écris à mon épouse à son bureau, à 2 km de la maison, le mail passe par un serveur d'un pays tiers de la communauté Européenne.

Si tu m'écris à mon bureau, le mail passe par un serveur aux USA, et la "policy" de la société U.S. indique clairement que le mail des employés peut être "monitoré" et l'est effectivement par des "robots". Une société dont le siège et les serveurs principaux sont à l'étranger et qui a des filiales dans d'autres pays traite les mails à son siège selon la législation qui y est applicable (au mieux). Crois-tu qu'ils configurent leur bazar différemment pour tenir compte de la législation locale applicable à Jean Dupont qui est en France, José Sanchez en Espagne, Roberto Spaghetti à Milan ou Willem Bidulus à Amsterdam ? Ça serait beaucoup trop compliqué, et puis ils s'en tapent. Si la législation locale permet aux shadoks de pomper, ils pompent...

(Note que si tu envoies en France des mails chiffrés à des employés de certains ministères [devine lesquels], leur serveur mail te les renvoie dans la poire avec un message poli t'indiquant que les mails chiffrés avec ce ministère ne sont pas autorisés, contactez le service de la sécurité, blabla...)

@Ko : Foin de justifications oiseuses comme les obligations professionnelles, hein : si tu fais un taf qui suppose que t'ailles aux Staïtes, y a de fortes chances que tu ne mérites pas ma compassion...

À chaque fois que j'ai été aux zuhessas, ça a été pour raison professionnelle, la prochaine fois sera probablement également le cas.

Quand tu cherches du boulot, s'il te fallait en plus exclure toutes les sociétés américaines, multinationales, et coller ta démission le jour où ta p'titboîte franchouille est rachetée par grossboîte ricaine...
Ça, à mon avis, ça ne ferait pas une "raison valable" pour Jacquouille qui veut saquer le chômiste ayant refusé deux "offres d'emploi acceptables"...

Another brick in the wall - ko

ko — Thu, 28 Feb 2008 20:55:36 +0100

Va bientôt falloir y aller à poil avec une main devant et une main derrière, passeport biométrique tenu entre les dents...

Ou, comme dit Christine, ne PAS y aller.

(Foin de justifications oiseuses comme les obligations professionnelles, hein : si tu fais un taf qui suppose que t'ailles aux Staïtes, y a de fortes chances que tu ne mérites pas ma compassion... ;-)))

Ça me rappelle un roman de Norman Spinrad, Le printemps russe, dans lequel les zétazunis sont décris comme sclérosés et totalement refermés sur eux-mêmes (au propre comme au figuré...)

Another brick in the wall - Westmalle

Westmalle — Thu, 28 Feb 2008 20:53:57 +0100

Wahou. J'avoue que je tombe des nues... les mails, de simples cartes postales s'il ne sont pas cryptés? Alors passe encore pour ma correspondance privée ( encore que.. bon, je vais arrêter d'envoyer des photos de soirées par mail moi..) mais professionnellement j'utilise régulièrement la messagerie , pour transmettre un courrier à un collègue, répondre à un salarié etc..

Et là j'éprouve comme une petit fond d'angoisse sur le respect du secret...

Merci de cette info je vais potasser un peu le sujet là.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Thu, 28 Feb 2008 19:42:13 +0100

Ben, pour le boulot, on peut parfois être obligé...

Et si ça doit de nouveau m'arriver, je peux t'assurer que j'irai avec un disque vierge et un système fraîchement réinstallé dessus... J'ai lu récemment chaipusoù la navrante histoire d'un cadre qui s'est fait pécho à l'immigration U.S. avec 3 photos pornographiques dans le cache de son navigateur (même pas des trucs particulièrement crades apparemment), et qui s'est vu non seulement refuser l'entrée, mais maintenir plusieurs jours en "rétention" dans les conditions qu'on imagine et juger pour "importation illicite de matériel pornographique".

Une photo de cul parfaitement légale sur ta machine quand tu entres aux U.S., et tremble carcasse, car il est illégal de passer avec !

Comme même des fichiers "supprimés" peuvent te mettre dedans et qu'on ne sait jamais ce qu'il peut y avoir dans le cache d'un navigateur (avec des sites pourris qui ouvrent automatiquement des fenêtres publicitaires sur d'autres)... ou si tu empruntes un portable "boulot" qui a été utilisé par quelqu'un d'autre avant dont tu ne sais pas ce qu'il a pu faire avec ni ce qu'il a pu stocker dessus... Mais à l'entrée des zuhessas, c'est pour tes pieds à toi que ça risque d'être chaud...

Pas intérêt non plus de passer avec le container chiffré de tes mots de passe de toute sorte, parce que tu as alors le choix entre refiler toutes les clés de ta vie virtuelle aux gabelous, ou rester coincé dans le filtre à l'aéroport...

Va bientôt falloir y aller à poil avec une main devant et une main derrière, passeport biométrique tenu entre les dents...

Another brick in the wall - Christine

Christine — Thu, 28 Feb 2008 19:16:22 +0100

Quel besoin d'entrer sur le territoire des USA, aussi ? ;-))

Another brick in the wall - Patrick

Patrick — Thu, 28 Feb 2008 19:12:37 +0100

Il faut coopérer, car le refus de fournir un mot de passe ou de faciliter l’accès peut aboutir à un refus d’entrée sur le territoire des USA. Bon, bin, l'auto-dénonciation, c'est déjà en route...

Another brick in the wall - jardin

jardin — Thu, 28 Feb 2008 03:07:02 +0100

Je me rassure en me disant qu'une texte intelligent est incompréhensible pour la police de la pensée.:

Hélas, LeFaun, je crains que tu ne te fasses des illusions, zont recruté des cerveaux, je le crains, des "science sans conscience", yen a à la pelle de nos jours. Le pire, c'est que ça cumule avec ceux qui sont cons, et qui, l'oeil suspicieux, voient du terrorisme dans une bombe glacée.

Another brick in the wall - ko

ko — Thu, 28 Feb 2008 01:21:15 +0100

Suffit d'écrire en bas-moldave pour qu'un citoyen lambda n'y entrave que pouic, en même temps. ;-/

Another brick in the wall - Patrick

Patrick — Wed, 27 Feb 2008 23:32:46 +0100

Voilà une bonne idée, que j'y avais même pas pensé* : devenir plus intelligent que les cons. Faudra faire attention tout de même à ne pas trop les vexer, après. On ne sait jamais comment ça peut être revanchard, un con. Y'a qu'à voir, déjà... :o)

(*c'est dire si j'ai du boulot pour y arriver.)

Another brick in the wall - LeFaun

LeFaun — Wed, 27 Feb 2008 20:04:08 +0100

Je me rassure en me disant qu'une texte intelligent est incompréhensible pour la police de la pensée.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 19:51:07 +0100

@Jean : pierre torris a de bons logiciels

En la matière, je ne ferais confiance à aucun logiciel qui ne soit pas open source, qui n'utilise pas des algorithmes éprouvés et n'ait pas été soumis au "peer review" pendant une durée suffisante...

Je n'ai rien contre ce monsieur, mais des petits Freewares pour Windows utilisant des algos maison, très peu pour moi.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 19:48:19 +0100

@Nico : Note: le serveur m'a refusé ce commentaire, je reposte ...

Juste passé en modération par Akismet pour une raison indépendante de ma volonté...

@jean : Combien ça coûte pour recevoir la lumière divine ?

Envoie copie de ta dernière fiche d'imposition à l'ashram, et je demanderai à l'un de nos disciples de te faire un devis pour l'atma darshan ;-)

Another brick in the wall - jean

jean — Wed, 27 Feb 2008 19:43:28 +0100

pour le chiffrement facile à utiliser, pierre torris a de bons logiciels :

http://www.ptorris.com/crypto.php
http://www.ptorris.com/download.php...

Another brick in the wall - Jean

Jean — Wed, 27 Feb 2008 19:40:38 +0100

Combien ça coûte pour recevoir la lumière divine ?

Another brick in the wall - Nico

Nico — Wed, 27 Feb 2008 19:40:24 +0100

Je planque ce genre de site dans un sous-domaine et j'utilise *.ndd comme CN.

La fin de ces ennuis arrive bientôt avec Server Name Indication décrit dans la RFC3546
mod_ssl ne supporte pas encore cette fonction mais mod_gnutls si.
Niveau navigateur, Opera 9 & Firefox 2 supporte SNI.
Internet Explorer 7 uniquement sous Vista et on n'a pas de nouvelle pour Safari.

Si tu cherche de la doc la-dessus.

Reste un souci: la charge CPU.
Mais les constructueurs commencent à faire des serveurs avec des unités crypto integrés dans le CPU.

Tous en TLS en 2012 ?

Note: le serveur m'a refusé ce commentaire, je reposte ...

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 19:14:03 +0100

@Nico : Moi, je me contente d'un certif qui fait gueuler les navigateurs avec un CN différent qui ne correspond à rien, mais on s'en fout, c'est seulement pour la partie "admin", pas pour le grand public, et j'aiguille le VirtualHost SSL avec une bardée de RewriteRules...

> soit on met autant de CN (ou de AltName) que de site qu'on posséde

Ça craint dur du point de vue de la confidentialité : Tu balances alors avec ton certif la liste intégrale des domaines et sites que ton serveur héberge... S'il y en a d'assez "marqués" ou qui appartiennent à des tiers, c'est moyen-moyen...

Another brick in the wall - Nico

Nico — Wed, 27 Feb 2008 18:59:50 +0100

Oops: les 2 derniéres lignes, faire s/2/3/ merci :)

Another brick in the wall - Nico

Nico — Wed, 27 Feb 2008 18:57:56 +0100

Apache ne supporte pas les NamedVirtualHosts en SSL pour une bonne raison: La connexion SSL est établie avant que l'URL demandée ne soit fournie, le système ne saurait donc pas à quel vhost se brancher.

Non, le traitement du vhost se fait à la reception de la requete HTTP/1.1 contenant le header Host:.
Le seul veritable probléme pour les vhost en SSL, c'est au niveau du Common Name (CN) du certificat.
Il est presenté avant de recevoir la requette HTTP/1.1.

On peut s'en sortir de differente façon (suivant les cas):
Pour tout les cas:
- on peut presenter un certificat avec un CN contenant "*". C'est dangereux et aucune CA acceptera de Certificate Request avec ce genre de CN ...
Si on as uniquement des sous-domaine: style nico.ndd.invalid et damip.ndd.invalid:
- on peut presenter un certificat contenant "*.ndd.invalid". Les CA acceptent mais certain navigateurs ne supportent pas.
Si on as des domaines different: style toto.invalid et tata.invalid
- soit on met autant de CN (ou de AltName) que de site qu'on posséde: donc le navigateur reçoit le certificat de toto.invalid et de tata.invalid. C'est accepté par la plupart des CA.

Je combine les 2 derniére méthode chez moi et ca fonctionne assez bien ...
Voici le genre d'openssl.cnf necessaire:

[ req ]
default_bits = 1024
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
0.commonName = SubDomain
0.commonName_default = *.somehost.invalid
1.commonName = Another Domain
1.commonName_default = *.othername.invalid
2.commonName = Direct Access
2.commonName_default = athome.getmyip.invalid
2.commonName = For ZeroConf
2.commonName_default = *.local

Another brick in the wall - Vince

Vince — Wed, 27 Feb 2008 18:51:39 +0100

Je sais pertinemment qu'il est quasi-impossible de casser un message PGP ...
Sinon je ne m'amuserais pas à chiffrer mes correspondances très personnelles ;0)

J'aime beaucoup ton "perfectionnisme" dans les explications, et si ça peut servir à certains pour mieux appréhender la chose, c'est d'autant plus utile.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 18:15:28 +0100

@Nico : Les vhosts sous SSL avec une seule IP c'est possible.

J'ai commis quelques horreurs avec des RewriteRules très lourdes mais-qui-marchent pour la partie admin du site, mais je ne m'y suis pas risqué pour les parties "ordinaires".

Apache ne supporte pas les NamedVirtualHosts en SSL pour une bonne raison: La connexion SSL est établie avant que l'URL demandée ne soit fournie, le système ne saurait donc pas à quel vhost se brancher. Je regarderai comment tu es parvenu à contourner ce problème, c'est un truc qui m'intéresse bien ;-)

Le choix de ne pas utiliser de SSL pour la bête consultation des blogs est aussi un choix de performances : moindre charge serveur, et permettre aux proxy-caches éventuels de faire leur boulot, donc encore économie de charge serveur et de bande passante. En SSL, c'est ballon de ce côté-là, bien sûr...

J'utilise le SSL quand j'en ai besoin pour une bonne raison, mais pas pour le plaisir de monter une config usine-à-gaz ou de bouffer des ressources là où je peux en économiser ;-)

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 17:13:21 +0100

@Jardin : Tu pourrais pas nous proposer un chiffrage invisible?

Ça existe. Ça s'appelle la stéganographie, ça consiste par exemple à camoufler un message dans un fichier d'apparence autre, comme du son (.wav, .mp3...) ou une image (.jpg...) Le fichier "caché" est alors encodé comme un très faible niveau de "bruit" (sonore ou visuel) dans le fichier hôte.

Inconvénients : C'est quand même généralement détectable quand on sait ce qu'on cherche, du coup c'est "encore plus suspect", ce n'est pas forcément très efficace, ça nécessite des méthodes beaucoup plus complexes que du chiffrement ordinaire, et en plus le stockage et la transmission de volumes de données considérablement plus élevés que la "charge utile" du message (puisque le message ne peut occuper qu'une très faible proportion du fichier hôte dans lequel il est très fortement "dilué").
Bref, bof...

En plus, ça ne protège pas de l'analyse de trafic, autrement dit, il peut paraître suspect qu'Alice et Paul passent leurs journées à s'échanger des photos de nuages, forêts feuillues ou des enregistrement de radio de basse qualité (tous fichiers propices à un "haut niveau de bruit")...

Cela dit non, chiffrer un message n'a pas à être considéré comme "intrinsèquement suspect", pas plus que ne l'est le fait de mettre une lettre sous enveloppe. Quel serait le monde où celui qui mettrait ses lettres sous enveloppes serait de ce fait considéré comme suspect de vouloir camoufler des choses délictueuses à l'oeil acéré du facteur ou du flic ? On vit dans un monde qui évolue de bien étrange manière, non ? Tous transparents, sinon suspects !

Il faudrait justement que tout le monde chiffre systématiquement tous ses mails, y compris pour envoyer la dernière blague creuse à ses potes ou commander une pizza, de manière à ce que le simple fait qu'un message soit chiffré ne soit pas de nature à attirer l'attention, pas plus qu'une lettre sous enveloppe n'attire l'attention pour cette seule raison.

Personnellement, je chiffre tous mes mails avec tous mes correspondants "équipés", pour cette raison et plus simplement parce que c'est totomatique, donc pas chiant du tout à faire...

Another brick in the wall - jardin

jardin — Wed, 27 Feb 2008 16:53:23 +0100

Déjà que c'est suspect de payer en liquide, de pas avoir de carte bleue ou de se passer d'un téléphone portable, alors chiffrer ses mails, je vous dis pas!

Tu pourrais pas nous proposer un chiffrage invisible? Sinon, on ressemble au pti gamin qui, la semaine avant la fête des mères, annonce d'un air gourmand à sa môman qu'il a un secret kifopa lui dire.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 16:06:42 +0100

Eh bien... J'ai trop de travail-qui-rend-libre pour arriver à suivre votre rythme, aujourd'hui... Ce n'est plus un modeste ashram, c'est le dernier salon où l'on cause ! ;-)

...et la méditation silencieuse dans tout ça, ô disciples ?

Another brick in the wall - wastedtime

wastedtime — Wed, 27 Feb 2008 16:02:18 +0100

La constitution, celle qu'on réforme en catimini ? Celle qu'on va abroger dans pas trop longtemps parce qu'elle empêche de légiférer en rond ?
Et ensuite, ça coûte cher un parlementaire, et vu l'utilité du lot 2007 (modèle connu sous le nom de "bénît OuiOui" par les connaisseurs), on pourrait en faire l'économie. Légiferer par décret du président, ça serait le plus efficace. (cf République de Weimar)

Another brick in the wall - Patrick

Patrick — Wed, 27 Feb 2008 15:54:00 +0100

@Swami : faudrait voir à "décomplexer" un peu, mon ami. Une constitution, ça se contourne, aujourd'hui. Figers in the blaze, même que ouais !

Another brick in the wall - ko

ko — Wed, 27 Feb 2008 15:19:30 +0100

Ben dites, les gars, ça fleure bon l'optimisme, par là...

Quand je vous dis qu'il faudra en revenir aux bonnes vieilles méthodes (je vais construire un sémaphore de ce pas gaillard)

Another brick in the wall - wastedtime

wastedtime — Wed, 27 Feb 2008 15:06:48 +0100

@patrick
Il est pas sous acide mon chat! Il est juste complètement débile !
Et ce site est tel quel depuis 2003. Je ne compte plus l'updater.
Avec un peu de chance çà deviendra le nouveau perdu.com

Note anti HS: relire minority report de Phillip K. Dick
Le crime par la pensée me semble la prochaine évolution logique. Ça colle bien avec la nouvelle loi d'enfermement préventif.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 14:48:10 +0100

@Patrick : Normalement, exiger l'auto-dénonciation, c'est anticonstitutionnel.

Euh... J'ai dit une connerie ? 8~/

Another brick in the wall - Patrick

Patrick — Wed, 27 Feb 2008 14:40:45 +0100

@wastedtime : à l'arrache : ooops ! les mots qui bougent et le chat sous acide, ça m'a fait flipper grave :o)

Another brick in the wall - Patrick

Patrick — Wed, 27 Feb 2008 14:35:58 +0100

@Swami : "tant que tu ne t'auto-dénonces pas..." bin, c'est ça l'idée, justement : si tu ne te dénonces pas tu prends un max, vu que tu es "présumé coupable" du simple fait d'utiliser le chiffrement. Tout me fait penser qu'on y va bien droit, par là.

Another brick in the wall - wastedtime

wastedtime — Wed, 27 Feb 2008 14:32:34 +0100

Moi je pense qu'il faudrait obliger les OS à avoir une backdoor pour l'état. C'est quand même hashement plus simple que de légaliser le piratage et les intrusions par les forces de l'ordre (Allemagne, France, etc...) parce que bon, les terroristes qui piratent du Céline Dion et Taxi 4 avec un couteau entre les dents ça fait super peur.
(degré de ce post mod 2 = 0)
Autrement, sérieusement, le terrorisme est quand même une superbe excuse à tout. Les moutons préferent la sécurité, suivi de l'abattoir à la liberté. C'est un schéma classique de gouvernement. Ce qui me fait peur, c'est sa généralisation à l'échelle planétaire, avec un "Global Branding" Al quaida. On dirait que tous les gouvernements suivent le mouvement sécuritaire US du patriot act. Cela me fait franchement flipper. L'étape logique après est de trouver un ennemi extérieur (après l'ennemi intérieur, ici identifié comme l'internaute lambda). Qui sera cet ennemi ? Perso, je mise sur l'Iran N°1, Venezuella N°2.

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 14:29:55 +0100

@Patrick : À cela près que ton mot de passe de connexion machin est généralement (pas toujours...) connu de ton banquier, ton F.A.I., etc... Tandis que les clés de chiffrement que tu génères toi-même, tout comme tes mots de passe "locaux", sont connus de toi seul. Donc, tant que tu ne t'auto-dénonces pas... :-}

Another brick in the wall - Patrick

Patrick — Wed, 27 Feb 2008 14:09:09 +0100

Ils ont déjà accès aux mots de passe , les clés de chiffrement ne devraient pas faire long feu. Gaffe les mecs, à ce rythme, le SSL devient vite une arme terroriste entre les mains de présumés coupables...

Another brick in the wall - Nico

Nico — Wed, 27 Feb 2008 13:21:36 +0100

Les vhosts sous SSL avec une seule IP c'est possible.
J'avais commis ce memo il y a quelques mois ...
Ca marche bien pour mes sous-domaines.
Il y a une page sur les vhost ssl sur le wiki cacert contenant les differentes façon de s'en sortir avec different ndd (subjectAltName)
D'ailleurs ca me fait penser que je dois renouveller ce certif.

Another brick in the wall - vieil anar

vieil anar — Wed, 27 Feb 2008 13:14:18 +0100

@ Chrissine, arrête de m'piquer mes tics!

@ Swâmi, la drague par coms interposés, c'est sympa, genre:"@ Amazone : A ton service si tu as besoin de tuyaux ou pour faire des tests..." !! :-)).

Gare au chiffrement! A plus, comme dirait Christine! :-)

vieil anar

Another brick in the wall - Christine

Christine — Wed, 27 Feb 2008 12:27:40 +0100

Dis donc, la vaillante travailleuse indépendante, tu bosses pas beaucoup ;-))

Bon, c'est pas tout ça : pause déjeuner.

A plus comme dirait j'sais plus qui

Another brick in the wall - ko

ko — Wed, 27 Feb 2008 12:25:06 +0100

Ben moi, je vais dresser mon chat à colporter des messages. Gnîark.
Bon, ok, je vais aussi faire un élevage de pigeons, ça sera sans doute plus efficace... ;-))

Tous suspects ? Farpaitement !!!

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 12:08:01 +0100

@Amazone : À ton service si tu as besoin de tuyaux ou pour faire des tests...

Another brick in the wall - Amazone

Amazone — Wed, 27 Feb 2008 12:01:13 +0100

Dès mon retour je m'attèle au chiffrement !

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 11:41:19 +0100

@La preuve : Qu'apprend je ? Ce site n'est même pas HTTPS

Ce site est HTTPS pour les interfaces d'administration et toutes sortes d'autres choses.
Il ne l'est pas pour l'accès "consultation" aux sites qu'il héberge pour une raison technique simple mais chiante : ce serveur héberge plusieurs sites différents ayant des noms différents, et pour faire du HTTPS dessus il me faudrait autant d'adresses IP externes que de sites HTTPS. Or, je ne dispose que d'une seule adresse IP ; j'ai donc du réserver le HTTPS aux différentes fonctions d'administration et faire du HTTP ordinaire pour la consultation - les sites étant par ailleurs publics et ne comportant pas de saisie d'élément confidentiels via HTTP.

Another brick in the wall - La preuve

La preuve — Wed, 27 Feb 2008 11:28:10 +0100

Qu'apprend je ? Ce site n'est même pas HTTPS (https://www.petaramesh.org/) ?
C'est pour quand ? ;-)

Another brick in the wall - La preuve

La preuve — Wed, 27 Feb 2008 11:17:17 +0100

C'est clair qu'on essaye de nous faire croire que "tout le monde est délinquant", qu'il faut se méfier de tout le monde, et surtout de ses voisins ("vous êtes sûr que votre voisin n'est pas un dangereux terroriste ?"). Le meilleur moyen de s'en rendre compte, c'est d'observer l'expansion de la "vidéo-surveillance", en effet, qui est-ce qu'on surveille à part les coupables ? C'est "vous êtes coupable jusqu'à preuve du contraire". C'est clair qu'on peut se demander si pour nos dirigeants ce n'est pas "l'ennemi, c'est le peuple". Ça va être une hécatombe quand ils verront des ~~coupables~~ suspects partout...

Another brick in the wall - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 27 Feb 2008 11:15:13 +0100

@Vince : je crois que le chiffrement des correspondances est déjà limite hors-la-loi en France ...

Pas du tout, le gouvernement Jospin l'a libéralisé - une des rares bonnes choses qu'il ait faites - sans toutefois aller jusqu'au bout des engagements qu'il avait pris, pour cause de changement de cap et de loi LSI allant dans l'autre sens.
Mais de fait l'utilisation de GnuPG ou PGP pour chiffrer son mail est aujourd'hui parfaitement légale en France.

> Les moyens de l'Etat pourront être utilisés pour déchiffrer les messages cryptés

...Effort évalué il y a quelques années par l'un des responsables de la NSA comme représentant 10 puissance 13 fois l'âge de l'univers en temps de calcul pour "casser" un message PGP en disposant de la puissance de l'ensemble des ordinateurs en service sur la planète. À supposer qu'il ait surestimé volontairement la difficulté de quelques ordres de grandeur et que la puissance de calcul disponible ait également augmenté de quelques ordres de grandeur depuis, ça devrait laisser un peu de marge :-}

@Céleste : je n'ai pas compris ce qu'est le chiffrement du courrier électronique, faudra que tu m'expliques :-)

C'est ce qu'on appelle (improprement) "crypter" son courrier ou ses fichiers.

Rien n'est plus facile que d'espionner le courrier électronique (c'est même ce que pratique à grande échelle le réseau Échelon).
Envoyer un mail, c'est comme envoyer une carte postale que tout le monde à la poste peut lire sans que cette lecture ne soit détectable ou laisse la moindre trace.
Chiffrer son mail, c'est mettre la carte postale sous enveloppe, une enveloppe mathématique opaque et théoriquement indestructible.
Nous avons l'habitude de mettre notre courrier sous enveloppe même s'il n'est pas particulièrement "sensible ou confidentiel", il serait temps que nous prenions l'habitude d'en faire autant pour notre courrier électronique - infiniment plus susceptible d'être automatiquement lu et analysé à l'insu de notre plein gré.

Le faire est facile et ne demande qu'un poil de familiarisation avec la technique adéquate. Ne pas le faire est de nos jours irresponsable, en particulier si notre courrier peut parfois comporter des informations plus ou moins confidentielles ou privées, si l'on est militant politique ou syndical, journaliste, avocat, médecin, etc, etc.

Another brick in the wall - Jean-Pierre Martin

Jean-Pierre Martin — Wed, 27 Feb 2008 11:13:29 +0100

66542258720254500055441 !
(45656)

Another brick in the wall - Christine

Christine — Wed, 27 Feb 2008 11:10:26 +0100

Ils sont Vichy, soyons pirates

Another brick in the wall - Vince

Vince — Wed, 27 Feb 2008 11:03:08 +0100

Ouais bin ... la LCEN nous permet de chiffrer. Mais "Les moyens de l'Etat pourront être utilisés pour déchiffrer les messages cryptés".
Si on peut s'amuser à en faire chier quelques-uns qui bossent pour l'Etat...

Another brick in the wall - Vince

Vince — Wed, 27 Feb 2008 10:58:54 +0100

Heu je crois que le chiffrement des correspondances est déjà limite hors-la-loi en France ...
Vais chercher pis je tiens au jus. Je ne voudrais pas que le Guru soit mis en cause pour inciter à commettre des actes répréhensibles.

Another brick in the wall - jojozzzz

jojozzzz — Wed, 27 Feb 2008 10:28:46 +0100

Une phrase (inexacte bien sûr) me revient en mémoire (Staline ?)

"Si vous êtes encore en liberté ce n'est pas que vous êtes innocent mais c'est qu'on a pas assez cherché"

Another brick in the wall - MishaaMouche

MishaaMouche — Wed, 27 Feb 2008 10:26:30 +0100

http://philoo.blogspot.com/2008/02/... ...

Another brick in the wall - Céleste

Céleste — Wed, 27 Feb 2008 09:12:22 +0100

en Italie c'est flagrant, on contrôle, on surveille le citoyen et on laisse agir les gros poissons prédateurs;

je n'ai pas compris ce qu'est le chiffrement du courrier électronique, faudra que tu m'expliques :-)

Another brick in the wall - Patrick

Patrick — Wed, 27 Feb 2008 09:08:12 +0100

@Swami : gageons que le chiffrement du courrier ne tardera pas à être réprimé. Ce serait bien "dans la ligne", non ?

Une clé de contact pour votre portable chiffré - Swâmi Petaramesh

Swâmi Petaramesh — Wed, 06 Feb 2008 23:41:50 +0100

@Blip : Dans la note n°2, tu précises que mettre le /boot sur une clé USB (ne laissant ainsi aucune donnée non chiffrée sur le système) n'est pas compliqué à faire ; pourrais-tu donner en quelques mots la démarche à suivre ?

Ça n'a rien de particulièrement difficile : Mettre le contenu du /boot sur une clé USB, installer grub dessus comme on le ferait sur un disque dur, s'assurer que le BIOS de la machine est capable de booter depuis la clé USB et la mettre en premier dans l'ordre des périphériques de boot.

On peut dans ce cas ne mettre sur le disque dur qu'une LVM chiffrée, sans aucun noyau bootable, aucun /boot, et aucun bootloader installé...

@Mitch : C'est une technique simple du genre de celle que tu proposes que j'utilise sur mon EeePC pour avoir une carte SD chiffrée LUKS (qui équivaut conceptuellement à un second disque dur) inutilisable sans la machine, puisqu'elle n'est déchiffrable que par un fichier-clé (aléatoirement généré au départ) présent sur le portable, dans sa LVM elle-même chiffrée.
Ainsi au boot, le portable commence par faire saisir la phrase secrète de sa LVM, boote, puis déchiffre et monte automatiquement la carte SD grâce à la clé qu'il possède. Sans le portable, je suis moi-même incapable d'accéder au contenu de la carte SD.

Par ailleurs, tu exagères sur la complexité d'utilisation d'une machine entièrement chiffrée : Si tu es le seul utilisateur de la machine et que tu as tout dans une LVM chiffrée, tu peux très bien mettre un autologin utlisateur et aucun autre mot de passe à l'intérieur. Dans ce cas, tu as besoin de taper une phrase secrète pour le boot, et basta (attention quand même dans ce cas à se protéger de toute attaque via le réseau, et notamment toute tentative de passer root... Tu peux mettre un mot de passe à root le cas échéant ;-)

Une clé de contact pour votre portable chiffré - mitch

mitch — Wed, 06 Feb 2008 21:34:16 +0100

oups javais oublié de noter : sudo mkfs.ext3 /dev/mapper/openedusb pour avoir une clé usb en ex3.
Ca m'apprendra à pas assez me relire.