La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix.
Les réponses multiples sont interdites pour les mêmes raisons.
Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses.
76,78 % des personnes sondées estiment que ces sondages sont ineptes.
La cryptographie permet la confidentialité des données personnelles et le respect de la vie privée par ceux qui ne la respectent pas ("amis", "compagnes" ;o), Etat...).
Ca permet aussi l'achat en ligne (mais ça c'est pour rire).
Au contraire la crypto c'est vachement marrant. C'est assez stupéfiant l'élégance de ces algo.
c'est triste que ca doive exister
???
Oui, c'est aussi triste de fermer à clé chez soit, et de devoir mettre un cadenas sur son vélo...
Mais la crypto c'est vachement moins pénible en pratique : les clés sont plus légères, les vérous aussi.
L'avantage de la crypto aujourd'hui c'est qu'on peut presque oublier qu'elle existe.
Bref, c'est triste que le monde ne soit pas parfait, mais la crypto c'est sympa... en plus si le monde était parfait, on ne pourrait pas chercher à l'améliorer... ce serait assez triste aussi (avoir la certitude que ton seul impact possible pourrait être un impact négatif).
Je nage en plein utopie ce matin, d'ou mon message...
Ceci-dit, je suis bien d'accord que la crypto c tres joli, les articles a ce sujet sont tjrs tres interessant, notamment dans MISC, j'aime la theorie... et j'utilise le chiffement tous les jours, sur linuxfr en https par exemple ;-)
Et puis dans un monde parfait, je ne serai pas moi-meme, avec tous mes defauts
ben de matter dlfp du boulot de facon vachement plus intime, et mettre en toute discretion des donnees strategiques sur la boite dans mes commentaires... non, aucun interet, en effet
En fait, ça n'a surtout aucun intérêt de s'authentifier en https sur un site et de le consulter en http.
Explication simple :
- on s'authentifie, on tape un mot de passe associé à un login qui est envoyé au serveur
- si le serveur confirme l'authentication, il génère un hash aléatoire, l'enregistre dans sa base de donnée, l'associant l'utilisateur concerné dans la base de donnée... et il laisse un cookie avec ce fameux hash et le nom de l'utilisateur
- lorsqu'on réaffiche une page, le serveur demande ce cookie systématiquement
Donc si on ne fait que l'authentication initiale en https, n'importe qui peut choper le cookie en sniffant le traffic http - et donc se faire passer pour l'utilisateur sniffé, après avoir dupliqué son cookie.
En résumé, l'intérêt de linuxfr en https, c'est de ne pas se faire cracker son compte.
« - lorsqu'on réaffiche une page, le serveur demande ce cookie systématiquement » et compare son contenu avec ce qu'il a en base de donné : même hash, même utilisateur => session valide.
il est conseillé de compresser au maximum avant de crypter, surtout si tu fais du OneTimePad ("clé à usage unique", seul cryptage démontré fiable mathématiquement)
Par nature fiable n'est pas mathématique. Cela ne veut pas dire grand chose un cryptage fiable.
On peut seulement démontrer: qu'à l'heure actuelle, cet algorithme est résistant et est l'un des plus sûr pour telle application et cela via les mathématiques. Cependant des failles peuvent toujours existées, et la naissance d'ordinateur quantique pourrait remettre encause pas mal de chose.
Par nature fiable n'est pas mathématique.
en l'occurence il est facilement démontrable par les math que l'OTP est incassable, quelle que soit la puissance de calcul de l'adversaire (donc même s'il possède un ordinateur quantique avec une puissance phénoménale)
http://www.wikipedia.org/wiki/One-time_pad(...)
je cite: One-time pads are provably secure, in that if all the conditions are met properly (i.e., the keys are chosen randomly, are at least as long as the message, and are never reused), then the ciphertext gives the attacking cryptanalyst no information about the message other than its length.
Mathématiquement, le otp, il est effectivement infaillible.
C'est au niveau de la mise en oeuvre dans le monde réel que c'est plus dur:
* il faut générer une vraie clef aléatoire, de la même taille que le message;
* il faut faire parvenir cette clef au destinataire de façon sécurisée avant de pouvoir envoyer le message via un canal non sécurisé
Bref:
* les armées peuvent s'en servir;
* les gouvernements aussi;
* le petit particulier qui veut commander une paire de chaussettes par internet par contre...
quand je rencontre en personne des gens, rien ne m'empeche de leur donner un petit CD/DVD sur lequel j'ai stocké d'énormes clés OTP
en compressant bien les messages textes que j'échange avec ces personnes, je peux communiquer avec eux pendant des années et plusieurs fois par jour en ajoutant une couche OTP (histoire de compliquer l'analyse de mon générateur aléatoire, et d'éviter les attaques par répétition/délétions/knownCleartext) à une couche de crypto classique
si mon générateur aléatoire n'est pas trop pourri (y'a des cartes PCI sinon), même les ordinateurs quantiques auront beaucoup de mal à décrypter tout ça (démonstration mathématique oblige)
si en + j'échange un HDD de 100 gigas avec un ami que je vois en personne toutes les semaines (ou tous les mois c'est selon), alors l'échange permanent sécurisé et en temps réel de fichiers multimédias avec cet ami n'est pas un problème non plus
(aucun problème pour se téléphoner en toute sécurité par exemple)
tout ceci est bien sûr valable pour du business et DEVRAIT être utilisé par toutes les entreprises pour leur communications passant par des réseaux extérieurs !
je le conseille aussi à ceux qui luttent contre la corruption des puissants (car dans la constitution française, comme dans d'autres, la justice/parquet/CSM dépend fortement des dirigeants politiques et de leurs amis)
Cela dit, si tu génére tes clés OTP avec un ordinateur, c'est foutu d'avance. La seule manière d'avoir un OTP secure est d'utiliser un générateur *vraiment* aléatoire. Idéalement, lancers de dés ou utilisation de certaines propriétés quantiques. Sans ça, l'OTP est vraiment un cryptage faible.
pas d'accord car j'ai bien précisé y'a des cartes PCI
cartes aléatoires spécialisées PCI qui sont en effet basées sur des phénomènes physiques aléatoires (il y a ausi des cartes mères VIA avec de tels générateurs)
mais en + il y a des phénomènes aléatoires courants comme le temps (en millisecondes ou mieux) écoulé entre 2 frappes de touche du clavier, manipulations souris, voir entre la réception de paquets provenants d'une carte réseau
c'est sur l'accumulation de ces phénomènes que se base /dev/random dans Linux (il y a un pool de ces phénomènes qui est sauvegardé lors d'un shutdown et qui bloque /dev/random quand il est épuisé)
C'est au niveau de la mise en oeuvre dans le monde réel que c'est plus dur
J'avais lu un article dans Courier International à ce propos. Un mec proposait la chose suivante:
- au début de la connexion, le chiffrage se fait par un algo classique avec clef publique/clef privée (en supposant qu'il faille au moins quelques secondes pour le casser)
- sur ces connexions, les deux parties se passent des informations pour se synchroniser
- après, la source de "one time padding" est lue à partir d'une source commune (par exemple, un satellite) qui émet des données "aléatoire" à haut débit (impossible de stocker toutes les données même durant un lap de temps court), ce qui fait qu'il n'est pas possible de connaitre les clefs OTP que si on a pu se synchroniser lors de la première étape (courte).
Bon c'est sûr qu'il faut une certaine infrastructure pour ça (un récepteur satellite), que les authorités ne veulent pas rendre possible un système quasi-inviolable...
Le point faible de ton système c'est la synchronisation.
Car il faut tenir compte de la distance parcourue par les données entre le satellite et les machines (ben oui, la vitesse de la lumière n'est pas infinie), et vu la précision demandée (probablement au moins la microseconde, peut-être moins suivant le débit dont tu parle) il faudra même faire des corrections relativistes (comme pour les GPS).
Pour une précision à 1µs près il faut connaître la distance à 300m près, on est déjà proche des limites du GPS (et il faut aussi que le satellite connaisse sa position très précisément, mais ce n'est pas le plus gros problème).
Et puis, une synchronisation par le réseau à la microseconde près ça ne doit pas être trivial non plus. Si j'en crois ntpd les trois serveur (en stratum 2) que j'ai défini comme base pour me mettre à l'heure ont des variations d'heure de l'ordre de la milliseconde (c'est déjà impressionnant!).
ben si tu cryptes pas les données que tu "caches" dans un fichier anodin, elles seront plus facilement trouvables (spécialement si ta méthode pour cacher devient connue) !
en + un fichier crypté ressemble beaucoup au "bruit de fond" d'un fichier audio/vidéeo, les 2 ayant une apparence aléatoire
Non pas du tout. Soit ton disque dur est neuf et rempli de zéros, et tes données chiffrées se verront comme le nez au milieu de la figure, soit tu disque dur a été utilisé, et les données qu'il a contenues ont un minimum de structure (des zéros en fin de clusters, par exemple), assez différentes du pur bruit binaire produit par un chiffrement.
On peut crypter des répertoires et fichiers (voire système de fichiers en entier) avec GnuPG ? Est-ce bien(TM) ? Pourquoi ?
Existe-t-il des interfaces ? (clic droit dans Nautilus/Konqueror)
Le FS peut être chiffré grâce à cryptoapi ou loop-aes. Le swap aussi.
Le noyau pré-compilé livré sur Mandrake et SuSE fait ça. On peut opter soit pour des containers chiffrés, soit pour des partitions entières chiffrées: http://openpgp.vie-privee.org/linux.html(...)
J'aimerais pouvoir chiffrer un fichier seul (pas le système de fichier) avec juste un mot de passe (pas de clé assymétrique etc).
C'est quelque chose de basique, j'ose espérer qu'il y a un truc pour faire ça qui se trouve sur la plupart des systèmes (comme on peut raisonnablement penser trouver gzip)... mais je n'ai pas trouvé.
Peut être, mais pour la cryptage du FS, je doute qu'une clef 2048 bits, ça se casse si facilement.
Mmm... il y a toujour des bugs dans les softs de cryptage, à quand un soft avec les algos prouvés mathématiquement à grand coup de méthode formelle, comme le B ?
malheureusement les clés OneTimePad sont trop gourmandes en taille pour crypter de gros FS (mais suffit largement à crypter des fichiers textes compressés comme un répertoire d'emails)
par contre il a été démontré mathématiquement que OTP est le seul algo qui peut résister à un adversaire qui possède une puissance de calcul illimité
par contre il a été démontré mathématiquement que OTP est le seul algo qui peut résister à un adversaire qui possède une puissance de calcul illimité
Vu que ce n'est pas moi qui ait fait la preuve, je ne crois plus à 100% les affirmations qu'on me donne. Les médias ont le pouvoir de faire croire se qu'il veulent, alors pourquoi ne pas faire croire ça aussi pour la crypto ?
la démonstration que OTP est incassable est vraiment très simple (il suffit de simuler un cryptage OTP à la main pour comprendre que ajouter modulo 255 un octet aléatoire jetable à un octet "en clair" donne en résultat un octet aléatoire donc complètement inutilisable par un ennemi; il faudrait réutiliser plusieurs fois ce même octet clé pour arriver à le déterminer, mais OTP signifie bien que chaque octet clé est utilisé une seule fois)
Tu trouves cette démo facilement sur le net, tu peux donc la lire !
Tu trouveras aussi sur le net la démo qui garantit que OTP est le seul algo incassable par une puissance dez calcul illimitée. Cette démo est un peu plus longue (mais compréhensible avec des maths de niveau bac science +1)
bon, c'est bien OTP, mais la clé est un peu longue donc, je viens d'inventer l'algorithme qui tue pour faire une crypto facile pour tous :
1. Crypter sont fichier avec une cle OTP
2. Ajouter la clé à la fin du fichier.
Pour décrypter, on fait un programme qui :
1. Demande le mot de passe
2. Calcule le hash md5 de la clé, en lisant la deuxième moitié du fichier
3. Vérifie que le mot de passe = le hash md5
4. Dans ce cas, décrypte la première moitié du fichier avec la clé
5. Sinon, refuse le décryptage.
Avantages énaurmes de cette méthode :
1. Les fichiers cryptés se voient facilement : ils ont un nombre pair d'octets
2. Il ne faut pas retenir toute la clé, juste son md5
3. un md5, c'est facile à retenir
4. Le cryptage OTP est le seul à garantir une inviolabilité meme avec une puissance de calcul illimitée.
C'est le sondage idéal pour poser ma question:
Connaissez-vous un organisme certifiant la clé SSL pour faire du https pour une somme modique et reconnu par tous les navigateurs (suivez mon regard) ?
La crypto c'est pas sympa pour les systèmes de fichiers non amovibles.
Enfin, surtout, c'est généralement très inutile le cryptage de FS mais je suis ouvert à tout argument contraire !
peux-tu garantir qu'un tiers (cambrioleur ou imposteur ou traitre ou...) n'aura jamais accès physiquement aux données de ton disque dur ?
je ne crois pas ...
Est-ce que toutes tes données sont sensibles au point de nécessiter un tel niveau de sécurité ?
AMHA c'est un besoin très vertical que la crypto pour les FS et qui arrive après des mesures de sécurité beaucoup plus lourdes et physiques (portes blindés, vigiles, sécurité, équipements tempest-proof...) autant qu'organisationnelles (le faible maillon humain).
sur le plan économique je préfère la solution cryptage + système d'alarme pour détecter les tentatives d'accès à la pièce de l'ordinateur quand tu n'es pas là
cette solution est pas chère et efficace: en cas d'intrusion, même si le voleur s'empare du disque dur ou en copie les données, tu es prévenu et tu peux passer la pièce et l'ordi au peigne fin pour t'assurer que des mouchards n'ont pas été déposés (tu peux même changer d'ordi au besoin)
Si ma mémoire est bonne, il y avait un projet très astucieux et bien abouti sur ce sujet. StegFS je crois. Le principe est d'appliquer la stéganographie sur un sgf afin d'en dissimuler les données considérées comme privées.
La force du système est double :
- Tout d'abord, mathématiquement, il est impossible de démontrer sur une quelconque partition de ce type qu'elle contient des données ou non.
- Ensuite, le camouflage se fait par niveau : un mot de passe peut ne dévoiler qu'un masque du sgf.
Le risque c'est que si on perd le mot de passe global, il n'y a aucune chance que vous voyiez un jour vos données de nouveau... Vous aurez beau crier, personne ne vous croira qu'il y a des données de perdues et on vous dira "prouvez le" et vous serez bien emmerdé. Mais c'est souvent le prix à payer pour une sécurité de qualité, n'est-ce pas ?
Bon j'avoue, j'ai eu un peu la flemme de chercher plus amples info sur le net donc je ne laisse pas de pointeur. C'est aussi le coté collaboratif de la chose ;)
une définition rapide du Jargon français : « Steganographic File System. système de fichiers stéganographique, qui non seulement crypte les données, mais en plus les dissimule de façon qu'on ne puisse pas prouver qu'elles sont là... » (http://www.linux-france.org/prj/jargonf/S/StegFS.html(...))
# Re: La crypto c'est sympa pour chiffrer
Posté par Jeff . Évalué à -1.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Jeff . Évalué à -1.
-------------------------------------------------------------------------------------->[]
# Re: La crypto c'est sympa pour chiffrer
Posté par iTanguy . Évalué à 5.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Jeff . Évalué à 0.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par ASpirit . Évalué à 5.
Ca permet aussi l'achat en ligne (mais ça c'est pour rire).
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Christophe Morvan (site web personnel) . Évalué à 10.
Au contraire la crypto c'est vachement marrant. C'est assez stupéfiant l'élégance de ces algo.
c'est triste que ca doive exister
???
Oui, c'est aussi triste de fermer à clé chez soit, et de devoir mettre un cadenas sur son vélo...
Mais la crypto c'est vachement moins pénible en pratique : les clés sont plus légères, les vérous aussi.
L'avantage de la crypto aujourd'hui c'est qu'on peut presque oublier qu'elle existe.
Bref, c'est triste que le monde ne soit pas parfait, mais la crypto c'est sympa... en plus si le monde était parfait, on ne pourrait pas chercher à l'améliorer... ce serait assez triste aussi (avoir la certitude que ton seul impact possible pourrait être un impact négatif).
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par iTanguy . Évalué à 2.
Ceci-dit, je suis bien d'accord que la crypto c tres joli, les articles a ce sujet sont tjrs tres interessant, notamment dans MISC, j'aime la theorie... et j'utilise le chiffement tous les jours, sur linuxfr en https par exemple ;-)
Et puis dans un monde parfait, je ne serai pas moi-meme, avec tous mes defauts
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par GCN (site web personnel) . Évalué à 0.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par iTanguy . Évalué à 3.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Anonyme . Évalué à 3.
Explication simple :
- on s'authentifie, on tape un mot de passe associé à un login qui est envoyé au serveur
- si le serveur confirme l'authentication, il génère un hash aléatoire, l'enregistre dans sa base de donnée, l'associant l'utilisateur concerné dans la base de donnée... et il laisse un cookie avec ce fameux hash et le nom de l'utilisateur
- lorsqu'on réaffiche une page, le serveur demande ce cookie systématiquement
Donc si on ne fait que l'authentication initiale en https, n'importe qui peut choper le cookie en sniffant le traffic http - et donc se faire passer pour l'utilisateur sniffé, après avoir dupliqué son cookie.
En résumé, l'intérêt de linuxfr en https, c'est de ne pas se faire cracker son compte.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Anonyme . Évalué à 0.
« - lorsqu'on réaffiche une page, le serveur demande ce cookie systématiquement » et compare son contenu avec ce qu'il a en base de donné : même hash, même utilisateur => session valide.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Nap . Évalué à 0.
y a une vraie PKI sur DLFP ????
ou tu parlais juste d'assurer la confidentialité du mot de passe ?
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par LoX (site web personnel) . Évalué à -1.
Si si ! Tu serais toi même, avec uniquement des qualités :-P
ok, ok, ... Je sors, je sors... ----------> [ ]
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par spell (site web personnel) . Évalué à 2.
Bah, non puisque toi aussi tu serais parfait, tu ne pourrais pas avoir un impact négatif. ;-)
# Re: La crypto c'est sympa pour chiffrer
Posté par vincent LECOQ (site web personnel) . Évalué à 4.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par rhizome . Évalué à 1.
ça dépend, pas avec les hachages à sens unique (md5, sha1...) ;-)
[^] # plusieurs décompressions possibles
Posté par free2.org . Évalué à 1.
( taille du checksum < taille du message => collisions )
[^] # il est conseillé de compresser avant
Posté par free2.org . Évalué à 1.
[^] # Re: il est conseillé de compresser avant
Posté par _seb_ . Évalué à -1.
On peut seulement démontrer: qu'à l'heure actuelle, cet algorithme est résistant et est l'un des plus sûr pour telle application et cela via les mathématiques. Cependant des failles peuvent toujours existées, et la naissance d'ordinateur quantique pourrait remettre encause pas mal de chose.
[^] # Re: il est conseillé de compresser avant
Posté par free2.org . Évalué à 3.
en l'occurence il est facilement démontrable par les math que l'OTP est incassable, quelle que soit la puissance de calcul de l'adversaire (donc même s'il possède un ordinateur quantique avec une puissance phénoménale)
http://www.wikipedia.org/wiki/One-time_pad(...)
je cite:
One-time pads are provably secure, in that if all the conditions are met properly (i.e., the keys are chosen randomly, are at least as long as the message, and are never reused), then the ciphertext gives the attacking cryptanalyst no information about the message other than its length.
[^] # Re: il est conseillé de compresser avant
Posté par Snark_Boojum . Évalué à 1.
C'est au niveau de la mise en oeuvre dans le monde réel que c'est plus dur:
* il faut générer une vraie clef aléatoire, de la même taille que le message;
* il faut faire parvenir cette clef au destinataire de façon sécurisée avant de pouvoir envoyer le message via un canal non sécurisé
Bref:
* les armées peuvent s'en servir;
* les gouvernements aussi;
* le petit particulier qui veut commander une paire de chaussettes par internet par contre...
Snark
[^] # OTP est praticable par tous, voici comment
Posté par free2.org . Évalué à 1.
en compressant bien les messages textes que j'échange avec ces personnes, je peux communiquer avec eux pendant des années et plusieurs fois par jour en ajoutant une couche OTP (histoire de compliquer l'analyse de mon générateur aléatoire, et d'éviter les attaques par répétition/délétions/knownCleartext) à une couche de crypto classique
si mon générateur aléatoire n'est pas trop pourri (y'a des cartes PCI sinon), même les ordinateurs quantiques auront beaucoup de mal à décrypter tout ça (démonstration mathématique oblige)
si en + j'échange un HDD de 100 gigas avec un ami que je vois en personne toutes les semaines (ou tous les mois c'est selon), alors l'échange permanent sécurisé et en temps réel de fichiers multimédias avec cet ami n'est pas un problème non plus
(aucun problème pour se téléphoner en toute sécurité par exemple)
tout ceci est bien sûr valable pour du business et DEVRAIT être utilisé par toutes les entreprises pour leur communications passant par des réseaux extérieurs !
je le conseille aussi à ceux qui luttent contre la corruption des puissants (car dans la constitution française, comme dans d'autres, la justice/parquet/CSM dépend fortement des dirigeants politiques et de leurs amis)
[^] # Re: OTP est praticable par tous, voici comment
Posté par djrom . Évalué à 1.
[^] # carte pci et /dev/random
Posté par free2.org . Évalué à 1.
cartes aléatoires spécialisées PCI qui sont en effet basées sur des phénomènes physiques aléatoires (il y a ausi des cartes mères VIA avec de tels générateurs)
mais en + il y a des phénomènes aléatoires courants comme le temps (en millisecondes ou mieux) écoulé entre 2 frappes de touche du clavier, manipulations souris, voir entre la réception de paquets provenants d'une carte réseau
c'est sur l'accumulation de ces phénomènes que se base /dev/random dans Linux (il y a un pool de ces phénomènes qui est sauvegardé lors d'un shutdown et qui bloque /dev/random quand il est épuisé)
[^] # Re: il est conseillé de compresser avant
Posté par Fabimaru (site web personnel) . Évalué à 3.
J'avais lu un article dans Courier International à ce propos. Un mec proposait la chose suivante:
- au début de la connexion, le chiffrage se fait par un algo classique avec clef publique/clef privée (en supposant qu'il faille au moins quelques secondes pour le casser)
- sur ces connexions, les deux parties se passent des informations pour se synchroniser
- après, la source de "one time padding" est lue à partir d'une source commune (par exemple, un satellite) qui émet des données "aléatoire" à haut débit (impossible de stocker toutes les données même durant un lap de temps court), ce qui fait qu'il n'est pas possible de connaitre les clefs OTP que si on a pu se synchroniser lors de la première étape (courte).
Bon c'est sûr qu'il faut une certaine infrastructure pour ça (un récepteur satellite), que les authorités ne veulent pas rendre possible un système quasi-inviolable...
[^] # Re: il est conseillé de compresser avant
Posté par wismerhill . Évalué à 1.
Car il faut tenir compte de la distance parcourue par les données entre le satellite et les machines (ben oui, la vitesse de la lumière n'est pas infinie), et vu la précision demandée (probablement au moins la microseconde, peut-être moins suivant le débit dont tu parle) il faudra même faire des corrections relativistes (comme pour les GPS).
Pour une précision à 1µs près il faut connaître la distance à 300m près, on est déjà proche des limites du GPS (et il faut aussi que le satellite connaisse sa position très précisément, mais ce n'est pas le plus gros problème).
Et puis, une synchronisation par le réseau à la microseconde près ça ne doit pas être trivial non plus. Si j'en crois ntpd les trois serveur (en stratum 2) que j'ai défini comme base pour me mettre à l'heure ont des variations d'heure de l'ordre de la milliseconde (c'est déjà impressionnant!).
# Re: La crypto c'est sympa pour chiffrer
Posté par Eric Boulat . Évalué à 4.
[^] # stego => crypto
Posté par free2.org . Évalué à 1.
en + un fichier crypté ressemble beaucoup au "bruit de fond" d'un fichier audio/vidéeo, les 2 ayant une apparence aléatoire
[^] # Re: stego => crypto
Posté par nodens . Évalué à 0.
[^] # Re: stego => crypto
Posté par Boa Treize (site web personnel) . Évalué à 2.
# Re: La crypto c'est sympa pour chiffrer
Posté par Sebastien MICHEL (site web personnel) . Évalué à 4.
# Re: La crypto c'est sympa pour chiffrer
Posté par Gohar . Évalué à 10.
F3y9vT3UPYh3QFgEUlCalt0D/3n6NopRYy0hMN6BPu+NarXwv6NQ9g0GV5FNjEEr
igkrD/htqCyWAUl8zyCKKUFZZx4UGBRZ5guCdNzwgYH3yn3aVMhJYQ6tcSlLsj3f
JIz4LAZ3+rI77rbn7gHHdp7CSAuV+QHv3aNanUD/KGz5SPSvF4w+5qRM4PfPNT1h
LMV8BACzxiyX7vzeE4ZxNYvcuCtv0mvEHl9yD66NFA35RvXaO0QiRVYeoUa5JOQZ
gwq+fIB0zgsEYDhXFkC1hM/QL4NccMRk8C09nFn4eiz4dAEnwKt4rLCJKhkLl1DW
TSoXHe/dOXaLnFyLzB1J8hEYmUvw3SwPt//wMqDiVB
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par V . Évalué à 6.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par chooops . Évalué à 5.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par V . Évalué à 2.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Ramón Perez (site web personnel) . Évalué à 2.
Tout ça est arrivé si vite....
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Sixel . Évalué à 1.
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # On vous a parlé de la stéganographie ?
Posté par ナイコ (site web personnel) . Évalué à 6.
9sLXzDgYMAcpzkX59QvEkphSHDEElsG+/+tKQrMMKiSVbgm394Bwun1IZJ2par9Z
Q/n/twdlqcQDw6WBBeCr+eGlvbyPx78MLvpstVBmJ4qYbFq7chz0n1+NdsSCQU+3
1+IRAvP07tFlmGXXVk9RgZLesBrevetsSapuSaiPasBienz93P4Pcm5ge46mPm2sbNadc
AYRQHJS5zMGkeBOPdcSsdQZ1oApkPoaAhGPGR83vWJXKKRX42+9HzOh+leqpbV36
p+VZ7e9ENb5Uf1+Sur+2H1Z5ozVgo5z48BlbL3WzCAf+LL2SNs0Ki2sbP+Rkp2V6
deHof7ShlC/MqdjteRNfe/KOHalY3lo8b348pnFXJ29OxBHruObXZMcgg2RGm99K
c1hDpIDwRONtT8qw0T5vJYHcGA1qyGV8DVp9LDc1GnJToXbjHGsvTxPrmdjOtUaG
On vous a parlé de la stéganographie ? ;-)
[^] # Re: On vous a parlé de la stéganographie ?
Posté par Laurent Saint-Michel . Évalué à 2.
# Re: La crypto c'est sympa pour chiffrer
Posté par Nÿco (site web personnel) . Évalué à 1.
Existe-t-il des interfaces ? (clic droit dans Nautilus/Konqueror)
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Staz . Évalué à 1.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par nodens . Évalué à 1.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par pplf . Évalué à 1.
Le noyau pré-compilé livré sur Mandrake et SuSE fait ça. On peut opter soit pour des containers chiffrés, soit pour des partitions entières chiffrées: http://openpgp.vie-privee.org/linux.html(...)
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_sing(...)
# Re: La crypto c'est sympa pour chiffrer
Posté par Wawet76 (site web personnel) . Évalué à 1.
C'est quelque chose de basique, j'ose espérer qu'il y a un truc pour faire ça qui se trouve sur la plupart des systèmes (comme on peut raisonnablement penser trouver gzip)... mais je n'ai pas trouvé.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par mczz . Évalué à 3.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par domi . Évalué à 3.
openssl enc -idea -pass pass:toto -in FicIn -out FicOut [-d]
L'option -d est à ajouter pour le déchiffrement.
Si tu n'utilises pas l'argument pass:toto, le mot de passe toto devra être saisi au clavier.
# Re: La crypto c'est sympa pour chiffrer
Posté par abrida . Évalué à 2.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par C2RIK . Évalué à 1.
[^] # Re: La crypto c'est sympa pour chiffrer
Posté par Arnaud . Évalué à 1.
Mmm... il y a toujour des bugs dans les softs de cryptage, à quand un soft avec les algos prouvés mathématiquement à grand coup de méthode formelle, comme le B ?
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par free2.org . Évalué à 1.
par contre il a été démontré mathématiquement que OTP est le seul algo qui peut résister à un adversaire qui possède une puissance de calcul illimité
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par tipmeabout . Évalué à 0.
Vu que ce n'est pas moi qui ait fait la preuve, je ne crois plus à 100% les affirmations qu'on me donne. Les médias ont le pouvoir de faire croire se qu'il veulent, alors pourquoi ne pas faire croire ça aussi pour la crypto ?
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par free2.org . Évalué à 2.
Tu trouves cette démo facilement sur le net, tu peux donc la lire !
Tu trouveras aussi sur le net la démo qui garantit que OTP est le seul algo incassable par une puissance dez calcul illimitée. Cette démo est un peu plus longue (mais compréhensible avec des maths de niveau bac science +1)
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par Benjamin (site web personnel) . Évalué à 1.
bon, c'est bien OTP, mais la clé est un peu longue donc, je viens d'inventer l'algorithme qui tue pour faire une crypto facile pour tous :
1. Crypter sont fichier avec une cle OTP
2. Ajouter la clé à la fin du fichier.
Pour décrypter, on fait un programme qui :
1. Demande le mot de passe
2. Calcule le hash md5 de la clé, en lisant la deuxième moitié du fichier
3. Vérifie que le mot de passe = le hash md5
4. Dans ce cas, décrypte la première moitié du fichier avec la clé
5. Sinon, refuse le décryptage.
Avantages énaurmes de cette méthode :
1. Les fichiers cryptés se voient facilement : ils ont un nombre pair d'octets
2. Il ne faut pas retenir toute la clé, juste son md5
3. un md5, c'est facile à retenir
4. Le cryptage OTP est le seul à garantir une inviolabilité meme avec une puissance de calcul illimitée.
Vous vous rendez-compte ? Je vais etre riche ?
non ?
pourquoi ?
bon, d'accord ----> [] (tm(c))
[^] # Re: La crypto c'est sympa pour chiffrer OTP
Posté par PLuG . Évalué à 1.
(ils transmettent la clef a la fin des paquets ....)
# Re: La crypto c'est sympa pour chiffrer
Posté par NikToo . Évalué à 1.
# Re: ssl c'est chèr !
Posté par mxt . Évalué à 1.
Connaissez-vous un organisme certifiant la clé SSL pour faire du https pour une somme modique et reconnu par tous les navigateurs (suivez mon regard) ?
# La crypto c'est pas sympa pour...
Posté par Christophe GRAND (site web personnel) . Évalué à 0.
Enfin, surtout, c'est généralement très inutile le cryptage de FS mais je suis ouvert à tout argument contraire !
[^] # La crypto c'est sympa pour les FS !
Posté par free2.org . Évalué à 1.
je ne crois pas ...
[^] # Re: La crypto c'est sympa pour les FS !
Posté par Christophe GRAND (site web personnel) . Évalué à 1.
AMHA c'est un besoin très vertical que la crypto pour les FS et qui arrive après des mesures de sécurité beaucoup plus lourdes et physiques (portes blindés, vigiles, sécurité, équipements tempest-proof...) autant qu'organisationnelles (le faible maillon humain).
[^] # soltion efficace et peu chère
Posté par free2.org . Évalué à 1.
cette solution est pas chère et efficace: en cas d'intrusion, même si le voleur s'empare du disque dur ou en copie les données, tu es prévenu et tu peux passer la pièce et l'ordi au peigne fin pour t'assurer que des mouchards n'ont pas été déposés (tu peux même changer d'ordi au besoin)
[^] # Re: La crypto c'est pas sympa pour...
Posté par KiKouN . Évalué à 2.
[^] # Re: La crypto c'est pas sympa pour...
Posté par Christophe GRAND (site web personnel) . Évalué à 2.
C'est la principe d'une assurance ;-)
# Les système de fichiers et la crypto
Posté par Hubert . Évalué à 1.
La force du système est double :
- Tout d'abord, mathématiquement, il est impossible de démontrer sur une quelconque partition de ce type qu'elle contient des données ou non.
- Ensuite, le camouflage se fait par niveau : un mot de passe peut ne dévoiler qu'un masque du sgf.
Le risque c'est que si on perd le mot de passe global, il n'y a aucune chance que vous voyiez un jour vos données de nouveau... Vous aurez beau crier, personne ne vous croira qu'il y a des données de perdues et on vous dira "prouvez le" et vous serez bien emmerdé. Mais c'est souvent le prix à payer pour une sécurité de qualité, n'est-ce pas ?
Bon j'avoue, j'ai eu un peu la flemme de chercher plus amples info sur le net donc je ne laisse pas de pointeur. C'est aussi le coté collaboratif de la chose ;)
[^] # Re: Les système de fichiers et la crypto
Posté par Nucleos . Évalué à 1.
http://www.google.fr/search?q=stegfs(...)
le lien officiel
http://www.mcdonald.org.uk/StegFS/(...)
une définition rapide du Jargon français : « Steganographic File System. système de fichiers stéganographique, qui non seulement crypte les données, mais en plus les dissimule de façon qu'on ne puisse pas prouver qu'elles sont là... » (http://www.linux-france.org/prj/jargonf/S/StegFS.html(...))
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.