Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
fulcanelli
"Brain 0verride" wrote in message news:...
Quelqu'un sait s'il existe un logiciel sous license gpl tel que gnupg, implémentant le cryptage Vernam ? (masques jettables)
amicalement,
En gpl pas à ma connaissance, mais cela doit sans doute exister quelque par. Cela ne représente toutefois pas plus d'une cinquantaine de ligne de code à implémenter.
Le plus long étant de rentrer une longue clé aléatoire de la taille du message à la main...
"Brain 0verride" <christophe.casalegno@digital-network.net> wrote in message news:<pan.2003.06.29.21.43.23.142372@digital-network.net>...
Quelqu'un sait s'il existe un logiciel sous license gpl tel que gnupg,
implémentant le cryptage Vernam ? (masques jettables)
amicalement,
En gpl pas à ma connaissance, mais cela doit sans doute exister
quelque par.
Cela ne représente toutefois pas plus d'une cinquantaine de ligne de
code à implémenter.
Le plus long étant de rentrer une longue clé aléatoire de la taille du
message à la main...
Quelqu'un sait s'il existe un logiciel sous license gpl tel que gnupg, implémentant le cryptage Vernam ? (masques jettables)
amicalement,
En gpl pas à ma connaissance, mais cela doit sans doute exister quelque par. Cela ne représente toutefois pas plus d'une cinquantaine de ligne de code à implémenter.
Le plus long étant de rentrer une longue clé aléatoire de la taille du message à la main...
Brain 0verride
Le Wed, 02 Jul 2003 19:55:41 -0700, fulcanelli a écrit :
En gpl pas à ma connaissance, mais cela doit sans doute exister quelque part Cela ne représente toutefois pas plus d'une cinquantaine de ligne de code à implémenter.
Oui ce n'est pas pour un soucis d'implémentation mais pour un soucis de référencement des outils en question.
Le plus long étant de rentrer une longue clé aléatoire de la taille du message à la main...
Est ce que l'on perd la fiabilité du vernam si cette clef est générée automatiquement ? Genre un random de la taille du message ?
Le Wed, 02 Jul 2003 19:55:41 -0700, fulcanelli a écrit :
En gpl pas à ma connaissance, mais cela doit sans doute exister
quelque part
Cela ne représente toutefois pas plus d'une cinquantaine de ligne de
code à implémenter.
Oui ce n'est pas pour un soucis d'implémentation mais pour un soucis de
référencement des outils en question.
Le plus long étant de rentrer une longue clé aléatoire de la taille du
message à la main...
Est ce que l'on perd la fiabilité du vernam si cette clef est générée
automatiquement ? Genre un random de la taille du message ?
Le Wed, 02 Jul 2003 19:55:41 -0700, fulcanelli a écrit :
En gpl pas à ma connaissance, mais cela doit sans doute exister quelque part Cela ne représente toutefois pas plus d'une cinquantaine de ligne de code à implémenter.
Oui ce n'est pas pour un soucis d'implémentation mais pour un soucis de référencement des outils en question.
Le plus long étant de rentrer une longue clé aléatoire de la taille du message à la main...
Est ce que l'on perd la fiabilité du vernam si cette clef est générée automatiquement ? Genre un random de la taille du message ?
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que les ordinateurs sont des outils déterministes il est possible donc d'en deviner la sortie. ms il est clair que tu ne vas pas t'amuser à recoder un générateur pseudo-aléatoire , donc tu peux utiliser /dev/random, ms la sécurité de vernam en est affaiblie.
amicalement,
greg
"Brain 0verride" wrote in message news:
La sécurité du chiffré dépend directement de la qualité de l'aléa. Quel générateur aléatoire vas tu utiliser?
Si on utilise simplement un /dev/random par ex ?
Comment vas tu transmettre l'aléa ainsi généré à ton correspondant?
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que
les ordinateurs sont des outils déterministes il est possible donc d'en
deviner la sortie.
ms il est clair que tu ne vas pas t'amuser à recoder un générateur
pseudo-aléatoire , donc tu peux utiliser /dev/random, ms la sécurité de
vernam en est affaiblie.
amicalement,
greg
"Brain 0verride" <christophe.casalegno@digital-network.net> wrote in message
news:pan.2003.07.03.14.23.09.32099@digital-network.net...
La sécurité du chiffré dépend directement de la qualité de l'aléa. Quel
générateur aléatoire vas tu utiliser?
Si on utilise simplement un /dev/random par ex ?
Comment vas tu transmettre l'aléa
ainsi généré à ton correspondant?
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que les ordinateurs sont des outils déterministes il est possible donc d'en deviner la sortie. ms il est clair que tu ne vas pas t'amuser à recoder un générateur pseudo-aléatoire , donc tu peux utiliser /dev/random, ms la sécurité de vernam en est affaiblie.
amicalement,
greg
"Brain 0verride" wrote in message news:
La sécurité du chiffré dépend directement de la qualité de l'aléa. Quel générateur aléatoire vas tu utiliser?
Si on utilise simplement un /dev/random par ex ?
Comment vas tu transmettre l'aléa ainsi généré à ton correspondant?
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que les ordinateurs sont des outils déterministes il est possible donc d'en deviner la sortie.
Moui. Sauf que /dev/random est en général alimenté par de l'entropie ""d'assez bonne qualité"" (doubles guillemets) donnée par le kernel (aléas dans les cycles CPU et autres petites fluctuations intéressantes entropiquement parlant) contrairement à /dev/urandom
"When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads to /dev/random will block until additional environmental noise is gathered. "
Greg wrote:
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que
les ordinateurs sont des outils déterministes il est possible donc d'en
deviner la sortie.
Moui. Sauf que /dev/random est en général alimenté par de l'entropie
""d'assez bonne qualité"" (doubles guillemets) donnée par le kernel
(aléas dans les cycles CPU et autres petites fluctuations intéressantes
entropiquement parlant) contrairement à /dev/urandom
"When read, the /dev/random device will only return random bytes within
the estimated number of bits of noise in the entropy pool. /dev/random
should be suitable for uses that need very high quality randomness such
as one-time pad or key generation. When the entropy pool is empty, reads
to /dev/random will block until additional environmental noise is
gathered. "
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que les ordinateurs sont des outils déterministes il est possible donc d'en deviner la sortie.
Moui. Sauf que /dev/random est en général alimenté par de l'entropie ""d'assez bonne qualité"" (doubles guillemets) donnée par le kernel (aléas dans les cycles CPU et autres petites fluctuations intéressantes entropiquement parlant) contrairement à /dev/urandom
"When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads to /dev/random will block until additional environmental noise is gathered. "
pornin
According to Greg :
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que les ordinateurs sont des outils déterministes il est possible donc d'en deviner la sortie.
C'est contestable ici : /dev/random se nourrit sur du "hasard" provenant de mesures physiques (notamment des chronométrages fins d'évènements déclenchés par des pièces matérielles). Il n'est pas clair que le monde matériel soit déterministe (Laplace pensait que oui, mais depuis a été développée la mécanique quantique, qui repose entre autres sur l'idée qu'en fait non) et, en tous cas, même si c'est déterministe, il est très largement au-delà de nos capacités technologiques de déterminer ces évènements.
Donc, en fait, le /dev/random d'un OS décent (genre Linux, FreeBSD, ou Solaris 9) fournit un aléa de qualité "cryptographique", en ce sens qu'il est imprédictible pour tout attaquant ne disposant pas d'une très forte puissance de calcul (capable de faire dans les 2^128 opérations -- ce qui est moult fois plus grand que tout ce qu'on peut faire maintenant et qu'on pourra faire dans un avenir proche).
--Thomas Pornin
According to Greg <gleocadie@wanadoo.fr>:
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que
les ordinateurs sont des outils déterministes il est possible donc d'en
deviner la sortie.
C'est contestable ici : /dev/random se nourrit sur du "hasard" provenant
de mesures physiques (notamment des chronométrages fins d'évènements
déclenchés par des pièces matérielles). Il n'est pas clair que le monde
matériel soit déterministe (Laplace pensait que oui, mais depuis a été
développée la mécanique quantique, qui repose entre autres sur l'idée
qu'en fait non) et, en tous cas, même si c'est déterministe, il est très
largement au-delà de nos capacités technologiques de déterminer ces
évènements.
Donc, en fait, le /dev/random d'un OS décent (genre Linux, FreeBSD,
ou Solaris 9) fournit un aléa de qualité "cryptographique", en ce
sens qu'il est imprédictible pour tout attaquant ne disposant pas
d'une très forte puissance de calcul (capable de faire dans les
2^128 opérations -- ce qui est moult fois plus grand que tout ce
qu'on peut faire maintenant et qu'on pourra faire dans un avenir
proche).
l'aléa fait par les ordinateur n'est pas réellement aléatoire sachant que les ordinateurs sont des outils déterministes il est possible donc d'en deviner la sortie.
C'est contestable ici : /dev/random se nourrit sur du "hasard" provenant de mesures physiques (notamment des chronométrages fins d'évènements déclenchés par des pièces matérielles). Il n'est pas clair que le monde matériel soit déterministe (Laplace pensait que oui, mais depuis a été développée la mécanique quantique, qui repose entre autres sur l'idée qu'en fait non) et, en tous cas, même si c'est déterministe, il est très largement au-delà de nos capacités technologiques de déterminer ces évènements.
Donc, en fait, le /dev/random d'un OS décent (genre Linux, FreeBSD, ou Solaris 9) fournit un aléa de qualité "cryptographique", en ce sens qu'il est imprédictible pour tout attaquant ne disposant pas d'une très forte puissance de calcul (capable de faire dans les 2^128 opérations -- ce qui est moult fois plus grand que tout ce qu'on peut faire maintenant et qu'on pourra faire dans un avenir proche).
