la même que de deviner ton mot de passe sans aucun renseignement
Alors CA c'est ce qu'on appelle une "probabilité générale faussée" car la saine logique intervient dans le processus, par elimination. Sachant que la plupart des zigottos utilisent des mdp simples, voir achi-simple. Dans un très grande entreprise le service informatique a fait une étude (7000 PC) et constaté que:
si tu ne connais pas l'utilisateur... tout ca ne veut rien dire. Quel mot de passe va utiliser un coréen?
jdd
-- http://www.dodin.net Le wiki des forums son-image français: http://dodin.org/frsv/ http://jddtube.dodin.org/20120616-52-highway_v1115
Le 25/01/2013 00:24, Richard a écrit :
la même que de deviner ton mot de passe sans aucun renseignement
Alors CA c'est ce qu'on appelle une "probabilité générale faussée"
car la saine logique intervient dans le processus, par elimination.
Sachant que la plupart des zigottos utilisent des mdp simples,
voir achi-simple. Dans un très grande entreprise le service
informatique a fait une étude (7000 PC) et constaté que:
si tu ne connais pas l'utilisateur... tout ca ne veut rien dire. Quel
mot de passe va utiliser un coréen?
jdd
--
http://www.dodin.net
Le wiki des forums son-image français: http://dodin.org/frsv/
http://jddtube.dodin.org/20120616-52-highway_v1115
la même que de deviner ton mot de passe sans aucun renseignement
Alors CA c'est ce qu'on appelle une "probabilité générale faussée" car la saine logique intervient dans le processus, par elimination. Sachant que la plupart des zigottos utilisent des mdp simples, voir achi-simple. Dans un très grande entreprise le service informatique a fait une étude (7000 PC) et constaté que:
si tu ne connais pas l'utilisateur... tout ca ne veut rien dire. Quel mot de passe va utiliser un coréen?
jdd
-- http://www.dodin.net Le wiki des forums son-image français: http://dodin.org/frsv/ http://jddtube.dodin.org/20120616-52-highway_v1115
Jacques DASSIÉ
Alf92 a présenté l'énoncé suivant :
en revanche quand tu donnes des cours de phylo à 2francs sur FRP, ou que tu interviens sur fr.sci.psychologie ou fr.sci.psychanalyse, là il y a *vraiment* de quoi se marrer.
Désolé, Alf, mais tes informations s'avèrent un peu lacunaires...
En voici quelques autres, sans aucune prétention d'exhaustivité :
en revanche quand tu donnes des cours de phylo à 2francs sur FRP, ou
que tu interviens sur fr.sci.psychologie ou fr.sci.psychanalyse, là
il y a *vraiment* de quoi se marrer.
Désolé, Alf, mais tes informations s'avèrent un peu lacunaires...
En voici quelques autres, sans aucune prétention d'exhaustivité :
en revanche quand tu donnes des cours de phylo à 2francs sur FRP, ou que tu interviens sur fr.sci.psychologie ou fr.sci.psychanalyse, là il y a *vraiment* de quoi se marrer.
Désolé, Alf, mais tes informations s'avèrent un peu lacunaires...
En voici quelques autres, sans aucune prétention d'exhaustivité :
C'est le tag HTML <keygen>, existe au moins depuis HTML-3, il me semble.
Non, nouveauté de HTML5,
Il est implémenté dans les bons navigateurs depuis au moins 10 ans, mais tu as raison, je ne savais pas qu'il n'était pas normalisé.
pas implémentée partout (notament dans IE),
CQFD.
aucune garantie sur la qualité de la clef générée
Absurde, tu as toutes les garantis, vu que c'est fait localement avec un code que tu contrôle. Si tu n'es pas satisfait de la manière dont firefox le fait, tu peux recoder ce bout là...
Mais colle le dit FiLH, y'a de bonnes chances que ce soit un appel open-ssl qui lui-même renvoie au générateur aléatoire du kernel, qui a été pas mal audité.
Certe on est pas à l'abri d'une connerie, voir récemment ssh-keygen, mais je ne vois pas comment être plus sûr. D'autant que si tu veux connecter un générateur hardware à ta machine comme entrée du générateur du noyau, y'a ce qu'il faut.
C'est le tag HTML <keygen>, existe au moins depuis HTML-3, il me semble.
Non, nouveauté de HTML5,
Il est implémenté dans les bons navigateurs depuis au moins 10 ans, mais
tu as raison, je ne savais pas qu'il n'était pas normalisé.
pas implémentée partout (notament dans IE),
CQFD.
aucune garantie sur la qualité de la clef générée
Absurde, tu as toutes les garantis, vu que c'est fait localement avec un
code que tu contrôle. Si tu n'es pas satisfait de la manière dont
firefox le fait, tu peux recoder ce bout là...
Mais colle le dit FiLH, y'a de bonnes chances que ce soit un appel
open-ssl qui lui-même renvoie au générateur aléatoire du kernel, qui a
été pas mal audité.
Certe on est pas à l'abri d'une connerie, voir récemment ssh-keygen,
mais je ne vois pas comment être plus sûr. D'autant que si tu veux
connecter un générateur hardware à ta machine comme entrée du générateur
du noyau, y'a ce qu'il faut.
C'est le tag HTML <keygen>, existe au moins depuis HTML-3, il me semble.
Non, nouveauté de HTML5,
Il est implémenté dans les bons navigateurs depuis au moins 10 ans, mais tu as raison, je ne savais pas qu'il n'était pas normalisé.
pas implémentée partout (notament dans IE),
CQFD.
aucune garantie sur la qualité de la clef générée
Absurde, tu as toutes les garantis, vu que c'est fait localement avec un code que tu contrôle. Si tu n'es pas satisfait de la manière dont firefox le fait, tu peux recoder ce bout là...
Mais colle le dit FiLH, y'a de bonnes chances que ce soit un appel open-ssl qui lui-même renvoie au générateur aléatoire du kernel, qui a été pas mal audité.
Certe on est pas à l'abri d'une connerie, voir récemment ssh-keygen, mais je ne vois pas comment être plus sûr. D'autant que si tu veux connecter un générateur hardware à ta machine comme entrée du générateur du noyau, y'a ce qu'il faut.
En voici quelques autres, sans aucune prétention d'exhaustivité :
2s de reflexion t'aurait évité d'afficher ta bêtise ...
les www que tu cites sont des copie de usenet, je ne suis abonné à aucun forum web
90% des forum usenet que tu as stupidemment googlés sont le résultat de fu2 divers completement indépendants de ma volonté ...
je suis abonné actuellement à 4 forum usenet puisque ça t'interesse.
abc abc
On 2013-01-24, Richard wrote:
Si tu as le md5 d'un fichier, tu ne connais pas le contenu du fichier, mais si on te présente un fichier, que tu en fais le md5, tu peux certifier (à une probabilité très grande) que c'est bien le même.
C'est combien ça "une probabilité très grande" ?
Plus grande que la probabilité de se faire attaquer successivement 65 000 fois par un Gorille s'étant échappé d'un zoo.
On 2013-01-24, Richard <garetgv_remove_@skynet.be> wrote:
Si tu as le md5 d'un fichier, tu ne connais pas le contenu du fichier,
mais si on te présente un fichier, que tu en fais le md5, tu peux
certifier (à une probabilité très grande) que c'est bien le même.
C'est combien ça "une probabilité très grande" ?
Plus grande que la probabilité de se faire attaquer successivement
65 000 fois par un Gorille s'étant échappé d'un zoo.
Si tu as le md5 d'un fichier, tu ne connais pas le contenu du fichier, mais si on te présente un fichier, que tu en fais le md5, tu peux certifier (à une probabilité très grande) que c'est bien le même.
C'est combien ça "une probabilité très grande" ?
Plus grande que la probabilité de se faire attaquer successivement 65 000 fois par un Gorille s'étant échappé d'un zoo.
Les fichiers sont stockés chiffrés sur les serveurs de mega. La clef symetrique utilisée pour le chiffrement et dechiffrement des fichiers est elle aussi sur les serveurs de mega, mais chiffrée avec le mot de passe de l'utilisateur. Donc la clef est dechiffrée localement, et ensuite le contenu du fichier telechargé aussi.
ah voilà ça s'éclairci ...
Le principe semble pas mal, mais il faut attendre que quelques experts aient pris le temps d'analyser un peu plus en detail le fonctionnement pour voir si tout semble etre fait correctement. Par exemple il suffirait que l'algo utilisé pour le dechiffrement de la clef symetrique avec le mot de passe soit trop simple pour qu'un brute force sur le mot de passe soit possible dans des temps raisonnables.
voilà le truc qui clignote dans ma tête depuis le début, la force globale de l'ensemble c'est la force de mon pass...
rien à foutre du RSA 2048bit si mon pass c'est 1234 ...
Et si le mot de passe est bien choisis, ca va dépendre de l'algo utilisé pour la transformation mot de passe -> clef.
Dans le cas d'un accès à un serveur en utilisant un mot de passe, il est possible pour le serveur de limiter le nombre de tentatives par minute. Dans le cas du dechiffrement d'un fichier, tout peut se faire en local sans connexion avec le serveur. Donc la seule chose qui limite la possibilité de faire un brute force c'est le temps de calcul necessaire pour faire la transformation password -> clef, et la verification si la clef fonctionne.
Pour limiter les possibilités de brute force, on utiliser un algo qui demande beaucoup de calculs. C'est expliqué par exemple la dedans : http://wiki.cryptsetup.googlecode.com/git/TKS1-draft.pdf
Sous Linux quand on crée une partition cryptée, il est possible de choisir le nombre d'iterations de l'algo utilisé pour transformer le mot de passe en clef. Plus on choisis une valeur importante, et plus il sera compliqué de tester beaucoup de mots de passe, mais plus le montage de la partition prendra du temps (quelques secondes).
On 2013-01-24, Stephane Legras-Decussy <admin@leroymerlin.fr> wrote:
On 01/24/2013 07:19 PM, abc abc wrote:
Les fichiers sont stockés chiffrés sur les serveurs de mega. La clef
symetrique utilisée pour le chiffrement et dechiffrement des fichiers
est elle aussi sur les serveurs de mega, mais chiffrée avec le mot de
passe de l'utilisateur. Donc la clef est dechiffrée localement, et
ensuite le contenu du fichier telechargé aussi.
ah voilà ça s'éclairci ...
Le principe semble pas mal, mais il faut attendre que quelques experts
aient pris le temps d'analyser un peu plus en detail le fonctionnement
pour voir si tout semble etre fait correctement. Par exemple il suffirait
que l'algo utilisé pour le dechiffrement de la clef symetrique avec le
mot de passe soit trop simple pour qu'un brute force sur le mot de passe
soit possible dans des temps raisonnables.
voilà le truc qui clignote dans ma tête depuis le début,
la force globale de l'ensemble c'est la force de mon pass...
rien à foutre du RSA 2048bit si mon pass c'est 1234 ...
Et si le mot de passe est bien choisis, ca va dépendre de l'algo utilisé
pour la transformation mot de passe -> clef.
Dans le cas d'un accès à un serveur en utilisant un mot de passe, il est
possible pour le serveur de limiter le nombre de tentatives par minute.
Dans le cas du dechiffrement d'un fichier, tout peut se faire en local
sans connexion avec le serveur. Donc la seule chose qui limite la
possibilité de faire un brute force c'est le temps de calcul necessaire
pour faire la transformation password -> clef, et la verification si la
clef fonctionne.
Pour limiter les possibilités de brute force, on utiliser un algo qui
demande beaucoup de calculs. C'est expliqué par exemple la dedans :
http://wiki.cryptsetup.googlecode.com/git/TKS1-draft.pdf
Sous Linux quand on crée une partition cryptée, il est possible de
choisir le nombre d'iterations de l'algo utilisé pour transformer le mot
de passe en clef. Plus on choisis une valeur importante, et plus il sera
compliqué de tester beaucoup de mots de passe, mais plus le montage de
la partition prendra du temps (quelques secondes).
Les fichiers sont stockés chiffrés sur les serveurs de mega. La clef symetrique utilisée pour le chiffrement et dechiffrement des fichiers est elle aussi sur les serveurs de mega, mais chiffrée avec le mot de passe de l'utilisateur. Donc la clef est dechiffrée localement, et ensuite le contenu du fichier telechargé aussi.
ah voilà ça s'éclairci ...
Le principe semble pas mal, mais il faut attendre que quelques experts aient pris le temps d'analyser un peu plus en detail le fonctionnement pour voir si tout semble etre fait correctement. Par exemple il suffirait que l'algo utilisé pour le dechiffrement de la clef symetrique avec le mot de passe soit trop simple pour qu'un brute force sur le mot de passe soit possible dans des temps raisonnables.
voilà le truc qui clignote dans ma tête depuis le début, la force globale de l'ensemble c'est la force de mon pass...
rien à foutre du RSA 2048bit si mon pass c'est 1234 ...
Et si le mot de passe est bien choisis, ca va dépendre de l'algo utilisé pour la transformation mot de passe -> clef.
Dans le cas d'un accès à un serveur en utilisant un mot de passe, il est possible pour le serveur de limiter le nombre de tentatives par minute. Dans le cas du dechiffrement d'un fichier, tout peut se faire en local sans connexion avec le serveur. Donc la seule chose qui limite la possibilité de faire un brute force c'est le temps de calcul necessaire pour faire la transformation password -> clef, et la verification si la clef fonctionne.
Pour limiter les possibilités de brute force, on utiliser un algo qui demande beaucoup de calculs. C'est expliqué par exemple la dedans : http://wiki.cryptsetup.googlecode.com/git/TKS1-draft.pdf
Sous Linux quand on crée une partition cryptée, il est possible de choisir le nombre d'iterations de l'algo utilisé pour transformer le mot de passe en clef. Plus on choisis une valeur importante, et plus il sera compliqué de tester beaucoup de mots de passe, mais plus le montage de la partition prendra du temps (quelques secondes).
abc abc
On 2013-01-24, Erwan David wrote:
abc abc écrivait :
je n'ai vu aucun renseignement fiable. Les "informqtions" données sur le chiffrement sont en contradiction avec les usages mis en avant. Un browser web ne génère pas de clef. Et d'abord quel standard de clef, avec quelle force. Il y a beaucoup de buzz mais les infos techniques sont plus que lacunaires.
Y a des infos sur leur site : https://mega.co.nz/#developers
Beurk
Super argumenté comme toujours.
Et puis les sources du client en javascript sont publiques, il suffit de les lire.
Ah il ya donc bien du code téléchargé, et à chaque fois. Et croire qu'on peut évaluer une implémentation de crypto quand on n'est pas spécialiste c'est vraiment se foutre le doigt dans l'œil jusqu'à l'épaule.
Oui. Le pire étant ceux comme toi qui l'evaluent sans meme avoir regardé le code ou la moindre doc expliquant le fonctionnement.
Mais on en est meme pas à parler d'infos techniques quand toi tu parles d'une "appli fermée et pas auditée", signe que t'as vraiment rien pigé. Faut vraiment avoir rien suivi pour ne pas etre au courant que tout est fait en javascript dans le navigateur, c'est écrit et expliqué partout.
Ah ? Justement non. Et c'est tpoujours pas audité, et en plus inauditable puisqu'il n'y a aucune garantie que c'est le même code qui sera téléchargé à chaque fois.
Ca n'en fait pas une appli fermée. Et rien ne t'empeche d'heberger toi meme le code javascript, ou passer par l'API en implementant les trucs importants toi meme.
J'ai AUCUNE confiance dans la crypto faite de cette manière là. Mais vraiment aucune.
De quelle manière ?
Tu te permets de juger alors que manifestement tu n'as meme pas pris le temps de te renseigner un minimum sur ce dont tu parles.
Moi je ne dis pas que c'est secure, je n'ai pas étudié le code en detail, et je ne suis pas un expert en cryptographie, donc je n'affirme rien. Juste que ca n'est pas une appli fermée, et qu'il est possible de l'auditer, ce que sont d'ailleurs en train de faire certaines personnes.
Il y a des gens qui ont lu le code, et qui ont fait des critiques sur des points précis (par exemple le manque d'entropie possible pour generer la clef). Ca c'est interessant. Ca change des critiques de types comme toi qui n'ont meme pas pris le temps de se renseigner un minimum avant de dire que c'est nul ...
On 2013-01-24, Erwan David <erwan@rail.eu.org> wrote:
abc abc <abc@abc.abc> écrivait :
je n'ai vu aucun renseignement fiable. Les "informqtions" données sur le
chiffrement sont en contradiction avec les usages mis en avant. Un
browser web ne génère pas de clef. Et d'abord quel standard de clef,
avec quelle force. Il y a beaucoup de buzz mais les infos techniques
sont plus que lacunaires.
Y a des infos sur leur site :
https://mega.co.nz/#developers
Beurk
Super argumenté comme toujours.
Et puis les sources du client en javascript sont publiques, il suffit de
les lire.
Ah il ya donc bien du code téléchargé, et à chaque fois. Et croire qu'on
peut évaluer une implémentation de crypto quand on n'est pas spécialiste
c'est vraiment se foutre le doigt dans l'œil jusqu'à l'épaule.
Oui. Le pire étant ceux comme toi qui l'evaluent sans meme avoir regardé
le code ou la moindre doc expliquant le fonctionnement.
Mais on en est meme pas à parler d'infos techniques quand toi tu parles
d'une "appli fermée et pas auditée", signe que t'as vraiment rien
pigé. Faut vraiment avoir rien suivi pour ne pas etre au courant que
tout est fait en javascript dans le navigateur, c'est écrit et expliqué
partout.
Ah ? Justement non. Et c'est tpoujours pas audité, et en plus
inauditable puisqu'il n'y a aucune garantie que c'est le même code qui
sera téléchargé à chaque fois.
Ca n'en fait pas une appli fermée. Et rien ne t'empeche d'heberger toi
meme le code javascript, ou passer par l'API en implementant les trucs
importants toi meme.
J'ai AUCUNE confiance dans la crypto faite de cette manière là. Mais
vraiment aucune.
De quelle manière ?
Tu te permets de juger alors que manifestement tu n'as meme pas pris le
temps de te renseigner un minimum sur ce dont tu parles.
Moi je ne dis pas que c'est secure, je n'ai pas étudié le code en
detail, et je ne suis pas un expert en cryptographie, donc je n'affirme
rien. Juste que ca n'est pas une appli fermée, et qu'il est possible de
l'auditer, ce que sont d'ailleurs en train de faire certaines personnes.
Il y a des gens qui ont lu le code, et qui ont fait des critiques sur
des points précis (par exemple le manque d'entropie possible pour
generer la clef). Ca c'est interessant. Ca change des critiques de types
comme toi qui n'ont meme pas pris le temps de se renseigner un minimum
avant de dire que c'est nul ...
je n'ai vu aucun renseignement fiable. Les "informqtions" données sur le chiffrement sont en contradiction avec les usages mis en avant. Un browser web ne génère pas de clef. Et d'abord quel standard de clef, avec quelle force. Il y a beaucoup de buzz mais les infos techniques sont plus que lacunaires.
Y a des infos sur leur site : https://mega.co.nz/#developers
Beurk
Super argumenté comme toujours.
Et puis les sources du client en javascript sont publiques, il suffit de les lire.
Ah il ya donc bien du code téléchargé, et à chaque fois. Et croire qu'on peut évaluer une implémentation de crypto quand on n'est pas spécialiste c'est vraiment se foutre le doigt dans l'œil jusqu'à l'épaule.
Oui. Le pire étant ceux comme toi qui l'evaluent sans meme avoir regardé le code ou la moindre doc expliquant le fonctionnement.
Mais on en est meme pas à parler d'infos techniques quand toi tu parles d'une "appli fermée et pas auditée", signe que t'as vraiment rien pigé. Faut vraiment avoir rien suivi pour ne pas etre au courant que tout est fait en javascript dans le navigateur, c'est écrit et expliqué partout.
Ah ? Justement non. Et c'est tpoujours pas audité, et en plus inauditable puisqu'il n'y a aucune garantie que c'est le même code qui sera téléchargé à chaque fois.
Ca n'en fait pas une appli fermée. Et rien ne t'empeche d'heberger toi meme le code javascript, ou passer par l'API en implementant les trucs importants toi meme.
J'ai AUCUNE confiance dans la crypto faite de cette manière là. Mais vraiment aucune.
De quelle manière ?
Tu te permets de juger alors que manifestement tu n'as meme pas pris le temps de te renseigner un minimum sur ce dont tu parles.
Moi je ne dis pas que c'est secure, je n'ai pas étudié le code en detail, et je ne suis pas un expert en cryptographie, donc je n'affirme rien. Juste que ca n'est pas une appli fermée, et qu'il est possible de l'auditer, ce que sont d'ailleurs en train de faire certaines personnes.
Il y a des gens qui ont lu le code, et qui ont fait des critiques sur des points précis (par exemple le manque d'entropie possible pour generer la clef). Ca c'est interessant. Ca change des critiques de types comme toi qui n'ont meme pas pris le temps de se renseigner un minimum avant de dire que c'est nul ...
