Si la SNCF a passé un marché avec Voyages-sncf.com pour le site de réservation, il te suffit de postuler au prochain passage de marché.
D'un autre côté la SNCF étant n EPIC non majoritairement financé par l'État (ou était un EPIC et s'en est encore éloignée), elle n'est pas soumise au code des marchés publics. Alors même si la solution proposée est moins chère/correspond mieux au cahier des charges pour un coût raisonnable/etc., pas de garantie qu'ils ne privilégient pas la filiale Voyages-SNCF.com (le contraire serait même étonnant).
Ah si tu as été clair, en gros le bouton afficher les trains suivants ne sert à rien (enfin je ne l'ai jamais vu changer quoi que ce soit).
Et vous êtes tombés sur les réservations pour un train le jour même qui expirent 3 minutes après l'avoir faite (genre réservation faite à 15h02, expire à 15h05, mail témoin) ? (<ma vie> au lieu d'une demi-heure avant le départ du train comme précédemment, où on arrivait une demi-heure avant, on prenait son billet, le train était mis en place 20 minutes avant (au moins au départ de Paris), on s'installait calmement etc. etc. Et quand on leur maile le problème, réponse "Si vous avez eu des problèmes avec l'horaire de votre train, merci de contacter le service clientèle SNCF etc. etc." </ma vie> )
d'un autre côté à 4 ans, même sans savoir nager, tu as des chances de t'en sortir sans te noyer (d'ailleurs c'est ce qui s'est passé) en t'agitant un peu. C'est comme tout les autres tests, vaut-il mieux risquer d'en sacrifier un ou bien que les trois meurent...
En l'occurrence on peut en dire plus : on peut calculer l'espérance de la durée d'exécution de cette fonction avant qu'elle s'arrête, l'écart-type de la distribution des durées d'exécutions sur plusieurs essais, etc...
Il y a eu le cas avec le tsunami en Asie : une femme au milieu de l'eau avec deux enfants, son bébé ne sachant pas nager, et son fils de quatre ans qui ne savait pas nager non plus. Elle ne pouvait pas porter les deux, elle a expliqué à son fils que ce n'était pas parce qu'elle ne l'aimait pas qu'elle devait le lâcher, etc. etc. (imaginez le gamin qui se voit abandonné par sa mère !!)
Finalement ils s'en sont sortis tous les trois :-) enfin une histoire qui se termine bien !
Exemple: si il n'a pas de parents, pas de famille, ça fait baisser le "score affectif potentiel".
Sans plaisanter dans les hôpitaux/les urgences, c'est clair que quelqu'un qui n'a pas de famille ni personne pour insister pour les soins, ben il a une espérance de vie plus faible, personne ne le niera.
Exemple : la personne âgée atteinte d'une maladie incurable que personne ne vient voir à l'hôpital eh bien elle meurt à 70 ans d'un arrêt cardiaque, sans ou avec peu de réanimation.
je pertinente. Dans les formations de secouristes (AFPS notamment) on insiste beaucoup sur la protection du sauveteur et le fait que les secours viennent pour un blessé, pas pour deux :
1) S'éloigner du danger (explosion, feu, casserole brûlante, etc.) / se protéger. S'il fait -15 et que le type a 70 ans, il ne va pas intervenir.
2) Donner l'alerte
3) Intervenir, si c'est possible (en cas d'incendie, on ne peut pas intervenir sans équipement de pompier par exemple). Rappelons-nous l'exemple d'un électrocuté d'une vingtaine d'années il y a quelques années (pas réussi à retrouver des références) : les pompiers, prévenus, n'ayant pas de matériel de sécurité pour intervenir sur les toits de trains, ligne électrique sous tension, l'ont vu mourir sous leurs yeux en 15 minutes, même si le matériel est arrivé au bout de 20...
Le principe est qu'un sauveteur utile est un sauveteur vivant.
tant pis s'il est lent (ex: /dev/urandom vs /dev/random).
Euh, ce n'est pas tout à fait vrai ça : si c'est vrai pour la génération de clefs asymétriques (qu'on ne fait pas tous les jours), pour les serveurs de signatures, les protocoles SSL, etc. où on utilise beaucoup de nombres aléatoires à usage unique (nonces ou clefs de session), la vitesse du générateur pseudo-aléatoire commence à avoir une influence importante.
C'est vrai, et il suffit de connaître
1) l'algorithme utilisé (Mersenne-Twister ou autres)
2) une suite de quelques nombres générés par l'algorithme
pour savoir retrouver l'état interne du générateur et donc être capable de prédire les nombres suivants.
C'est pour ça que les recommandations pour un usage cryptographique imposent d'ajouter en plus un "retraitement" de l'aléas généré. C'est-à-dire, appliquer une fonction de hachage sur la sortie permet d'empêcher l'utilisateur d'avoir accès à la sortie brute de l'algorithme et donc de pouvoir le prédire.
Ensuite il y a des subtilités, genre parfois il vaut mieux ne prendre que quelques bits de la sortie de la fonction de hachage, etc...
Ça peut être très intéressant l'infrastructure de tests, on peut imaginer des programmes qui retrouveraient l'état interne du générateur à partir d'aléas si on sait lequel est utilisé (et s'il n'y a pas de retraitement par une fonction de hachage).
En revanche, il est vrai que pour un usage cryptographique (à peu près le seul où il y a vraiment besoin d'aléas non prévisible) c'est délicat de tout réimplémenter de façon sûre et rapide.
Mais en matière d'anonymat/de lutte contre le piratage, comment peut-on identifier plus facilement les gens ?
je pensais que les adresses Ipv6 étaient données par /64, 64 bits permettant l'identification du client (sa box, etc.), les 64 autres pouvant être aléatoires (calculés à la connexion sur la box du fournisseur d'accès pour revenir au sujet) ?
Oui bien sûr. C'était plutôt une attaque contre la lourdeur des choses : vu le nombre de bugs parfois critiques trouvés par jour, et le nombre de virus qui traînent encore, le fait que les logiciels soient signés ne change pas grand-chose par rapport aux mises à jour automatiques, qui sont déjà la règle.
Les éditeurs n'ont aucune raison de corriger les failles mieux/plus vite qu'avant.
Conclusion ça ne peut servir qu'à empêcher les utilisateurs de faire un peu ce qu'ils veulent, et ça démolit complètement le marketing "secure".
tu prends le cas des attentats du 11 septembre, en admettant que ce soit un américain qui soit responsable, il faut être sacrément gonflé.
Pour le 11 septembre, évidemment.
En revanche dans le cas d'une backdoor éventuelle dans Microsoft : il suffit de bien cibler la personne qui est au courant à l'intérieur. Genre un chef technique assez près pour pouvoir installer du code, avec assez d'autorité pour pouvoir faire face aux questions. C'est d'autant plus facile que le développement est (en général) modulaire.
Les backdoors matérielles : idem.
Comme en plus c'est l'organisation étatique qui fournit le (micro)code à ajouter, ça ne demande pas grand-chose.
je croyais qu'il y en avait 13 et qu'ils étaient répartis un peu partout sur la planète ?
Sinon pour rappel, il avait été suggéré que l'ONU prenne la direction de la gestion d'internet (sommet de Tunis, novembre 2005). Vu l'intérêt stratégique que les USA y ont, ils n'y avaient aucun intérêt.
Tout d'abord merci pour cet article, je suis justement à la recherche de solutions de cartes à puces libres.
Juste une remarque pour préciser la protection physique des cartes à puces : est-ce que les cartes dont tu parles sont certifiées, et si oui à quel niveau ? Parce que les attaques sur les cartes à puce notamment par canaux cachés, bien que pas à la disposition de Mme Michu, sont très efficaces et accessibles en pratique (notamment ceux qui chercheraient à attaquer la phrase de passe).
bref encore une fois en matière de sécurité, contre quoi cherches-tu à te protéger ?
Si sa soigne pas et que mon medecin m'en prescrit c'est que c'est un mauvais medecin.
On n'imagine pas le nombre de placebos qui courent les rues. Enfin ce n'est pas exactement que ça ne soigne pas, ça a une même certaine efficacité mais bon...
Par exemple : un "bête" sirop pour la toux, vs un grog bien sucré, souvent peu de différence ;-)
À l'heure où le logiciel libre gagne du terrain par l'importance du côté standardisé et ouvert,
je voulais bien entendu ajouter "et surtout l'indépendance du fournisseur, gage de sécurité" Cf IBM et ses récentes annonces de déshomogénéiser son parc informatique histoire d'être sûr de pouvoir changer ce qu'il veut quand il veut.
Bon, c'est bien "joli" tout ça, mais
Est-ce que le fait que les binaires soient signés empêchent qu'il y ait des erreurs de programmation dans le programme qui est exécuté ?
Non.
Est-ce que le programme signé en cours d'exécution a les même droits que d'habitude ?
Oui. (au moins pour le moment, mais ça va durer encore plus longtemps)
Conclusion : il n'y aura pas moins de failles qu'avant, et elles ne seront pas moins exploitables (je pense aux virus).
C'est là-dessus qu'on peut communiquer : Trusted ou pas, le programme exécuté n'a aucune raison d'avoir moins de failles. Ça ne protège donc de rien face aux attaques "grand public/entreprise" par rapport aux technologies existantes (protection de pile, bit d'exécution (vieux comme l'informatique ou presque quoiqu'on puisse en penser)).
Pire, ça laisse encore plus à la merci de l'éditeur pour ce qui est de la correction de la faille ;-) À l'heure où le logiciel libre gagne du terrain par l'importance du côté standardisé et ouvert, ça tombe mal. Sans compter l'évolution constante vers les services en lignes, et la mobilité d'un même utilisateur entre plusieurs machines.
Par contre ça peut très bien servir aux DRM évidemment.
Vous avez déjà vu un algorithme cryptographique symétrique dont la clef est confiée à celui en qui on n'a pas confiance ?
Oui. Deux fois : DRM (mais tant que ça se passe en mémoire -> poubelle) et téléphone portable (GSM = chiffrement symétrique. En plus il n'y a qu'une seule clef "d'authentification"). Mais dans ce denier cas elle est dans la carte SIM où se font toutes les opérations cryptographiques évidemment.
Rappelez-vous d'Intel et son Processor-ID sur les Pentium-!!!, ça avait fait du bruit et la chose avait disparu...
Connaissez vous beaucoup de personne qui sont prêt à payer pour quelque chose qui n'existe pas encore (-> impossible d'évaluer la qualité) voir pire qui n'existera peut-être jamais (faillite) ?
à part les capitaux-risqueurs, je ne vois pas trop. Ils prêtent de l'argent pour monter des entreprises sans jamais être sûr de ce que ça va leur rapporter, mais quand ça marche c'est le jackpot (et ça compense les pertes des autres prêts qui n'ont pas marché).
(oui, quand on veut fonder une entreprise les banques sont très frileuses, surtout dans le domaine informatique quand elles n'ont pas de garantie)
En tous cas parmi les particuliers, c'est un peu difficile d'imaginer... Bon ça n'empêche pas de faire un don de temps à autre, mais ce n'est pas la même chose.
petit complément à la commande de montage :
cryptsetup luksOpen gère le côté chiffré de la chose, et crée un device virtuel dans /dev/mapper/ qu'on peut utiliser comme une partition normale (kcryptd s'occupe du chiffrement et du déchiffrement à la volée)
pour démonter : umount /dev/mapper/clef
et ensuite on ferme le device (sinon il reste accessible en clair. Et puis c'est mieux de continuer à dérouler le protocole cryptographique...)
cryptsetup luksClose /dev/mapper/clef </:i>
Et également multimedis, qui fabrique les portables à la demande pour les centres Leclerc. Ils ne précisent pas la compatibilité Linux mais le matériel est très détaillé. http://www.multimedis.fr/
Ou encore les PC portables by Surcouf, qui sont relativement chers également (et ne proposent pas de carte graphique ATI).
Sinon une liste est sur le site de detaxe.org il me semble, mais pour le moment impossible de m'y connecter.
Tu n'as pas réussi à redémarrer sur la carte SD en modifiant les disques dans grub c'est ça (en éditant la ligne de commande, et remplaçant (hd2,0) par (hd1,0) et sdc1 par sdb1 comme c'était avant) ?
C'est très bizarre que grub perde les pédales comme ça. Si tu réessayes, tente de la reconfiguration du paquet grub avant de redémarrer, avec dpkg-reconfigure.
Normalement l'installation de cryptsetup modifie les devices pour permettre le démarrage sur une partition chiffrée (ce qui nécessite également l'inclusion des modules cryptographiques dans l'initrd pour pouvoir monter la partition chiffrée). C'est étrange qu'il ait décidé de mettre /dev/sdc1 comme ça, s'il n'existait pas !!!
Sinon pour utiliser une même clef USB chiffrée sur deux PC différents, si tu utilises cryptsetup et luks on peut la monter normalement partout comme suit en ligne de commande :
cryptsetup luksOpen /dev/usb_key_dev clef #remplace clef par le nom que tu veux
qui demande la passephrase
mount /dev/mapper/clef /media/usbdisk par exemple
[^] # Re: Voyages-sncf != SNCF
Posté par khivapia . En réponse au journal sncf deux points zéro. Évalué à 3.
D'un autre côté la SNCF étant n EPIC non majoritairement financé par l'État (ou était un EPIC et s'en est encore éloignée), elle n'est pas soumise au code des marchés publics. Alors même si la solution proposée est moins chère/correspond mieux au cahier des charges pour un coût raisonnable/etc., pas de garantie qu'ils ne privilégient pas la filiale Voyages-SNCF.com (le contraire serait même étonnant).
[^] # Re: MERCIIIIIIIIII !!!
Posté par khivapia . En réponse au journal sncf deux points zéro. Évalué à 6.
Et vous êtes tombés sur les réservations pour un train le jour même qui expirent 3 minutes après l'avoir faite (genre réservation faite à 15h02, expire à 15h05, mail témoin) ? (<ma vie> au lieu d'une demi-heure avant le départ du train comme précédemment, où on arrivait une demi-heure avant, on prenait son billet, le train était mis en place 20 minutes avant (au moins au départ de Paris), on s'installait calmement etc. etc. Et quand on leur maile le problème, réponse "Si vous avez eu des problèmes avec l'horaire de votre train, merci de contacter le service clientèle SNCF etc. etc." </ma vie> )
[^] # Re: Ils embauchent !
Posté par khivapia . En réponse au journal sncf deux points zéro. Évalué à 7.
C'est une prise de conscience (?) tardive mais nécessaire...
[^] # Re: j'ai fait le test [SPOILER]
Posté par khivapia . En réponse au journal [HS] Tester les intuitions morales. Évalué à 2.
[^] # Re: Une faille ?
Posté par khivapia . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 2.
[^] # Re: j'ai fait le test [SPOILER]
Posté par khivapia . En réponse au journal [HS] Tester les intuitions morales. Évalué à 4.
Finalement ils s'en sont sortis tous les trois :-) enfin une histoire qui se termine bien !
[^] # Re: 5 patients...
Posté par khivapia . En réponse au journal [HS] Tester les intuitions morales. Évalué à 3.
Sans plaisanter dans les hôpitaux/les urgences, c'est clair que quelqu'un qui n'a pas de famille ni personne pour insister pour les soins, ben il a une espérance de vie plus faible, personne ne le niera.
Exemple : la personne âgée atteinte d'une maladie incurable que personne ne vient voir à l'hôpital eh bien elle meurt à 70 ans d'un arrêt cardiaque, sans ou avec peu de réanimation.
[^] # Re: Pertinent
Posté par khivapia . En réponse au journal [HS] Tester les intuitions morales. Évalué à 4.
1) S'éloigner du danger (explosion, feu, casserole brûlante, etc.) / se protéger. S'il fait -15 et que le type a 70 ans, il ne va pas intervenir.
2) Donner l'alerte
3) Intervenir, si c'est possible (en cas d'incendie, on ne peut pas intervenir sans équipement de pompier par exemple). Rappelons-nous l'exemple d'un électrocuté d'une vingtaine d'années il y a quelques années (pas réussi à retrouver des références) : les pompiers, prévenus, n'ayant pas de matériel de sécurité pour intervenir sur les toits de trains, ligne électrique sous tension, l'ont vu mourir sous leurs yeux en 15 minutes, même si le matériel est arrivé au bout de 20...
Le principe est qu'un sauveteur utile est un sauveteur vivant.
[^] # Re: initialisation
Posté par khivapia . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 3.
Euh, ce n'est pas tout à fait vrai ça : si c'est vrai pour la génération de clefs asymétriques (qu'on ne fait pas tous les jours), pour les serveurs de signatures, les protocoles SSL, etc. où on utilise beaucoup de nombres aléatoires à usage unique (nonces ou clefs de session), la vitesse du générateur pseudo-aléatoire commence à avoir une influence importante.
[^] # Re: Mersenne twister
Posté par khivapia . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 6.
1) l'algorithme utilisé (Mersenne-Twister ou autres)
2) une suite de quelques nombres générés par l'algorithme
pour savoir retrouver l'état interne du générateur et donc être capable de prédire les nombres suivants.
C'est pour ça que les recommandations pour un usage cryptographique imposent d'ajouter en plus un "retraitement" de l'aléas généré. C'est-à-dire, appliquer une fonction de hachage sur la sortie permet d'empêcher l'utilisateur d'avoir accès à la sortie brute de l'algorithme et donc de pouvoir le prédire.
Ensuite il y a des subtilités, genre parfois il vaut mieux ne prendre que quelques bits de la sortie de la fonction de hachage, etc...
Voir http://www.ssi.gouv.fr/site_documents/politiqueproduit/Mecan(...) pour plus de précisions.
[^] # Re: À quoi ça sert…
Posté par khivapia . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 3.
En revanche, il est vrai que pour un usage cryptographique (à peu près le seul où il y a vraiment besoin d'aléas non prévisible) c'est délicat de tout réimplémenter de façon sûre et rapide.
[^] # Re: DDOS
Posté par khivapia . En réponse au journal Le Pentagone veut pouvoir détruire tous les sites Internet qui le gênent. Évalué à 3.
cf par exemple http://damien.sauveron.free.fr/slides/ProgrammeTransversal-P(...) pour un aperçu, et puis des recherches google attaques cartes à puce, differential/simple power analysis etc.
[^] # Re: Mieux lutter contre le piratage avec IPv6 ?
Posté par khivapia . En réponse au journal L'Europe veut plus d'IPV6 et appelle à la migration. Évalué à 3.
je pensais que les adresses Ipv6 étaient données par /64, 64 bits permettant l'identification du client (sa box, etc.), les 64 autres pouvant être aléatoires (calculés à la connexion sur la box du fournisseur d'accès pour revenir au sujet) ?
[^] # Re: Information.
Posté par khivapia . En réponse au journal TCPA le retour bis. Évalué à 3.
Les éditeurs n'ont aucune raison de corriger les failles mieux/plus vite qu'avant.
Conclusion ça ne peut servir qu'à empêcher les utilisateurs de faire un peu ce qu'ils veulent, et ça démolit complètement le marketing "secure".
[^] # Re: Pourquoi faire compliqué quand on peut faire simple??
Posté par khivapia . En réponse au journal Le Pentagone veut pouvoir détruire tous les sites Internet qui le gênent. Évalué à 3.
Pour le 11 septembre, évidemment.
En revanche dans le cas d'une backdoor éventuelle dans Microsoft : il suffit de bien cibler la personne qui est au courant à l'intérieur. Genre un chef technique assez près pour pouvoir installer du code, avec assez d'autorité pour pouvoir faire face aux questions. C'est d'autant plus facile que le développement est (en général) modulaire.
Les backdoors matérielles : idem.
Comme en plus c'est l'organisation étatique qui fournit le (micro)code à ajouter, ça ne demande pas grand-chose.
Citons un exemple similaire récent : http://techno.branchez-vous.com/actualite/2007/11/seagate_de(...)
pas de nouvelles de l'enquête, comme quoi c'est assez facile de le faire discrètement...
[^] # Re: Facile !
Posté par khivapia . En réponse au journal Le Pentagone veut pouvoir détruire tous les sites Internet qui le gênent. Évalué à 2.
Sinon pour rappel, il avait été suggéré que l'ONU prenne la direction de la gestion d'internet (sommet de Tunis, novembre 2005). Vu l'intérêt stratégique que les USA y ont, ils n'y avaient aucun intérêt.
# Sécurité physique
Posté par khivapia . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 3.
Juste une remarque pour préciser la protection physique des cartes à puces : est-ce que les cartes dont tu parles sont certifiées, et si oui à quel niveau ? Parce que les attaques sur les cartes à puce notamment par canaux cachés, bien que pas à la disposition de Mme Michu, sont très efficaces et accessibles en pratique (notamment ceux qui chercheraient à attaquer la phrase de passe).
bref encore une fois en matière de sécurité, contre quoi cherches-tu à te protéger ?
[^] # Re: Wargames
Posté par khivapia . En réponse à la dépêche Légalisation riposte graduée / spyware : Le Monde.fr confirme. Évalué à 1.
On n'imagine pas le nombre de placebos qui courent les rues. Enfin ce n'est pas exactement que ça ne soigne pas, ça a une même certaine efficacité mais bon...
Par exemple : un "bête" sirop pour la toux, vs un grog bien sucré, souvent peu de différence ;-)
[^] # Re: Information.
Posté par khivapia . En réponse au journal TCPA le retour bis. Évalué à 3.
je voulais bien entendu ajouter "et surtout l'indépendance du fournisseur, gage de sécurité" Cf IBM et ses récentes annonces de déshomogénéiser son parc informatique histoire d'être sûr de pouvoir changer ce qu'il veut quand il veut.
# Information.
Posté par khivapia . En réponse au journal TCPA le retour bis. Évalué à 5.
Est-ce que le fait que les binaires soient signés empêchent qu'il y ait des erreurs de programmation dans le programme qui est exécuté ?
Non.
Est-ce que le programme signé en cours d'exécution a les même droits que d'habitude ?
Oui. (au moins pour le moment, mais ça va durer encore plus longtemps)
Conclusion : il n'y aura pas moins de failles qu'avant, et elles ne seront pas moins exploitables (je pense aux virus).
C'est là-dessus qu'on peut communiquer : Trusted ou pas, le programme exécuté n'a aucune raison d'avoir moins de failles. Ça ne protège donc de rien face aux attaques "grand public/entreprise" par rapport aux technologies existantes (protection de pile, bit d'exécution (vieux comme l'informatique ou presque quoiqu'on puisse en penser)).
Pire, ça laisse encore plus à la merci de l'éditeur pour ce qui est de la correction de la faille ;-) À l'heure où le logiciel libre gagne du terrain par l'importance du côté standardisé et ouvert, ça tombe mal. Sans compter l'évolution constante vers les services en lignes, et la mobilité d'un même utilisateur entre plusieurs machines.
Par contre ça peut très bien servir aux DRM évidemment.
Vous avez déjà vu un algorithme cryptographique symétrique dont la clef est confiée à celui en qui on n'a pas confiance ?
Oui. Deux fois : DRM (mais tant que ça se passe en mémoire -> poubelle) et téléphone portable (GSM = chiffrement symétrique. En plus il n'y a qu'une seule clef "d'authentification"). Mais dans ce denier cas elle est dans la carte SIM où se font toutes les opérations cryptographiques évidemment.
Rappelez-vous d'Intel et son Processor-ID sur les Pentium-!!!, ça avait fait du bruit et la chose avait disparu...
[^] # Re: Connaissez vous..
Posté par khivapia . En réponse au journal "Mais comment vais-je me nourrir", nous disait le milliardaire.. Évalué à 3.
à part les capitaux-risqueurs, je ne vois pas trop. Ils prêtent de l'argent pour monter des entreprises sans jamais être sûr de ce que ça va leur rapporter, mais quand ça marche c'est le jackpot (et ça compense les pertes des autres prêts qui n'ont pas marché).
(oui, quand on veut fonder une entreprise les banques sont très frileuses, surtout dans le domaine informatique quand elles n'ont pas de garantie)
En tous cas parmi les particuliers, c'est un peu difficile d'imaginer... Bon ça n'empêche pas de faire un don de temps à autre, mais ce n'est pas la même chose.
[^] # Re: Bizarre.
Posté par khivapia . En réponse au message eeepc lenny crypsetup, grup plante !. Évalué à 2.
cryptsetup luksOpen gère le côté chiffré de la chose, et crée un device virtuel dans /dev/mapper/ qu'on peut utiliser comme une partition normale (kcryptd s'occupe du chiffrement et du déchiffrement à la volée)
pour démonter : umount /dev/mapper/clef
et ensuite on ferme le device (sinon il reste accessible en clair. Et puis c'est mieux de continuer à dérouler le protocole cryptographique...)
cryptsetup luksClose /dev/mapper/clef </:i>
[^] # Re: Conversion des videos pour gagner de la place...
Posté par khivapia . En réponse au journal Cours du collège de France en ligne. Évalué à 3.
41 minutes pour l'encodage vidéo,
moins d'une minute pour la fusion de l'audio et de la vidéo.
(en utilisant les paquets de debian-multimedia.org, pentium M 1.6 GHz 2 Mo de cache)
[^] # Re: juste des liens
Posté par khivapia . En réponse au message un portable sans OS ?. Évalué à 3.
http://www.multimedis.fr/
Ou encore les PC portables by Surcouf, qui sont relativement chers également (et ne proposent pas de carte graphique ATI).
Sinon une liste est sur le site de detaxe.org il me semble, mais pour le moment impossible de m'y connecter.
[^] # Re: Bizarre.
Posté par khivapia . En réponse au message eeepc lenny crypsetup, grup plante !. Évalué à 3.
C'est très bizarre que grub perde les pédales comme ça. Si tu réessayes, tente de la reconfiguration du paquet grub avant de redémarrer, avec dpkg-reconfigure.
Normalement l'installation de cryptsetup modifie les devices pour permettre le démarrage sur une partition chiffrée (ce qui nécessite également l'inclusion des modules cryptographiques dans l'initrd pour pouvoir monter la partition chiffrée). C'est étrange qu'il ait décidé de mettre /dev/sdc1 comme ça, s'il n'existait pas !!!
Sinon pour utiliser une même clef USB chiffrée sur deux PC différents, si tu utilises cryptsetup et luks on peut la monter normalement partout comme suit en ligne de commande :
cryptsetup luksOpen /dev/usb_key_dev clef #remplace clef par le nom que tu veux
qui demande la passephrase
mount /dev/mapper/clef /media/usbdisk par exemple