Proposition : cryptage pyramidale

Fp, p
Mais le papier conseille p1 (fin du chapitre 2)

Le soft ne correspond pas au papier ?
Quel système du papier est implémenté par le soft ?
Je préfèrerais ne pas avoir à apprendre Delphi..

Toutes les valeurs sont possible mais n'offre pas la même sécurité.
p > sécurité par attaque de test directes: 10^39 tests
p1 > sécurité par attaque de test directes: 10^47 tests (mais beaucoup
plus sécurisé pour l'attaque sur l'inversion des polynomes)

Aussi: dans le début du chapitre 3 du papier, quels sont les
ensembles notés [3,0] et (3,0) ?
C'est noté aragraphe 3 (10ème ligne environ) : [s,t ] est...et (s,t)

est...

M.K

tu ne veut pas refaire ton pdf avec etude et mise en oeuvre d'un cas
concret

Même un cas simple demande pas mal de travail. Calcul de polynome
d'inverses. Peut-être une fois si je trouve quelques bonnes heures devant
moi.

Quelles ligne je n'ai pas trouvé? Dans A indice i,j on a
- j varie de 1 à k
- et pour j=1 on a que i varie de 1 à 2^(k-1) donc les indices 2i et 2i-1
varient de 1 à 2^k
- pour j quelconque i varie de 1 à 2^(k-j) donc les indice 2i et 2i-1
varie

de 1 à 2^(k-j+1)

Mes excuses je me suis trompe en lisant trop vite.

tu ne veut pas refaire ton pdf avec etude et mise en oeuvre d'un cas
concret

Même un cas simple demande pas mal de travail. Calcul de polynome
d'inverses. Peut-être une fois si je trouve quelques bonnes heures devant
moi.
si un jour tu trouves un peu de temps

pour refaire ton pdf attardes toi sur
paragraphe c) codage multiple
soit (c1,c2...cm) fct de codage public
d(c1,c2,...)=id fct de decodage privee


cryptage du texte (y1,y2)=(c(t),(id-r)(t))
decryptage t=y2-d(y1)

avec c,d,r doc=r
et c ,d sont connus

donne du pb la qt trouvee r
donc moi je dis que
avec plusieurs couples
texte clair /texte crypte

je calcule id
pour rapeller voir pdf
d(c1,c2,c3,...)=id
je connais aussi (id-r)
pour rapeller fct de codage
(y1,y2)=(c(t),(X)(t))
X=(id-r)
il doit etre possible de simplifier la recherche d
parce que
d(c1,c2,c3,...)=id
en gros je fais des hypotheses a partir du calcul de ton "pivot" id
avec les couples texte clair /texte crypte
que j'ai trouve pour la methode

voir courrier precedent

mais bon c'est aussi clair que ton pdf donc ...



remy

"Thomas Pornin" <pornin@nerim.net> a écrit dans le message de news:
bpqo68$2er0$1@biggoron.nerim.net...

La cryptographie s'intéresse à la connaissance de l'information, et deux
informations sont considérées comme identiques si le passage de l'une à
l'autre et réciproquement est computationnellement aisé. C'est le cas de
vos clés K et K', qui sont fondamentalement deux représentations de la
même "convention secrète".
Je vous remercie de bien vouloir me consacrer un peu de votre temps

et de vous pencher sur mon problème. Je me permets cependant quelques
observations.
Je constate que, pour le commun des mortels, le concept de la symétrie
et de son inverse, se rattachent généralement à une vision géométrique des
choses, ou encore à une succession d'étapes dans un processus particulier
.
Pour le DES, il y a 16 rounds au chiffrement et repassage en ordre inverse
des 16 étapes au déchiffrement. Il y a bien là une symétrie dans les
successions directe et inverse. Pour le RSA, vous le savez, le déchiffrement
fait appel à une caractéristique fonctionnelle des groupes multiplicatifs, à
savoir qu'à chaque élément, correspond un élément inverse, et de là, il n'y
a qu'un pas au concept de l'asymétrie.
Dans la pratique, il se fait que tous les algorithmes dits symétriques
opèrent sur des blocs relativement petits de 64, 128 ou 256 bits
avec les mêmes clefs au déchiffrement et déchiffrement. Pour les algorithmes
asymétriques, les blocs sont nettement plus longs et avec des clefs
différentes au chiffrement et au déchiffrement. La faible vitesse de ces
derniers est une contrainte, mais est compensée par la possibilité de la
constitution d'une clef secrète, l'autre étant publique, pour autant que les
vecteurs soient suffisamment grands. Peut-on dire que le RSA deviendrait un
algorithme symétrique si on utilisait un modulo-N trop petit avec lequel il
est facile de calculer la clef inverse, alors que le même algorithme
deviendrait asymétrique si le modulo-N est suffisamment grand, bien que pour
les deux cas, les fonctionnalités restent identiques.

Le SED n'a rien de commun, du point de vue de sa fonctionnalité, avec
les
autres algorithmes symétriques pour lesquels il y a le repassage obligé au
déchiffrement par toutes les étapes faites en sens contraire au chiffrement.
Par contre, le SED présente des similitudes avec le RSA du point de vue de
sa fonctionnalité: dans les deux algorithmes, la clef joue le rôle
d'exposant
dans un espace formé par un groupe multiplicatif, avec la différence que
pour le RSA, l'espace contient un diviseur (N=p*q) et que l'exponentiation
s'opère arithmétiquement sur un vecteur, tandis que pour le SED, l'espace
est un nombre premier (=2^127-1) et que l'exponentiation s'opère sur une
matrice (127*127) modulo-2.
Le SED, avec sa clef privée (ou une clef fille), peut être enfoui dans
un circuit intégré avec la possibilité de l'utiliser pour chiffrer, mais
sans que l'utilisateur ne puisse connaître ou recomposer bit par bit la
clef. La programmation du système ClassicSys à été conçue dans cette
optique pour que, dans son évolution future, sa structure puisse être
conservée dans la réalisation d'un circuit intégré. Dans cette façon de
voir,

la"convention secrète des clefs K et K’, comme vous dites, ne serait plus
applicable, l'algorithme deviendrait-il asymétrique?
Evidemment, un circuit intégré émet des ondes électromagnétiques, et de
ce fait, un bidouilleur pourrait reconstituer la clef secrète. C'est ce que
m'a fait remarquer Yves Roggeman, chef de l'équipe cryptographie à
l'Université Libre de Bruxelles. Je sais bien que la chose est possible,
mais vraiment pas aisée à réaliser, même pour un bidouilleur chevronné. En
fait, je l'ai expérimenté moi-même au cours de ma carrière professionnelle
au CEN (Centre d'Etude Nucléaire de Mol Belgique).
(J'ouvre ici une parenthèse pour la petite histoire. Travaillant dans une
enceinte faradisée, le capteur électromagnétique, était raccordé à un
analyseur de fréquences, et placé à proximité du microprocesseur lequel
chiffrait un RSA avec la clef secrète. Pour améliorer le rapport
signal/bruit des émissions électromagnétiques, on a eu recours à des
blindages mais sans grands résultats. Finalement, le microprocesseur a été
mis dans une espèce de cavité réalisée en cuivre rouge et faite pour cette
application. Le couvercle de l'enceinte était fixé sur une surface plane
circulaire attenante au corps de la cavité. Les surfaces en contact ont été
argentées et rodées, puis fixées rigidement par une série de boulons placés
sur tout le pourtour. Ce n'est qu'après un fort serrage de tous les boulons
que les images à l'oscillo ont montré d'une manière étonnante le défilement
des bits de la clef secrète).

Je voudrais faire remarquer qu'il serait plus logique d'appliquer les
appellations symétrique et asymétrique par rapport à la fonctionnalité de
l'algorithme, et non par rapport aux conséquences obtenues pour les
caractéristiques de cet algorithme, qui découlent d'une application
déterminée.

Les deux concepts symétrie/asymétrie et clefs privée/publique sont
suffisamment explicites pour pouvoir définir leurs significations propres.
Il se fait que les portées de ces deux concepts ont toujours coïncidé
jusqu'ici, et de ce fait, l'évolution du langage courant dans la
littérature a fait un amalgame des deux concepts. Il n'empêche que
si une nouvelle méthode est proposée pour la cryptanalyse différentielle des
algorithmes symétriques, cela n'intéresse pas le SED. Par contre, s'il
s'agit d'une cryptanalyse différentielle des algorithmes asymétriques, la
chose devrait être examinée, mais je reste sceptique à ce sujet.

Pour conclure et sortir de cette petite controverse étymologique, je
plaide pour que l'algorithme SED puisse bénéficier de l'appellation
d'algorithme à fonctionnalité asymétrique.

En gros vous avez réinventé la roue.
Je ne crois pas avoir réinventé la roue "ANSI X9.17" que je

connaissais d'ailleurs, mais j'ai peut-être inventé le roulement à billes
qui pourrait utilement équiper la dite roue.

Si je me réfère à la fig. 13.1, page 546 du Handbook, vous verrez que la
clef K commune à A et B est la même au chiffrement et au déchiffrement, ce
qui n'est pas le cas avec le système de distribution de clefs de ClassicSys.
Je répète ce que j'ai déjà dit précédemment, Alice est seule à pouvoir créer
un message chiffré et Bob est seul à pouvoir le déchiffrer parce que les
deux clefs sont différentes. Vous me rétorquerez qu'un bidouilleur serait
capable de réaliser un faux message dont la création pourrait être attribuée
à l'autre correspondant. C'est exact. Mais pour ce faire, le bidouilleur
devra décompiler le logiciel et reconstituer le programme source, étant
donné que les deux clefs ne sont pas accessibles car elles sont chiffrées
dans le logiciel. Ceci n'est pas suffisant en tant que protection software,
mais pourrait devenir suffisant dans le cas d'une protection hardware, c-à-d
réaliser l'enfouissement de l'algorithme dans un circuit intégré. Le
logiciel
ClassicSys, considéré comme une maquette, a pour but de montrer la
faisabilité des possibilités offertes par l'algorithme SED enfoui dans un
IC.

Tout protocole utilisant SED pourrait utiliser à la place un AES ou un
RC5.

Ceci n'est pas exact. La commande du mode chiffrement ou déchiffrement
dans ClassicSys s'effectue par l'utilisation d'un statut de l'opération
choisie. Pour un bidouilleur en herbe, il suffit de changer quelques bits
dans ce statut pour modifier la commande Chiffrement/déchiffrement si
l'algorithme SED est remplacé par un algorithme symétrique.

La prochaine version (fin 2003) de ClassicSys sera caractérisée par la
possibilité d'une transmission de la clef privée du TA au nouvel affilié par
un chiffrement Diffie-Hellmann avec 1024 bits. Je ne crois pas qu'on doive
craindre Oscar, l'homme du milieu. Si on prend la précaution de pouvoir
lire l'empreinte hash de la clef Diffie-Helmann sur le site du TA et que
cette même empreinte figure aussi à la fenêtre principale du logiciel de
l'affilié, la sécurité est acquise.

Je voudrais vous soumettre la méthode que je préconise pour la
réalisation d'émails recommandés à réaliser dans le logiciel ClassicSys.

Alice prend une affiliation à ClassicSys et reçoit une clef privée avec
un numéro public d'affiliation de 44 bits. La clef privée ne pourra être
utilisée qu'en mode de chiffrement et que d'autre part, la clef conjuguée
n'est connue que par le TA. Si Alice désire être une affiliée enregistrée,
elle
fera parvenir au responsable de la gestion du TA un virement bancaire d'une
somme minimum de 0,03 Euro. Ce n'est pas ruineux, et en Belgique,
c'est le montant minimum pour un virement. Ce virement serait introduit,
soit à un terminal "self bank" dans les locaux de la banque, soit par une
procédure de "HomeBanking" à domicile, et accompagné d'une
communication écrite: "Virement par selfbank" ou par "Virement par Home
Banking". L'intérêt de cette procédure est d'obliger l'expéditeur à
introduire nécessairement son code PIN. Le responsable de la gestion du TA
pourra, à la réception du virement, vérifier la concordance de l'identité
donnée à l'affiliation et celle figurant sur le virement. Si les deux
identités sont identiques, l'affiliation est enregistrée. Cette procédure
est probablement plus sécurisante que celle de l'envoi d'une photocopie des
documents d'identité. Bien que mon épouse soit déjà en possession d'une
carte d'identité à puce, la généralisation de ce procédé n'est pas encore
pour demain.

Alice clique sur le bouton "émail recommandé", choisit son correspondant
Bob et inscrit son message. Lorsque celui-ci est entièrement écrit, Alice
clique sur le bouton "Envoyer" et son logiciel effectue les opérations
suivantes.
- Calcul de l'empreinte hash du texte clair (vecteur de 128 bits);
- Chiffrement de l'empreinte par la clef privée;
- Envoi au TA en mode on line des trois blocs suivants:
-1) Statut du message + n° affiliation Alice + n° affiliation Bob;
-2) Empreinte hash du message clair;
-3) Chiffrement de l'empreinte avec la clef privée d'Alice qui
constitue une signature.
- Chiffrement et envoi émail du message chiffré à Bob

A la réception de la communication d'Alice, le TA, qui peut
recalculer la clef privée d'Alice, vérifie que la signature est correcte.
1) Si celle-ci est correcte, le TA envoie deux récépissés.
a) envoi à Alice de six blocs chiffrés avec la clef
inverse privée d'Alice: les trois blocs précédents + le bloc formé par la
somme XOR des trois blocs précédents et le moment de la réception par le TA
des trois blocs d'Alice + l'empreinte hash des quatre blocs qui précédent +
la signature de
l'empreinte hash précédente par la clef privée du TA.
b) Envoi à Bob de six blocs chiffrés avec la clef
inverse privée de Bob (mêmes six blocs envoyés à Alice)
2) Si la signature n'est pas correcte, notification + abandon.

A la réception du message chiffré et recommandé d'Alice, le logiciel de
Bob procède de la même manière que celui d'Alice. Après le déchiffrement,
vérification que l'empreinte hash du texte clair d'Alice est correct. Si
l'empreinte hash est correcte, envoi au TA de trois blocs:
-1) Statut du message reçu + n° affiliation Alice +n° affiliation°
Bob;
-2) Empreinte hash du message clair reçu;
-3) Chiffrement de l'empreinte hash avec la clef privée de Bob, ce
qui constitue une signature par Bob

A la réception par le TA de la communication de Bob on line, même
processus comme ci-dessus, le TA envoi les deux récépissés à Alice et Bob.

Grâce aux quatre récépissés, Alice et Bob ont la certitude de
l'intégrité, la confidentialité, la non révocation du message envoyé et les
moments d'envoi et de réception du recommandé. Alice, tout autant que Bob,
pourront toujours par la suite faire usage des récépissés signés par le TA
et authentifiables par qui que ce soit.

Ceci n'est qu'un projet à méditer.

Merci et bien à vous,

Emile Musyck

donc si je comprends bien
apres une lecture en diagonale

alice paye et recupere une cle
bob aussi


alice veut envoyer un texte a bob

alice s'identifie "au tiers de confiance"
et demande au meme tiers de confiance une cle
pour chiffrer un msg a bob
alice recupere la cle de chiffrement code avec sa cle
privee chiffre son msg et l'envoie a
bob

et bob qd il veut decoder le msg
fait l'operation inverse
s'identifie dit qu'il a recu un msg d'alice
et demande une cle de dechiffrement codee avec sa cle
privee


si j'ai bien compris
alice et bob partagent un secret commun
chiffre avec deux cles differentes cle privee d'alice et cle
privee de bob


cela donne quoi si j'ai les 2 msg ceux qui
contiennent la cle de chiffrement/dechiffrement du texte ???
code avec les cles privees d'alice et de bob

a+ remy

Peut-on dire que le RSA deviendrait un algorithme symétrique si on
utilisait un modulo-N trop petit avec >lequel il est facile de calculer la

clef inverse, alors que le même algorithme deviendrait asymétrique si le

modulo-N est suffisamment grand, bien que pour les deux cas, les
fonctionnalités restent identique

L'intérêt de RSA est que le calcul de p et q (grands nombres permiers) est
beaucoup plus facile que la décomposition du produit n=pq pour retrouver p
et q. La puissance de calcul pour la décomposition est beaucoup plus grand
que la puissance de calcul qui permet d'inventer p et q (en milliard de fois
plus et même davantage). C'est cela qui est tout l'intérêt de RSA. En
calculant des nombres premiers p et q à la limite de la puissance de nos
ordinateurs, la puissance nécessaire pour décomposer devient complètement
hors d'accès de tout calcul. C'est cela le fondement de la méthode RSA.
C'est ce qui la rend "incassable". Fabriquer la clé est accessible au
calcul, la décomposer ne l'est pas, d'où la sécurité.

Avec p et q petit, RSA n'a aucun intérêt.Car on peut trouver les clés
inverses. Il n'y a donc plus aucune sécurité.

De façon général, une méthode asymétrique est intéressante uniquement s'il
est impossible de trouver une clé secrète à partir de la clé publique. Dans
le cas contraire, il ne s'agit pas d'une clé qu'on peut rendre publique.
Tout l'intérêt de la méthode asymétrique est de pouvoir rendre la clé de
cryptage publique au su et vu de tous : tout le monde peut me crypter avec
ma clé publique sans aucun échange préalable (si c'est bien ma clé). Sinon
on a rien gagné par rapport à une méthode symétrique : tout doit rester
secret.

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> a écrit dans le
message de news: bq4tv7$qa3$1@news.tiscali.fr...

Peut-on dire que le RSA deviendrait un algorithme symétrique si on
utilisait un modulo-N trop petit avec >lequel il est facile de calculer la

clef inverse, alors que le même algorithme deviendrait asymétrique si le

modulo-N est suffisamment grand, bien que pour les deux cas, les
fonctionnalités restent identique

Avec p et q petit, RSA n'a aucun intérêt.Car on peut trouver les clés
inverses. Il n'y a donc plus aucune sécurité.
Le seul intérêt du RSA avec p et q petits est d'ordre didactique où il

est possible d'effectuer un chiffrement complet à titre de démonstration à
l'aide d'une petite calculette à main. Je voulais seulement insister sur le
fait
qu'un RSA avec des petits ou des grands facteurs premiers p et q garde
toujours une même fonctionnalité.

De façon général, une méthode asymétrique est intéressante uniquement s'il
est impossible de trouver une clé secrète à partir de la clé publique.
Le cas de mon algorithme SED est particulier en ce sens qu'il fait appel

à
deux clefs. Si on peut s'arranger pour qu'on puisse utiliser une clef, sans
la
connaître matériellement, et que l'autre clef est utilisée par un organisme
de
confiance, ne retrouve-t-on pas là les conditions d'un fonctionnement
asymétrique? Je dois dire que je ne voie pratiquement pas d'autres
applications valables de mon algorithme hormis celle-là, le système
ClassicSys. Avec le RSA, on fait connaître publiquement sa clef privée. Avec
ClassicSys, on fait connaître publiquement son numéro d'affiliation et
l'organisme de confiance "se débrouille" pour faire parvenir la clef
conjuguée à l'interlocuteur choisi Éventuellement un opposant qui pourrait
prendre connaissance des informations échangées n'est pas capable de
reconstituer la clef de session échangée. Cela suppose que la clef privée
d'un affilié doit être protégée physiquement au domicile de son détenteur.

"Pierre Vandevennne" <pierre@datarescue_ns.com> a écrit dans le message de
news: Xns943BA26F84D9pierredatarescue@195.238.3.180...

"Emile Musyck" <emilemusyck@skynet.be> wrote in
news:3fbe80f0$0$22028$ba620e4c@reader3.news.skynet.be:
Cette vue un peu hautaine me paraît un peu déplacée. Je suis
certain que des personnes comme François Grieu, Thomas Pornin et
autres contributeurs que j'oublie disposent de tout le bagage
mathématique nécessaire, mais j'imagine qu'ils ont d'autres choses à
faire.
Je suis navré si quelqu'un a pris ombrage de mes explications. Je

comprends parfaitement que le temps disponible à chacun est certes limité et
ne permet pas de se consacrer à des réponses qui, à première vue n'en valent
pas peut-être la peine. Je ne désire faire que des amis.

ClassicSys me parait impressionnant. Trop, peut-être.
Ma réponse du 8/11/03 à la demande d'avis du 15/10/03 est-elle trop

compliquée à comprendre pour un premier contact avec le SED?

D'abord d'un point de vue purement rhétorique: cette phrase implique que
si on n'est pas persuadé de l'incassabilité de ClassicSys et qu'on a lu
ce papier, on ne l'a pas compris. C'est un peu simple, et cela enlève
beaucoup d'intérêt au débat. Que pense Mieczislaw de ClassicSys au fait?
J'ai une très grande admiration pour Mieczislaw Kula. C'est lui qui a

déniché le SED sur internet. Sans que je lui demande, il a rédigé le papier
de la cryptanalyse du SED, ce qui m'a été très précieux pour la suite de mes
travaux. Quand j'évalue la somme d'énergie que Mieczislaw a dû déployer
pour la rédaction de ce papier, et tenant compte de sa compétence, j'ai tout
de même là une certaine assurance sur la fiabilité de la méthode proposée.
Mieczislaw n'a abordé que l'aspect robustesse du SED et ne s'est pas penché
sur ClassicSys. Je pense qu'il n'y a pas lieu de devoir comprendre le papier
de Mieczislaw pour pouvoir vérifier le bon usage du SED dans ClassicSys. Un
éventuel contact avec Mieczislaw ne serait peut-être pas superflu, mais pour
cela, je n'ai pas assez de compétences en anglais.

Concernant la cryptanalyse, je ne crois jamais que quelqu'un
s'aventurerait à entreprendre 2^64 tests de l'algorithme placé dans une
boîte noire, chaque test pouvant coûter plusieurs secondes de calcul, afin
de pouvoir recomposer la clef de chiffrement. Malgré cela, j'ai introduit,
dans la dernière version du SED, une application MAM entre les deux
applications DLM, ce qui me coûte moins d'un % du temps de calcul en plus.
La cryptanalyse du SED doit se baser nécessairement sur certaines
caractéristiques qui lient les vecteurs clair et chiffré. C'est précisément
cette relation d'isomorphisme que Mieczislaw a mis en évidence. Il faut dire
que les deux applications DLM ont en commun certains éléments vitaux, à
savoir une même structure des exponentielles avec 1+1=0, bien qu'exprimés
dans des bases logarithmiques différentes, tandis que dans le MAM, on garde
le même exposant mais avec la différence que 1+1=2. J'ai fait part à
Mieczislaw de cette nouvelle orientation. Je ne vois pas la possibilité de
mettre en
oeuvre une cryptanalyse plus poussée, dans le but de mettre en évidence une
nouvelle relation d'isomorphisme englobant la suite des applications DLM/63,
MAM et DLM/30. Je n'ai pas non plus les compétences nécessaires question
d'isomorphisme, je préfère m'abstenir de toutes observations à ce sujet.
Je n'aime pas mendier des tuyaux de cryptanalyse à de grands experts,
Ceux-ci ne disposent pas toujours, effectivement, ni de la motivation ni du
temps nécessaire,
Bravo tout de même à Mieczislaw.

les algorithmes pleuvent, sans qu'ils répondent vraiment à un besoin.
Le SED n'a d'intérêt que dans un cryptosytème tel que ClassicSys. Ne

pensez vous pas qu'il y a tout de même un petit plus introduit par
ClassicSys? En principe, tous les buts des procédures qui sont réalisées
avec le RSA, peuvent aujourd'hui, ou pourront demain, être réalisées avec
ClassicSys. Avec le RSA, le mur de protection est la difficulté de
factoriser N (=p*q), tandis que pour ClassicSys, c'est l'inviolabilité de la
clef secrète utilisée par l'organisme de confiance. Cela signifie que si on
veut faire usage de cette clef, il faut se mettre en relation on line avec
le TA, ce qui se fait aisément et ne dure que deux-trois secondes.
ClassicSys est toujours un logiciel d'expérimentation et ce n'est un secret
pour personne, j'assure seul, pour l'instant, la gestion administrative du
TA. La clef secrète du TA se trouve dans l'ordinateur qui assure la fonction
du TA principal, lequel ordinateur est mis dans un local à accès protégé, à
l'Université Libre de Bruxelles. Le TA administratif se trouve à mon
domicile, et je vérifie chaque jour sur le TA, la présence de nouveaux
affiliés. La demande ne dure pas plus d'une seconde. C'est vrai, je suis
déçu par le manque d'intérêt des internautes à expérimenter ce nouveau
système. Pourquoi?. Est-ce un manque de confiance?
Peut-être ne veulent-ils pas se fatiguer à tester un nouveau système
totalement inconnu, qui ne dispose pratiquement d'aucune référence, et
devoir verser 0,03 Euro pour être un affilié enregistré, alors qu'il faut
débourser 1300 Euro chez Verisign pour bénéficier d'une sécurité
informatique probablement
équivalente. Revenons à nos amis Alice et Bob. Si Alice veut envoyer un
émail à Bob, avec l'obligation pour les deux correspondants de faire usage
de leur clef privée, afin d'obtenir pour Alice, une clef exclusive de
chiffrement, et pour Bob, la clef conjuguée exclusive de déchiffrement, et
que la vitesse de chiffrement cet émail est du même ordre de grandeur des
algorithmes symétriques, est-cela un fait banal?

Classicsys pourrait, si l'on en admet la solidité, remplacer certains
protocoles complexes reposant actuellement sur le RSA mais ce que
Monsieur Musyk présente comme un avantage est en fait un inconvénient:
il n'y a pas énormément de cryptographes professionnels qui vont
s'intéresser à un système qui prive les majors du domaine de revenus.
Soyez rassurés, Emile Musyck n'a aucune arrière pensée lucrative, la

cryptographie, c'est sa passion, Si vraiment mon système devait, comme vous
dites, priver les majors en ce domaine, de revenus, n'oublions pas tout de
même qu'en fin de course c'est l'utilisateur final qui paie!

je pense pouvoir affirmer que personne ne pense "ridicule" - c'est sans
aucun doute un bel effort, on le respecte et puis on retourne travailler.
Eh oui, le travail anoblit l'homme et devient une source de joie, c'est

bien pourquoi je ne renonce pas.

Timeo doli frangentur inanes
Pouvez-vous satisfaire ma curiosité, je ne saisis pas réellement le sens de

cette citation, je n'ai pas fait de latin, faut-il comprendre "Je crains que
les fourberies trompent les infatués". ? Est-ce le sens que vous lui donnez?
Qui est l'auteur de cette citation?

Amicalement

Emile

Bonsoir,

On Sat, 29 Nov 2003, Emile Musyck wrote:

[...]

ClassicSys est toujours un logiciel d'expérimentation et ce n'est un secret
pour personne, j'assure seul, pour l'instant, la gestion administrative du
TA. La clef secrète du TA se trouve dans l'ordinateur qui assure la fonction
du TA principal, lequel ordinateur est mis dans un local à accès protégé, à
l'Université Libre de Bruxelles. Le TA administratif se trouve à mon
domicile, et je vérifie chaque jour sur le TA, la présence de nouveaux
affiliés. La demande ne dure pas plus d'une seconde. C'est vrai, je suis
déçu par le manque d'intérêt des internautes à expérimenter ce nouveau
système. Pourquoi?. Est-ce un manque de confiance?
Peut-être ne veulent-ils pas se fatiguer à tester un nouveau système
totalement inconnu, qui ne dispose pratiquement d'aucune référence, et
devoir verser 0,03 Euro pour être un affilié enregistré, alors qu'il faut
débourser 1300 Euro chez Verisign pour bénéficier d'une sécurité
informatique probablement
équivalente.

Une petite attaque sans fondement. Pensez-vous vraiment que les moyens
techniques mis en place par VeriSign pour vendre leurs certificats 1300
Euros se limitent à 1 PC dans une université et un autre au domicile de
son PDG? Ca ne tient pas debout. Vous devriez aller les voir, à Mountain
View, et vous ne verriez qu'une partie des moyens techniques.

Ne parlez pas de prix si ça n'est pas votre métier. Même des "experts"
arrivent à se casser la gueule en parlant non pas de prix, mais de coût,
ce qui est plus facile (voir par exemple le papier de Bernstein décrivant
sa machine à factoriser massivement parallèle, et Shamir, qui se met
aussi dans la peau d'un industriel).

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Jh 28 ans, informaticien, cherche femme sur Chartres.
-+- PGeorges in GNU - Elle est oû la Charte du groupe ? -+-