Si. http://www.sothink.com/product/flashdecompiler/download.htm
Ce logiciel décompile à volonté tous les SWF de toutes les versions de
flash apparues à ce jour. Le fait est qu'il n'y a aucun intéret à
décompiler un swf de saisie de code de CB, puisque le swf ne s'occupe que
de l'interface (les formes graphiques, les images, etc.). Il se contente
ensuite d'envoyer les données entrée à un php (ou cgi ou autre) coté
serveur sans faire aucune modification (rien de moins sécurisé que de
mettre l'algo de protection coté client !). Flash a plus le rôle de
l'esthétique ici.
Si. http://www.sothink.com/product/flashdecompiler/download.htm
Ce logiciel décompile à volonté tous les SWF de toutes les versions de
flash apparues à ce jour. Le fait est qu'il n'y a aucun intéret à
décompiler un swf de saisie de code de CB, puisque le swf ne s'occupe que
de l'interface (les formes graphiques, les images, etc.). Il se contente
ensuite d'envoyer les données entrée à un php (ou cgi ou autre) coté
serveur sans faire aucune modification (rien de moins sécurisé que de
mettre l'algo de protection coté client !). Flash a plus le rôle de
l'esthétique ici.
Si. http://www.sothink.com/product/flashdecompiler/download.htm
Ce logiciel décompile à volonté tous les SWF de toutes les versions de
flash apparues à ce jour. Le fait est qu'il n'y a aucun intéret à
décompiler un swf de saisie de code de CB, puisque le swf ne s'occupe que
de l'interface (les formes graphiques, les images, etc.). Il se contente
ensuite d'envoyer les données entrée à un php (ou cgi ou autre) coté
serveur sans faire aucune modification (rien de moins sécurisé que de
mettre l'algo de protection coté client !). Flash a plus le rôle de
l'esthétique ici.
"Glav" a écrit dans le message de
news:h20ir9$kg1$Si. http://www.sothink.com/product/flashdecompiler/download.htm
Ce logiciel décompile à volonté tous les SWF de toutes les versions de
flash apparues à ce jour. Le fait est qu'il n'y a aucun intéret à
décompiler un swf de saisie de code de CB, puisque le swf ne s'occupe que
de l'interface (les formes graphiques, les images, etc.). Il se contente
ensuite d'envoyer les données entrée à un php (ou cgi ou autre) coté
serveur sans faire aucune modification (rien de moins sécurisé que de
mettre l'algo de protection coté client !). Flash a plus le rôle de
l'esthétique ici.
Merci pour l'info, cela dit, le fait de pouvoir décompiler aussi facilement
des .swf pose le problème de la réutilisation de manière ultra facile des
éléments graphiques se trouvant à l'intérieur ainsi que du code (pour les
jeux par exemple). Quant à l'appli e-carte bleue, il y a au moins les
adresses IP des serveurs bancaires et le protocole de cryptage pour le login
/ password, non ?
"Glav" <spr3adster@gmail.com> a écrit dans le message de
news:h20ir9$kg1$1@aioe.org...
Si. http://www.sothink.com/product/flashdecompiler/download.htm
Ce logiciel décompile à volonté tous les SWF de toutes les versions de
flash apparues à ce jour. Le fait est qu'il n'y a aucun intéret à
décompiler un swf de saisie de code de CB, puisque le swf ne s'occupe que
de l'interface (les formes graphiques, les images, etc.). Il se contente
ensuite d'envoyer les données entrée à un php (ou cgi ou autre) coté
serveur sans faire aucune modification (rien de moins sécurisé que de
mettre l'algo de protection coté client !). Flash a plus le rôle de
l'esthétique ici.
Merci pour l'info, cela dit, le fait de pouvoir décompiler aussi facilement
des .swf pose le problème de la réutilisation de manière ultra facile des
éléments graphiques se trouvant à l'intérieur ainsi que du code (pour les
jeux par exemple). Quant à l'appli e-carte bleue, il y a au moins les
adresses IP des serveurs bancaires et le protocole de cryptage pour le login
/ password, non ?
"Glav" a écrit dans le message de
news:h20ir9$kg1$Si. http://www.sothink.com/product/flashdecompiler/download.htm
Ce logiciel décompile à volonté tous les SWF de toutes les versions de
flash apparues à ce jour. Le fait est qu'il n'y a aucun intéret à
décompiler un swf de saisie de code de CB, puisque le swf ne s'occupe que
de l'interface (les formes graphiques, les images, etc.). Il se contente
ensuite d'envoyer les données entrée à un php (ou cgi ou autre) coté
serveur sans faire aucune modification (rien de moins sécurisé que de
mettre l'algo de protection coté client !). Flash a plus le rôle de
l'esthétique ici.
Merci pour l'info, cela dit, le fait de pouvoir décompiler aussi facilement
des .swf pose le problème de la réutilisation de manière ultra facile des
éléments graphiques se trouvant à l'intérieur ainsi que du code (pour les
jeux par exemple). Quant à l'appli e-carte bleue, il y a au moins les
adresses IP des serveurs bancaires et le protocole de cryptage pour le login
/ password, non ?
Tu veux proteger tes elements graphiques ?
le droit d'auteur est la pour toi.
Tu veux proteger tes elements graphiques ?
le droit d'auteur est la pour toi.
Tu veux proteger tes elements graphiques ?
le droit d'auteur est la pour toi.
Et d'ou sors-tu cette affirmation ?
Il y a des tonnes de DLL et de logiciels crackes dans la nature. Des que
ca presente le moindre interet, il y a des gens pour le faire.
Les seuls logiciels non crackes sont ceux qui sont suffisamment nuls pour
que ca n'interesse personne....
Et d'ou sors-tu cette affirmation ?
Il y a des tonnes de DLL et de logiciels crackes dans la nature. Des que
ca presente le moindre interet, il y a des gens pour le faire.
Les seuls logiciels non crackes sont ceux qui sont suffisamment nuls pour
que ca n'interesse personne....
Et d'ou sors-tu cette affirmation ?
Il y a des tonnes de DLL et de logiciels crackes dans la nature. Des que
ca presente le moindre interet, il y a des gens pour le faire.
Les seuls logiciels non crackes sont ceux qui sont suffisamment nuls pour
que ca n'interesse personne....
Bonjour.
"Vincent Burel" a écrit dans le message
de news 4a41e381$0$17074$
> "Jean-Claude BELLAMY" wrote in
> message news:4a41dfa0$0$12660$
>> "Zeldus" a écrit dans le message de
>> news:4a414044$0$27809$
>>>
>>> Dans le cadre du développement d'un projet sous Windows avec
>>> Visual Studio ou CodeGear C++ , est il possible d'intégrer
>>> directement des fichiers multimédia (JPG, PNG, AVI, AAC et Flash)
>>> dans une DLL lors de sa création ?
>>>
>>> Le but est de pouvoir réutiliser ces fichiers depuis un
>>> executable via des fonctions tout en empêchant ou rendant
>>> difficile leur utilisation en dehors du cadre de l'aplpli (pour
>>> les droits d'auteurs), en particulier pour la vidéo.
>>
>>
>> Oui, on peut mettre tout ce qu'on veut en binaire grâce aux
>> ressources de type RCDATA.
>> http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx
>>
>>
>> Par contre, laisse tomber l'idée de protéger ces données !
>> Avec un éditeur/extracteur de ressources tel que "Resource Hacker"
>> (freeware génial), on fait absolument tout ce qu'on veut !
>> http://www.angusj.com/resourcehacker/
>
> il peut inclure des resources binaires, criptées.
> et justement intégrer dans la DLL les fonctions de decriptage...
> Décriptage qui peut se faire selon un mot de passe fournit par
> l'application (qui utilise cette DLL).
>
Navré d'être chiant, mais pour le principe, la culture générale et la
qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car cryptées,
seraient inexploitables même pour l'application légitime:
http://fr.wikipedia.org/wiki/Cryptographie
Et comme il a été dit, effectivement, l'application doit garder le
de l'opération de déchiffrement car il serait extrêmement facile de
récupérer et afficher le mot de passe avec une DLL fake.
Bonjour.
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> a écrit dans le message
de news 4a41e381$0$17074$ba4acef3@news.orange.fr
> "Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> wrote in
> message news:4a41dfa0$0$12660$ba4acef3@news.orange.fr...
>> "Zeldus" <no@email.com> a écrit dans le message de
>> news:4a414044$0$27809$426a74cc@news.free.fr...
>>>
>>> Dans le cadre du développement d'un projet sous Windows avec
>>> Visual Studio ou CodeGear C++ , est il possible d'intégrer
>>> directement des fichiers multimédia (JPG, PNG, AVI, AAC et Flash)
>>> dans une DLL lors de sa création ?
>>>
>>> Le but est de pouvoir réutiliser ces fichiers depuis un
>>> executable via des fonctions tout en empêchant ou rendant
>>> difficile leur utilisation en dehors du cadre de l'aplpli (pour
>>> les droits d'auteurs), en particulier pour la vidéo.
>>
>>
>> Oui, on peut mettre tout ce qu'on veut en binaire grâce aux
>> ressources de type RCDATA.
>> http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx
>>
>>
>> Par contre, laisse tomber l'idée de protéger ces données !
>> Avec un éditeur/extracteur de ressources tel que "Resource Hacker"
>> (freeware génial), on fait absolument tout ce qu'on veut !
>> http://www.angusj.com/resourcehacker/
>
> il peut inclure des resources binaires, criptées.
> et justement intégrer dans la DLL les fonctions de decriptage...
> Décriptage qui peut se faire selon un mot de passe fournit par
> l'application (qui utilise cette DLL).
>
Navré d'être chiant, mais pour le principe, la culture générale et la
qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car cryptées,
seraient inexploitables même pour l'application légitime:
http://fr.wikipedia.org/wiki/Cryptographie
Et comme il a été dit, effectivement, l'application doit garder le
de l'opération de déchiffrement car il serait extrêmement facile de
récupérer et afficher le mot de passe avec une DLL fake.
Bonjour.
"Vincent Burel" a écrit dans le message
de news 4a41e381$0$17074$
> "Jean-Claude BELLAMY" wrote in
> message news:4a41dfa0$0$12660$
>> "Zeldus" a écrit dans le message de
>> news:4a414044$0$27809$
>>>
>>> Dans le cadre du développement d'un projet sous Windows avec
>>> Visual Studio ou CodeGear C++ , est il possible d'intégrer
>>> directement des fichiers multimédia (JPG, PNG, AVI, AAC et Flash)
>>> dans une DLL lors de sa création ?
>>>
>>> Le but est de pouvoir réutiliser ces fichiers depuis un
>>> executable via des fonctions tout en empêchant ou rendant
>>> difficile leur utilisation en dehors du cadre de l'aplpli (pour
>>> les droits d'auteurs), en particulier pour la vidéo.
>>
>>
>> Oui, on peut mettre tout ce qu'on veut en binaire grâce aux
>> ressources de type RCDATA.
>> http://msdn.microsoft.com/en-us/library/aa381039(VS.85).aspx
>>
>>
>> Par contre, laisse tomber l'idée de protéger ces données !
>> Avec un éditeur/extracteur de ressources tel que "Resource Hacker"
>> (freeware génial), on fait absolument tout ce qu'on veut !
>> http://www.angusj.com/resourcehacker/
>
> il peut inclure des resources binaires, criptées.
> et justement intégrer dans la DLL les fonctions de decriptage...
> Décriptage qui peut se faire selon un mot de passe fournit par
> l'application (qui utilise cette DLL).
>
Navré d'être chiant, mais pour le principe, la culture générale et la
qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car cryptées,
seraient inexploitables même pour l'application légitime:
http://fr.wikipedia.org/wiki/Cryptographie
Et comme il a été dit, effectivement, l'application doit garder le
de l'opération de déchiffrement car il serait extrêmement facile de
récupérer et afficher le mot de passe avec une DLL fake.
Maintenant , comme il a été dit, tout peut se péter, il suffit de faire une
DLL fake, il suffit de désassembler la DLL etc... le fait est que dans la
pratique trés peu de produit (DLL ,EXE ...) protégé de la sorte, sont
crackés. Pour une simple raison : ceux qui auraient envi de le faire n'ont
ni la compétence ni le temps de l'acquérir, ceux qui auraient cette
compétence n'ont généralement aucun intérêt à perdre du temps là dessus.
Maintenant , comme il a été dit, tout peut se péter, il suffit de faire une
DLL fake, il suffit de désassembler la DLL etc... le fait est que dans la
pratique trés peu de produit (DLL ,EXE ...) protégé de la sorte, sont
crackés. Pour une simple raison : ceux qui auraient envi de le faire n'ont
ni la compétence ni le temps de l'acquérir, ceux qui auraient cette
compétence n'ont généralement aucun intérêt à perdre du temps là dessus.
Maintenant , comme il a été dit, tout peut se péter, il suffit de faire une
DLL fake, il suffit de désassembler la DLL etc... le fait est que dans la
pratique trés peu de produit (DLL ,EXE ...) protégé de la sorte, sont
crackés. Pour une simple raison : ceux qui auraient envi de le faire n'ont
ni la compétence ni le temps de l'acquérir, ceux qui auraient cette
compétence n'ont généralement aucun intérêt à perdre du temps là dessus.
In article <4a473818$0$12615$,
Vincent Burel wrote:
>Maintenant , comme il a été dit, tout peut se péter, il suffit de faire
>DLL fake, il suffit de désassembler la DLL etc... le fait est que dans la
>pratique trés peu de produit (DLL ,EXE ...) protégé de la sorte, sont
>crackés. Pour une simple raison : ceux qui auraient envi de le faire
>ni la compétence ni le temps de l'acquérir, ceux qui auraient cette
>compétence n'ont généralement aucun intérêt à perdre du temps là dessus.
Et d'ou sors-tu cette affirmation ?
Il y a des tonnes de DLL et de logiciels crackes dans la nature. Des que
ca presente le moindre interet, il y a des gens pour le faire.
Les seuls logiciels non crackes sont ceux qui sont suffisamment nuls pour
que ca n'interesse personne....
In article <4a473818$0$12615$ba4acef3@news.orange.fr>,
Vincent Burel <vincent.burel@nospam.wanadoo.fr> wrote:
>Maintenant , comme il a été dit, tout peut se péter, il suffit de faire
>DLL fake, il suffit de désassembler la DLL etc... le fait est que dans la
>pratique trés peu de produit (DLL ,EXE ...) protégé de la sorte, sont
>crackés. Pour une simple raison : ceux qui auraient envi de le faire
>ni la compétence ni le temps de l'acquérir, ceux qui auraient cette
>compétence n'ont généralement aucun intérêt à perdre du temps là dessus.
Et d'ou sors-tu cette affirmation ?
Il y a des tonnes de DLL et de logiciels crackes dans la nature. Des que
ca presente le moindre interet, il y a des gens pour le faire.
Les seuls logiciels non crackes sont ceux qui sont suffisamment nuls pour
que ca n'interesse personne....
In article <4a473818$0$12615$,
Vincent Burel wrote:
>Maintenant , comme il a été dit, tout peut se péter, il suffit de faire
>DLL fake, il suffit de désassembler la DLL etc... le fait est que dans la
>pratique trés peu de produit (DLL ,EXE ...) protégé de la sorte, sont
>crackés. Pour une simple raison : ceux qui auraient envi de le faire
>ni la compétence ni le temps de l'acquérir, ceux qui auraient cette
>compétence n'ont généralement aucun intérêt à perdre du temps là dessus.
Et d'ou sors-tu cette affirmation ?
Il y a des tonnes de DLL et de logiciels crackes dans la nature. Des que
ca presente le moindre interet, il y a des gens pour le faire.
Les seuls logiciels non crackes sont ceux qui sont suffisamment nuls pour
que ca n'interesse personne....
Bof, beaucoup de logiciels crackés ou présentés comme tels, sont des
freeware, des versions de démo, des version NFR, des versions
promotionnelles (un pourcentage important ne présente d'ailleurs aucun
intérêt, et ne sont jamais utilisé... ).
Bof, beaucoup de logiciels crackés ou présentés comme tels, sont des
freeware, des versions de démo, des version NFR, des versions
promotionnelles (un pourcentage important ne présente d'ailleurs aucun
intérêt, et ne sont jamais utilisé... ).
Bof, beaucoup de logiciels crackés ou présentés comme tels, sont des
freeware, des versions de démo, des version NFR, des versions
promotionnelles (un pourcentage important ne présente d'ailleurs aucun
intérêt, et ne sont jamais utilisé... ).
"Patrick 'Zener' Brunet"
wrote in message news:h1tl7d$h5o$"Vincent Burel" a écrit dans le
message de news 4a41e381$0$17074$"Jean-Claude BELLAMY" wrote in
message news:4a41dfa0$0$12660$"Zeldus" a écrit dans le message de
news:4a414044$0$27809$
[..]
Navré d'être chiant, mais pour le principe, la culture générale et
la qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car
cryptées, elles seraient inexploitables même pour l'application
légitime: http://fr.wikipedia.org/wiki/Cryptographie
Et comme il a été dit, effectivement, l'application doit garder le
contrôle de l'opération de déchiffrement car il serait extrêmement
facile de récupérer et afficher le mot de passe avec une DLL fake.
Je ne suis pas suffisamment calé pour garantir que mon vocabulaire
est adapté...
Par contre je sais , par la pratique, qu'il est trés simple de
mettre en place de "encodage" symétrique (XOR) qui ne pourra pas
être cassé sans avoir en même temps [1] l'algo de fabrication de la
série (d'encryption). [2] le mot de passe.
Si cela ne protège pas le contenu (tout flux, tout rendering... sont
capturables) cela protège l'intégrité de la DLL et cela empeche
toute corruption de celle ci.
Maintenant , comme il a été dit, tout peut se péter, il suffit de
faire une DLL fake, il suffit de désassembler la DLL etc... le fait
est que dans la pratique trés peu de produit (DLL ,EXE ...) protégé
de la sorte, sont crackés. Pour une simple raison : ceux qui
auraient envi de le faire n'ont ni la compétence ni le temps de
l'acquérir, ceux qui auraient cette compétence n'ont généralement
aucun intérêt à perdre du temps là dessus.
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid>
wrote in message news:h1tl7d$h5o$1@shakotay.alphanet.ch...
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> a écrit dans le
message de news 4a41e381$0$17074$ba4acef3@news.orange.fr
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> wrote in
message news:4a41dfa0$0$12660$ba4acef3@news.orange.fr...
"Zeldus" <no@email.com> a écrit dans le message de
news:4a414044$0$27809$426a74cc@news.free.fr...
[..]
Navré d'être chiant, mais pour le principe, la culture générale et
la qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car
cryptées, elles seraient inexploitables même pour l'application
légitime: http://fr.wikipedia.org/wiki/Cryptographie
Et comme il a été dit, effectivement, l'application doit garder le
contrôle de l'opération de déchiffrement car il serait extrêmement
facile de récupérer et afficher le mot de passe avec une DLL fake.
Je ne suis pas suffisamment calé pour garantir que mon vocabulaire
est adapté...
Par contre je sais , par la pratique, qu'il est trés simple de
mettre en place de "encodage" symétrique (XOR) qui ne pourra pas
être cassé sans avoir en même temps [1] l'algo de fabrication de la
série (d'encryption). [2] le mot de passe.
Si cela ne protège pas le contenu (tout flux, tout rendering... sont
capturables) cela protège l'intégrité de la DLL et cela empeche
toute corruption de celle ci.
Maintenant , comme il a été dit, tout peut se péter, il suffit de
faire une DLL fake, il suffit de désassembler la DLL etc... le fait
est que dans la pratique trés peu de produit (DLL ,EXE ...) protégé
de la sorte, sont crackés. Pour une simple raison : ceux qui
auraient envi de le faire n'ont ni la compétence ni le temps de
l'acquérir, ceux qui auraient cette compétence n'ont généralement
aucun intérêt à perdre du temps là dessus.
"Patrick 'Zener' Brunet"
wrote in message news:h1tl7d$h5o$"Vincent Burel" a écrit dans le
message de news 4a41e381$0$17074$"Jean-Claude BELLAMY" wrote in
message news:4a41dfa0$0$12660$"Zeldus" a écrit dans le message de
news:4a414044$0$27809$
[..]
Navré d'être chiant, mais pour le principe, la culture générale et
la qualité de la documentation du futur logiciel:
il vaudrait mieux que ces ressources soient *chiffrées*, car
cryptées, elles seraient inexploitables même pour l'application
légitime: http://fr.wikipedia.org/wiki/Cryptographie
Et comme il a été dit, effectivement, l'application doit garder le
contrôle de l'opération de déchiffrement car il serait extrêmement
facile de récupérer et afficher le mot de passe avec une DLL fake.
Je ne suis pas suffisamment calé pour garantir que mon vocabulaire
est adapté...
Par contre je sais , par la pratique, qu'il est trés simple de
mettre en place de "encodage" symétrique (XOR) qui ne pourra pas
être cassé sans avoir en même temps [1] l'algo de fabrication de la
série (d'encryption). [2] le mot de passe.
Si cela ne protège pas le contenu (tout flux, tout rendering... sont
capturables) cela protège l'intégrité de la DLL et cela empeche
toute corruption de celle ci.
Maintenant , comme il a été dit, tout peut se péter, il suffit de
faire une DLL fake, il suffit de désassembler la DLL etc... le fait
est que dans la pratique trés peu de produit (DLL ,EXE ...) protégé
de la sorte, sont crackés. Pour une simple raison : ceux qui
auraient envi de le faire n'ont ni la compétence ni le temps de
l'acquérir, ceux qui auraient cette compétence n'ont généralement
aucun intérêt à perdre du temps là dessus.
Bonsoir.
Seul le chiffre de Vernam est définitivement inviolable, mais ce n'est
transfert de la difficulté vers la transmission (ou création de part et
d'autre) de la clé.
Sur fr.misc.cryptologie, il y a régulièrement des gens qui viennent
avoir trouvé le Graal, et soit ils se font gentiment décevoir, soit ils
insistent, rajoutant sparadrap sur sparadrap sans pouvoir boucher le trou,
deviennent agressifs, et finissent par se rendre ridicules.
Fort heureusement, la quête de ce Graal reste ouverte, mais la simple
faisabilité théorique d'un tel protocole sans aucun des 4 travers
reste à démontrer. On en a pas mal discuté...
L'humain a cette caractéristique presque unique: le goût du jeu, de la
futilité.
Le simple fait de tenter de protéger un truc lance automatiquement un défi
que quelqu'un va tenter de relever.
Il y a aussi des gens qui sont intimement convaincus que toute forme de
secret est illégitime et doit être cassé.
Et plus ça résiste, plus il est motivant d'être celui qui va signer et
publier l'exploit.
Bonsoir.
Seul le chiffre de Vernam est définitivement inviolable, mais ce n'est
transfert de la difficulté vers la transmission (ou création de part et
d'autre) de la clé.
Sur fr.misc.cryptologie, il y a régulièrement des gens qui viennent
avoir trouvé le Graal, et soit ils se font gentiment décevoir, soit ils
insistent, rajoutant sparadrap sur sparadrap sans pouvoir boucher le trou,
deviennent agressifs, et finissent par se rendre ridicules.
Fort heureusement, la quête de ce Graal reste ouverte, mais la simple
faisabilité théorique d'un tel protocole sans aucun des 4 travers
reste à démontrer. On en a pas mal discuté...
L'humain a cette caractéristique presque unique: le goût du jeu, de la
futilité.
Le simple fait de tenter de protéger un truc lance automatiquement un défi
que quelqu'un va tenter de relever.
Il y a aussi des gens qui sont intimement convaincus que toute forme de
secret est illégitime et doit être cassé.
Et plus ça résiste, plus il est motivant d'être celui qui va signer et
publier l'exploit.
Bonsoir.
Seul le chiffre de Vernam est définitivement inviolable, mais ce n'est
transfert de la difficulté vers la transmission (ou création de part et
d'autre) de la clé.
Sur fr.misc.cryptologie, il y a régulièrement des gens qui viennent
avoir trouvé le Graal, et soit ils se font gentiment décevoir, soit ils
insistent, rajoutant sparadrap sur sparadrap sans pouvoir boucher le trou,
deviennent agressifs, et finissent par se rendre ridicules.
Fort heureusement, la quête de ce Graal reste ouverte, mais la simple
faisabilité théorique d'un tel protocole sans aucun des 4 travers
reste à démontrer. On en a pas mal discuté...
L'humain a cette caractéristique presque unique: le goût du jeu, de la
futilité.
Le simple fait de tenter de protéger un truc lance automatiquement un défi
que quelqu'un va tenter de relever.
Il y a aussi des gens qui sont intimement convaincus que toute forme de
secret est illégitime et doit être cassé.
Et plus ça résiste, plus il est motivant d'être celui qui va signer et
publier l'exploit.
