Bonjour, Merci pour la pensée et l'encouragement :-) Par manque de temps je n'ai pas encore terminé la version 3 de mon logiciel, mais par contre l'algo est complète (pour l'instant) depuis un bout. Pour l'instant, le problème est de transformer en C (en DLL) la partie du code VB concernant l'algo. J'ai étudié l'année dernière le C mais j'ai dû arrêter de l'étudier pour vaquer à autre chose et j'en ai, à la longue, oublié presque la totalité de l'étude (l'étude serait donc à refaire). J'ai déjà, sous forme de procédure VB, l'algo servant strictement au chiffrement. Mais selon la demande de Christophe HENRY faudrait que j'amène une explication détaillée de l'algo sur ce forum; mais je fournirais aussi la procédure VB si cela peut aider à me faire comprendre mieux. Cette procédure est donc temporaire jusqu'à ce qu'elle soit transformé en C (en DLL que je puisse appeler à partir de logiciel fait en VB, en Delphi ou autres). La transformation de ce code vers le C est nécessaire en vue d'un chiffrement plus rapide, d'une vitesse de chiffrement plus acceptable pour l'utilisateur du logiciel, vue la quantité plus importante de calcul par rapport à la version précédente. Je pourrais même amener cela sur ce forum dans les jours qui suivent. J'ai le temps qui me manque au travers tout ça, mais je vais essayer d'amener cela sous peu sous le titre : 'Algo RH'.
Bonne journée Raymond
__________________________________________
"Mister Jack" a écrit dans le message de news: 43c82092$0$8138$ ...
Au passage, Raymond, si tu passes encore ici, je suis content de voir qu'il y a eu du progrès. Même si tout n'est pas encore rose. Faut dire, le rose faut aimer...
Bonne continuation,
-- Mister Jack (MJ) "Dans quel état j'erre ?"
Bonjour,
Merci pour la pensée et l'encouragement :-)
Par manque de temps je n'ai pas encore terminé la version 3 de mon
logiciel, mais par contre l'algo est complète (pour l'instant) depuis un
bout. Pour l'instant, le problème est de transformer en C (en DLL) la
partie du code VB concernant l'algo. J'ai étudié l'année dernière le C mais
j'ai dû arrêter de l'étudier pour vaquer à autre chose et j'en ai, à la
longue, oublié presque la totalité de l'étude (l'étude serait donc à
refaire). J'ai déjà, sous forme de procédure VB, l'algo servant
strictement au chiffrement.
Mais selon la demande de Christophe HENRY faudrait que j'amène une
explication détaillée de l'algo sur ce forum; mais je fournirais aussi la
procédure VB si cela peut aider à me faire comprendre mieux. Cette
procédure est donc temporaire jusqu'à ce qu'elle soit transformé en C (en
DLL que je puisse appeler à partir de logiciel fait en VB, en Delphi ou
autres). La transformation de ce code vers le C est nécessaire en vue d'un
chiffrement plus rapide, d'une vitesse de chiffrement plus acceptable pour
l'utilisateur du logiciel, vue la quantité plus importante de calcul par
rapport à la version précédente.
Je pourrais même amener cela sur ce forum dans les jours qui suivent.
J'ai le temps qui me manque au travers tout ça, mais je vais essayer
d'amener cela sous peu sous le titre : 'Algo RH'.
Bonne journée
Raymond
__________________________________________
"Mister Jack" <news@mjcie.net> a écrit dans le message de news:
43c82092$0$8138$626a54ce@news.free.fr...
...
Au passage, Raymond, si tu passes encore ici, je suis content de voir
qu'il y a eu du progrès. Même si tout n'est pas encore rose. Faut dire, le
rose faut aimer...
Bonjour, Merci pour la pensée et l'encouragement :-) Par manque de temps je n'ai pas encore terminé la version 3 de mon logiciel, mais par contre l'algo est complète (pour l'instant) depuis un bout. Pour l'instant, le problème est de transformer en C (en DLL) la partie du code VB concernant l'algo. J'ai étudié l'année dernière le C mais j'ai dû arrêter de l'étudier pour vaquer à autre chose et j'en ai, à la longue, oublié presque la totalité de l'étude (l'étude serait donc à refaire). J'ai déjà, sous forme de procédure VB, l'algo servant strictement au chiffrement. Mais selon la demande de Christophe HENRY faudrait que j'amène une explication détaillée de l'algo sur ce forum; mais je fournirais aussi la procédure VB si cela peut aider à me faire comprendre mieux. Cette procédure est donc temporaire jusqu'à ce qu'elle soit transformé en C (en DLL que je puisse appeler à partir de logiciel fait en VB, en Delphi ou autres). La transformation de ce code vers le C est nécessaire en vue d'un chiffrement plus rapide, d'une vitesse de chiffrement plus acceptable pour l'utilisateur du logiciel, vue la quantité plus importante de calcul par rapport à la version précédente. Je pourrais même amener cela sur ce forum dans les jours qui suivent. J'ai le temps qui me manque au travers tout ça, mais je vais essayer d'amener cela sous peu sous le titre : 'Algo RH'.
Bonne journée Raymond
__________________________________________
"Mister Jack" a écrit dans le message de news: 43c82092$0$8138$ ...
Au passage, Raymond, si tu passes encore ici, je suis content de voir qu'il y a eu du progrès. Même si tout n'est pas encore rose. Faut dire, le rose faut aimer...
Bonne continuation,
-- Mister Jack (MJ) "Dans quel état j'erre ?"
Francois Grieu
Dans l'article <43c66ab0$0$2136$, "Arnold McDonald (AMcD)" écrit:
juste quelques reflexions après 40' environ passées sur (le logiciel CryptFAST): http://arnold.mcdonald.free.fr/pdf/Swisscrypt.pdf
Deux points limpides à voir cette analyse:
1) Le chiffré est encodé sous forme de caractères visualisables, à raison de 6 bits par caractère non compté les retours à la ligne; c'est peu efficace et inutile dans le contexte, mais n'est PAS une faiblesse de sécurité.
2) Il y a quelque chose de particulier au début du chiffré, apparemment dans les 30 à 36 premiers bits; je conjecture qu'il s'agit de la somme, modulo 2^32, sur 32 bits, de tous les octets DU CLAIR; que cette somme est encodée octet de poids faible en tête, avec chaque octet énuméré bit de poids fort en tête et les bits résultants découpés en tranches de 6 bits, encodés bit de poids fort en tête selon la table de 2^6 caractères ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Si cette hypothèse est exacte (et à des erreurs mineures près, je suis assez affirmatif), cela constitue une faiblesse réelle du cryptosystème, puisque cette "checksum" du clair filtre en clair. Par exemple, si on connais tout le clair sauf un octet, on peut reconstituer exactement le clair à partir des 2 premiers caractères du chiffré.
Bref l'analyse superficielle du seul résultat produit par ce logiciel CryptFAST montre que la cryptographie mise en oeuvre comporte une erreur sérieuse et de niveau béotien.
L'argumentaire pour SwissCRYPT, de la même société, est du même niveau: je renvoie le lecteur à l'article <43c916d1$0$1161$ et fait la remarque que dans un système basé sur OTP, la sécurité est basée entièrement sur le secret de l'OTP aléatoire, lequel doit être à la disposition de celui qui déchiffre, et que l'argumentaire est muet sur la manière dont cette information nécessaire au déchiffrement serait accessible au programme de déchiffrement, mais pas à un adversaire.
Mon avis est de rester à distance prudente de CryptFast, SwissCrypt, et plus généralement des activités que promeuvent www.swisscrypt.com, www.pro.ch, et PCV SA.
François Grieu
Dans l'article <43c66ab0$0$2136$636a15ce@news.free.fr>,
"Arnold McDonald (AMcD)" <killspammers@free.fr> écrit:
juste quelques reflexions après 40' environ passées sur
(le logiciel CryptFAST):
http://arnold.mcdonald.free.fr/pdf/Swisscrypt.pdf
Deux points limpides à voir cette analyse:
1) Le chiffré est encodé sous forme de caractères
visualisables, à raison de 6 bits par caractère non compté
les retours à la ligne; c'est peu efficace et inutile dans
le contexte, mais n'est PAS une faiblesse de sécurité.
2) Il y a quelque chose de particulier au début du chiffré,
apparemment dans les 30 à 36 premiers bits; je conjecture qu'il
s'agit de la somme, modulo 2^32, sur 32 bits, de tous les octets
DU CLAIR; que cette somme est encodée octet de poids faible
en tête, avec chaque octet énuméré bit de poids fort en tête
et les bits résultants découpés en tranches de 6 bits, encodés
bit de poids fort en tête selon la table de 2^6 caractères
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Si cette hypothèse est exacte (et à des erreurs mineures près,
je suis assez affirmatif), cela constitue une faiblesse réelle
du cryptosystème, puisque cette "checksum" du clair filtre en
clair. Par exemple, si on connais tout le clair sauf un octet,
on peut reconstituer exactement le clair à partir des 2
premiers caractères du chiffré.
Bref l'analyse superficielle du seul résultat produit par ce
logiciel CryptFAST montre que la cryptographie mise en oeuvre
comporte une erreur sérieuse et de niveau béotien.
L'argumentaire pour SwissCRYPT, de la même société, est du
même niveau: je renvoie le lecteur à l'article
<43c916d1$0$1161$5402220f@news.sunrise.ch>
et fait la remarque que dans un système basé sur OTP,
la sécurité est basée entièrement sur le secret de l'OTP
aléatoire, lequel doit être à la disposition de celui qui
déchiffre, et que l'argumentaire est muet sur la manière
dont cette information nécessaire au déchiffrement serait
accessible au programme de déchiffrement, mais pas à un
adversaire.
Mon avis est de rester à distance prudente de CryptFast,
SwissCrypt, et plus généralement des activités que promeuvent
www.swisscrypt.com, www.pro.ch, et PCV SA.
Dans l'article <43c66ab0$0$2136$, "Arnold McDonald (AMcD)" écrit:
juste quelques reflexions après 40' environ passées sur (le logiciel CryptFAST): http://arnold.mcdonald.free.fr/pdf/Swisscrypt.pdf
Deux points limpides à voir cette analyse:
1) Le chiffré est encodé sous forme de caractères visualisables, à raison de 6 bits par caractère non compté les retours à la ligne; c'est peu efficace et inutile dans le contexte, mais n'est PAS une faiblesse de sécurité.
2) Il y a quelque chose de particulier au début du chiffré, apparemment dans les 30 à 36 premiers bits; je conjecture qu'il s'agit de la somme, modulo 2^32, sur 32 bits, de tous les octets DU CLAIR; que cette somme est encodée octet de poids faible en tête, avec chaque octet énuméré bit de poids fort en tête et les bits résultants découpés en tranches de 6 bits, encodés bit de poids fort en tête selon la table de 2^6 caractères ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Si cette hypothèse est exacte (et à des erreurs mineures près, je suis assez affirmatif), cela constitue une faiblesse réelle du cryptosystème, puisque cette "checksum" du clair filtre en clair. Par exemple, si on connais tout le clair sauf un octet, on peut reconstituer exactement le clair à partir des 2 premiers caractères du chiffré.
Bref l'analyse superficielle du seul résultat produit par ce logiciel CryptFAST montre que la cryptographie mise en oeuvre comporte une erreur sérieuse et de niveau béotien.
L'argumentaire pour SwissCRYPT, de la même société, est du même niveau: je renvoie le lecteur à l'article <43c916d1$0$1161$ et fait la remarque que dans un système basé sur OTP, la sécurité est basée entièrement sur le secret de l'OTP aléatoire, lequel doit être à la disposition de celui qui déchiffre, et que l'argumentaire est muet sur la manière dont cette information nécessaire au déchiffrement serait accessible au programme de déchiffrement, mais pas à un adversaire.
Mon avis est de rester à distance prudente de CryptFast, SwissCrypt, et plus généralement des activités que promeuvent www.swisscrypt.com, www.pro.ch, et PCV SA.
François Grieu
Paul Gaborit
À (at) Sat, 14 Jan 2006 16:21:36 +0100, "--- SwissCrypt.com ---" écrivait (wrote): [...]
Le fichier des code est généré d'une manière aléatoire dite "cérébrale" par opposition aux méthodes informatiques et mathématiques plus ou moins prévisibles. [...]
Quelques remarque sur ce passage :
1- Ce n'est pas parce que vous n'avez pas modélisé mathématiquement votre méthode qu'elle n'est pas modélisable mathématiquement. C'est comme la physique : même si vous n'y connaissez rien, les règles de la physique s'appliquent à vous. Ou comme la prose : même si vous ne savez pas ce que c'est vous en faites sans le savoir.
2- Votre outil fonctionne sur un ordinateur. Il utilise donc une méthode informatique... que vous le vouliez ou non.
3- Concernant le "plus ou moins prévisibles" : l'intérêt des mathématique est justement de pouvoir caractériser la "prévisibilité" d'une méthode ou d'un générateur aléatoire.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sat, 14 Jan 2006 16:21:36 +0100,
"--- SwissCrypt.com ---" <site@swisscrypt.com> écrivait (wrote):
[...]
Le fichier des code est généré d'une manière aléatoire dite "cérébrale"
par opposition aux méthodes informatiques et mathématiques plus ou moins
prévisibles.
[...]
Quelques remarque sur ce passage :
1- Ce n'est pas parce que vous n'avez pas modélisé mathématiquement
votre méthode qu'elle n'est pas modélisable mathématiquement. C'est
comme la physique : même si vous n'y connaissez rien, les règles de la
physique s'appliquent à vous. Ou comme la prose : même si vous ne
savez pas ce que c'est vous en faites sans le savoir.
2- Votre outil fonctionne sur un ordinateur. Il utilise donc une
méthode informatique... que vous le vouliez ou non.
3- Concernant le "plus ou moins prévisibles" : l'intérêt des
mathématique est justement de pouvoir caractériser la "prévisibilité"
d'une méthode ou d'un générateur aléatoire.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sat, 14 Jan 2006 16:21:36 +0100, "--- SwissCrypt.com ---" écrivait (wrote): [...]
Le fichier des code est généré d'une manière aléatoire dite "cérébrale" par opposition aux méthodes informatiques et mathématiques plus ou moins prévisibles. [...]
Quelques remarque sur ce passage :
1- Ce n'est pas parce que vous n'avez pas modélisé mathématiquement votre méthode qu'elle n'est pas modélisable mathématiquement. C'est comme la physique : même si vous n'y connaissez rien, les règles de la physique s'appliquent à vous. Ou comme la prose : même si vous ne savez pas ce que c'est vous en faites sans le savoir.
2- Votre outil fonctionne sur un ordinateur. Il utilise donc une méthode informatique... que vous le vouliez ou non.
3- Concernant le "plus ou moins prévisibles" : l'intérêt des mathématique est justement de pouvoir caractériser la "prévisibilité" d'une méthode ou d'un générateur aléatoire.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Pierre Vandevennne
Francois Grieu wrote in news:fgrieu- :
Bref l'analyse superficielle du seul résultat produit par ce logiciel CryptFAST montre que la cryptographie mise en oeuvre comporte une erreur sérieuse et de niveau béotien.
Allons Francois, tu es juste jaloux parce que tes competences mathematiques et crypologiques ne t'ont jamais permis de lancer une boite de mannequins!
Francois Grieu <fgrieu@francenet.fr> wrote in news:fgrieu-
461ADE.09443516012006@news5-e.proxad.net:
Bref l'analyse superficielle du seul résultat produit par ce
logiciel CryptFAST montre que la cryptographie mise en oeuvre
comporte une erreur sérieuse et de niveau béotien.
Allons Francois, tu es juste jaloux parce que tes competences mathematiques
et crypologiques ne t'ont jamais permis de lancer une boite de mannequins!
Bref l'analyse superficielle du seul résultat produit par ce logiciel CryptFAST montre que la cryptographie mise en oeuvre comporte une erreur sérieuse et de niveau béotien.
Allons Francois, tu es juste jaloux parce que tes competences mathematiques et crypologiques ne t'ont jamais permis de lancer une boite de mannequins!
JJG
Vous m'ennervez.
Moi aussi je vous lance un defis: prouvez que votre système est inviolable (defis con pour defis con).
