OVH Cloud OVH Cloud

Cryptosystème ClassicSys

98 réponses
Avatar
Emile
Bonjour,

J'ai fait une refonte de la description de l'algorithme SED et son
application ClassicSys. Vous pouvez t=E9l=E9charger ce texte =E0 l'URL
http://fr.wikipedia.org/wiki/Utilisateur:Emile_Musyck

La copie des conclusions figurant au bas de l'=E9tude est reprise ci-
apr=E8s.

Si vous =EAtes jeune dipl=F4m=E9 en informatique ou prochainement dipl=F4=
m=E9,
avec une bonne connaissance de l'anglais, que vous ma=EEtrisez Turbo-
Pascal et l'outil de d=E9veloppement DELPHI, pourquoi ne vous
investiriez vous pas dans une =E9tude approfondie de l'algorithme SED?
Avec ces connaissances, vous pourrez offrir vos services =E0 Google et
leur proposer d'am=E9liorer la messagerie Gmail en reprenant les
principes de ClassicSys, pourquoi pas? Si vous pouvez relever ce d=E9fi
l=E0, vous enjamberez plusieurs =E9chelons hi=E9rarchiques =E0 la fois. En
tant que senior, j'aiderais volontiers un jeune enthousiaste =E0 relever
ce d=E9fi.

Conclusions (extrait de l'URL susmentionn=E9e)

L=92immunit=E9 d=92un algorithme de chiffrement =E0 une cryptanalyse peut =
se
mesurer par le caract=E8re al=E9atoire du bloc chiffr=E9 par rapport au blo=
c
clair. Cette mesure ne peut pas s=92effectuer sur des blocs de 128 bits,
par contre une simulation d=92une double exponentiation dans des corps
finis pour n=3D7 ou n=3D17 est r=E9alisable et donne les indices de
confiance respectivement de 0.86 et 0.9998 pour le caract=E8re al=E9atoire
du bloc chiffr=E9 par rapport au bloc clair. Cette simulation ne peut se
faire qu=92avec l=92algorithme SED.

La transmission des mails en mode chiffr=E9 est le souhait de tous,
mais il faut bien reconna=EEtre 99,99 % des mails passent encore
toujours en clair malgr=E9 une panoplie de logiciels qu=92on peut
t=E9l=E9charger gratuitement. Il n=92existe aucun logiciel qui permette de
se trouver automatiquement en mode de chiffrement avec la clef de
session d=E9termin=E9e par le logiciel pour un contact d=E9fini, rien qu=92=
en
cliquant sur ce contact. Le logiciel ClassicSys (Free) comble cette
lacune et ne fait pas usage de l=92algorithme RSA.

L=92adoption g=E9n=E9ralis=E9e par les internautes d=92une clef USB conten=
ant
l=92algorithme SED pour chiffrer toute information circulant sur la
toile =E0 l=92aide d=92une clef de session transmise par un Organisme de
Confiance permettrait d=92=E9radiquer tout virus ou spam.

Emile

10 réponses

Avatar
Sylvain SF
Emile wrote on 31/07/2008 16:50:

En fait, SED est censé avoir quoi de plus qu'un bon vieil AES des
familles ?



[...] pour le DES, [] la petite taille des boîtes de substitution est
visiblement la cause des clefs faibles et semi-faibles.



soit 20 clés sur 2^56, tu penses que ça a déjà géné quelqu'un ?
que l'on ne saurait pas les écarter ? que ne pas savoir combien
de "clés faibles" (tu précisera le concept si besoin) existe dans
SED est "un plus" par rapport à cette connaissance là ?

Le nombre de rondes dans l’AES est une valeur qui a été estimée
suffisante pour ne pas permettre une cryptoanalyse linéaire ou
différentielle, mais elle ne correspond pas au résultat d’un calcul
ayant pour but de rechercher la valeur optimum.



l'affirmation me parait gratuite, tu insinues du mystique dans ce
choix des rondes pour en fait ne pas répondre à une question simple.

[...]



L'avantage premier du chiffrement généralisé pour la messagerie
électronique est certes la confidentialité, mais il y a un autre
avantage tout aussi important, c'est la possibilité d'une
vérification de l'origine du message.



non ?!? et tu n'as pas remarqué que c'est pour cela qu'existent
a) le chiffrement (du contenu), b) la signature ?
il t'aurait vraiment échappé que ces 2 choses existent ?

Si l'Organisme de Confiance applique la consigne d'attribuer des
clefs de session qu'aux correspondants enregistrés, on pourrait


> de cette manière éradiquer tous les virus et spams.

"organisme de confiance" est un néologisme pour "autorité de confiance
à qui on ne doit pas faire confiance (de part sa faculté à révéler
toutes les clés)" ?

Manuel as répondu en matheux pour douter de tes affirmations, en
praticien de la crypto. j'ajoute que ton système est une imposture
liberticide; je rajouterais en physicien (comptant 0, 1, l'infini)
que soit personne n'a de "clé de session" et donc personne ne peut
rien échanger, soit tout le monde a un clé et les virus et spams
n'ont aucun souci à ce faire; encore plus clairement: filtrer sur
qui a un chiffrement SED est aussi inutilement inefficace que filtrer
sur quel mot est présent, quel host envoie le mail, de quelle couleur
est le texte.

Sylvain.
Avatar
Emile
On 28 juil, 11:05, Stéphane CARPENTIER
wrote:

Parce que ça ne marche pas. Bon, honnêtement, je n'ai pas essayé, j' ai
juste téléchargé le zip pour voir ce qu'il y avait dedans et j'ai su que ça
ne marcherait pas.



Comment avez vous su que cela ne marcherait pas quand vous avez vu ce
qui avait dans le ZIP? En fait, en décompressant le ZIP on obtient
huit fichiers:

ClassicTaPr.0E5 (306 oct). (la clef publique Diffie-Helmann)
ClassicTit.eng (273.408 oct) (les textes en anglais)
ClassicTit.fra (274.432 oct) (les textes en français)
ClassicTit.exe (1.079.296 oct) (application)
ClassicTit_E.cnt (609 oct) (textes en anglais)
ClassicTit_F.cnt (717 oct) (textes en français)
ClassicTit_E.hlp (23.183 oct) (aide en anglais)
ClassicTit_F.hlp (24.550 oct) (aide en français)

Ces huit fichiers sont à enregistrer par exemple dans le dossier
ClassicTit, ce dernier étant placé dans le dossier Program Files.
En cliquant sur l'application, il y a huit champs à remplir:

- Langues (F/A)
- Utilisateurs (Employé, indépendant, particulier)
- Adresse IP (inscrire 164.15.123.79)
- Smtp (voir FAI)
- Pop3 (voir FAI)
- Nom de compte (voir FAI)
- Mot de passe (voir FAI)
- Cliquer 8 fois (création clef publique Diffie-Helmann
destinataire)

Lorsque les huit champs sont remplis, cliquer su OK. Une nouvelle
fenêtre s'ouvre concernant l'identité de l'affilié. Lorsque les champ s
sont remplis, cliquer sur CHIFFRER puis ENVOYER. Il y a deux envois
consécutifs à effectuer. Le premier est chiffré avec la clef D-H, le
second avec la clef de l'affilié. Consulter éventuellement l'aide s'il
y a des difficultés.

Ca manque de rigueur tout ça.



Une expérience intéressante à effectuer. Si on modifie un seul bit d u
message chiffré, le logiciel le détecte et donne l'avertissement "Les
données sont altérées". Lorsque l'expéditeur a terminé l'écritu re du
message, le logiciel crée le bloc hash de l'ensemble du message et à
la réception, le même bloc hash est recalculé. Si les deux hash ne
sont pas identiques, le logiciel donne l'avertissement "Les données
sont altérées". Le destinataire reçoit le bloc hash et la signature
qui est formée par le chiffrement du bloc hash avec la clef privée de
l'expéditeur. Pour vérifier la signature, le destinataire clique sur
le shake-hand et l'autorité de confiance lui envoie un certificat de
la vérification de la signature. Je me demande combien de logiciels de
messagerie effectuent ce genre de service.

Il y a un autre truc qui montre le manque de rigueur et qui fait que
j'affirme que ça ne marche pas. Je te laisse trouver par toi même.



Je n'ai toujours pas trouvé le truc qui montre le manque de rigueur.

Emile
Avatar
mpg
Le (on) vendredi 01 août 2008 17:52, Emile a écrit (wrote) :

la vérification de la signature. Je me demande combien de logiciels de
messagerie effectuent ce genre de service.



Bah thunderbird avec enigmail (et gnupg derrière) donc fait tout à fait ce
genre de choses, sauf que bien sûr ce n'est pas basé sur un tiers de
confiance.

Puisqu'on parle du tiers de confiance, soyons clair :je ne veux pas qu'un
tiers, fut-il proclamé « de confiance » puisse lire ma messagerie privée et
c'est pour ça que je ne voudrai jamais de ton modèle pour mes mails, et
beaucoup d'autres personne aussi d'ailleurs. Avec gpg, je n'ai pas ce genre
de problème (même si j'en ai certes d'autres).

Je n'ai toujours pas trouvé le truc qui montre le manque de rigueur.



Au hasard :

http://en.wikipedia.org/wiki/Mac_os
http://en.wikipedia.org/wiki/Linux
http://en.wikipedia.org/wiki/Bsd

mais aussi et surtout, je n'ai pas vu les sources de ton programme.

Manuel.
Avatar
Raymond H.
"Emile" a écrit dans le message de news:
28
juil, 11:05, Stéphane CARPENTIER
wrote:

...
Une expérience intéressante à effectuer. Si on modifie un seul bit du
message chiffré, le logiciel le détecte et donne l'avertissement "Les
données sont altérées". Lorsque l'expéditeur a terminé l'écriture du
message, le logiciel crée le bloc hash de l'ensemble du message et à
la réception, le même bloc hash est recalculé. Si les deux hash ne
sont pas identiques, le logiciel donne l'avertissement "Les données
sont altérées". Le destinataire reçoit le bloc hash et la signature
qui est formée par le chiffrement du bloc hash avec la clef privée de
l'expéditeur. Pour vérifier la signature, le destinataire clique sur
le shake-hand et l'autorité de confiance lui envoie un certificat de
la vérification de la signature. Je me demande combien de logiciels de
messagerie effectuent ce genre de service.



Il y a un autre truc qui montre le manque de rigueur et qui fait que
j'affirme que ça ne marche pas. Je te laisse trouver par toi même.





Je n'ai toujours pas trouvé le truc qui montre le manque de rigueur.



Emile



Bonjour,
J'ai lu ceci sur
http://www.mascre-heguy.com/htm/fr/publications/avocat_signature_droit_preuve.htm :
******
".1 La cryptographie asymétrique
A l'heure actuelle, les seules signatures électroniques reconnues comme
fiables sont fondées sur la cryptographie à clés asymétriques décrites en
annexe de la Directive. Deux clés sont utilisées : avec la première clé (clé
privée) on signe électroniquement, avec la deuxième (clé publique) on
vérifie la signature électronique. De plus, il est impossible de déduire ou
extrapoler une clé à partir de l'autre.

A titre d'exemple, Jacques souhaite signer électroniquement un message et l'envoyer.
Jacques génère un couple de clés dont l'une est privée et l'autre publique.
Jacques signe le message au moyen de sa clé privée qu'il garde secrète (lui
seul pourra donc signer). Jacques envoie au destinataire son message signé
électroniquement assorti de sa clé publique. Le destinataire utilise la clé
publique de Jacques pour vérifier l'origine du message. Lorsque le
destinataire vérifie l'origine du message avec la clé publique de Jacques,
il peut avoir la certitude que le message a bien été signé avec la clé
privée de Jacques (authentification) et que ce message n'a pas été modifié
(intégrité du message). "
******

Dans le texte ci-haut, il est dit que le destinataire a ainsi la preuve
que c'est bien Jacques qui a signé le message. Par contre, Jacques n'aurait
pas de preuve que le destinataire a bien reçu son message. Aie-je bien
raison?

Dans le cas d'Emile, la preuve ne repose-t-elle pas sur l'organisme de
confiance? Si oui, n'importe qui de cette organisme pourrait altérer la
vérité et transmettre un mensonge. L'organisme de confiance serait quelques
chose en soit qu'on ne peut pas vraiment avoir confiance à 100%.

Je pense que juridiquement, il faudrait être capable d'établir une
preuve que:
a) c'est bien Jacques qui a envoyé le message au destinataire,
b) que c'est bien le destinataire qui a reçu le message venant de Jacques,
c) que la preuve de 'a' et de 'b' soit apportée.

Il me semble que l'ensemble de ces 3 points n'est pas à 100% sûr
d'après le texte ci-haut pris sur
http://www.mascre-heguy.com/htm/fr/publications/avocat_signature_droit_preuve.htm ,
ni d'après l'idée d'un 'organisme de confiance' apporté par Emile.

Je dis ceci pour souligner le principe qui existe dans mon algorithme
(l'algo RH) qui fournirait la preuve à Jacques que vraiment le destinataire
a reçu son message (à cause de l'accusé de réception que le destinataire
fourni à Jacques); que le destinataire à bien la preuve que le message vient
bien de Jacques (à cause de la clef d'acquittement que Jacques lui envoie en
retour et qu'ainsi son message puisse être décrypté).
Ainsi, ceci rencontre bien les exigences (ci-haut) des points 'a' et
'b'. Concernant le point 'c' (sur les courriels) on aurait la preuve des
transactions faites, par les traces sur le serveur des providers de Jacques
et aussi du destinataire (tout y serait 'stoqué' là pour un bon bout, et les
autorités policières en ont accès...). Ici au Canada, j'ai déjà entendu
dire que tout reste sur les serveurs pour au moins un an afin que les
autorités puisse consulter ces preuves au besoin; je ne sais pas ailleurs
comment c'est. Quelqu'un pourrait-il en dire plus et m'éclairer sur cet
aspect?

Voici 2extraits de textes sur la partie 'c2' de mon 'algo RH' pris sur
mon site (ici je tire l'attention uniquement sur la partie 'c2' qui est créé
dans les cryptogrammes; que ce soit par le moyen du logiciel AllCrypter ou
via un autre logiciel utilisant l'algo RH cela n'a pas de différence, ici il
est question de la partie 'c2' généré via l'algo RH. Ne serait-ce pas la
solution (dans notre exemple) qui donne la preuve à Jacques et au
destinataire, c'est à dire du bien fondé de savoir avec certitude qui envoie
et qui reçoit le courriel (l'origine et le destinataire) ? Ainsi, nul besoin
d'organisme de confiance à qui on ne peut pas vraiment se fier à 100% à
cause de ceux qui y travaillent. Comme on dit: 'On est jamais mieux servi
que par soit-même' :-)


Voici 2 extraits:
http://logicipc.no-ip.com/allcrypter/AllCrypter-explication02.html
..." Si vous désirez avoir la preuve que le destinataire a bien reçu
votre fichier (ou vos données), vous avez alors l'option d'inclure un accusé
de réception et une clef d'acquittement dans votre fichier (ou vos données)
lorsque vous cryptez . Pour ce faire, cliquez sur le menu 'Options' puis sur
la ligne 'Crypter en incluant un accusé de réception'. Ceci affichera deux
lignes juste en dessous de la première case blanche en haut.
Lorsque le destinataire commence à décrypter votre fichier, si c'est
la bonne clef personnelle alors une fenêtre s'affiche lui dévoilant l'accusé
de réception que vous y avez auparavant crypté, et il doit vous l'envoyer
pour recevoir en retour de vous la clef d'acquittement qu'il doit ensuite
entrer dans cette même fenêtre afin de pouvoir débuter le décryptage. Ainsi,
lorsque vous recevez de lui l'accusé de réception, ceci est la preuve que
c'est bien lui le destinataire qui a reçu votre fichier (vos données), et
qu'il est bien en possession de votre fichier.
C'est donc parce que vous en avez la preuve, que vous lui envoyez en
retour la clef d'acquittement pour qu'il l'écrive dans la fenêtre afin qu'il
puisse être capable de poursuivre de décryptage, sinon le décryptage ne se
fait pas du tout. Cliquez avec le '?' sur ces lignes pour afficher
l'explication de ces 2 lignes."

http://logicipc.no-ip.com/allcrypter/algorh3a.html
..."- ClefAcq = 42 caractères = clef d'acquittement dont l'expéditeur
envoie au destinataire du cryptogramme en échange de l'accusé de réception
(généré au début du déchiffrement) afin que le déchiffrement puisse se
poursuivre complètement. ClefAcq est nécessaire seulement si le destinataire
doit fournir un accusé de réception (code de 4 caractères en base 256
intégré dans le cryptogramme) à l'expéditeur pour que celui-ci lui
communique la clef d'acquittement en retour pour que le déchiffrement puisse
se poursuivre jusqu'au bout par le destinataire.
Lorsqu'il n'y a pas d'accusé de réception d'activé dans InfoS (AccON =
ayant un nombre ascii pair au hasard), alors les options 'Acc', 'HashAcq',
'Tail' et 'Date' ne sont pas actives et contiennent des caractères choisis
au hasard.
Ex. InfoS =
Sfa||Sfb||HashSf||AccON||Acc||HashAcq||HashSi||FichON||TailFich||Tail||Date||VersF.
Mais si un accusé de réception est utilisé (AccON = ayant un nombre
impair au hasard) alors Sfa et Sfb deviennent Sfa* et Sfb* indiquant que Sfa
et Sfb ont été cryptés à l'aide de la clef d'acquittement (ClefAcq) ayant 42
caractères.
Ex. InfoS =
Sfa*||Sfb*||HashSf||AccON||Acc||HashAcq||HashSi||FichON||TailFich||Tail||Date||VersF.


Exemple sur le rôle de l'accusé de réception:
'A' insère un accusé de réception (Acc = code de 4 caractères) dans c2.
A envoie c (le cryptogramme) à B, et B débute le déchiffrement de 'c' via sa
clef personnelle habituelle (K connu de A et B). Si HashSf (intégré dans c2)
correspond au 2 clefs de session finales cryptées par ClefAcq (donc si
'Sfa*<2>2 xor Sfb*<2>2 = HashSf') alors maintenant le code décrypté (Acc)
est non seulement connu de A mais aussi de B, et B l'envoie à A. 'A' reçoit
ce code (Acc), et c'est la certitude pour A que c'est bien B qui a reçu ce
'c', puisque ce n'est que via sa propre clef personnelle que ce code pouvait
être décrypté. Alors, A envoie à B une clef spéciale et unique,
c'est-à-dire la clef d'acquittement (ClefAcq) par laquelle B décrypte les 2
clefs de sessions finales cryptées (Sfa* et Sfb* intégrés dans c2) afin de
connaître Sfa et Sfb. Ce n'est que via ces 2 clefs de sessions finales
décryptées (Sfa et Sfb) par B que le déchiffrement de 'c' peut se poursuivre
jusqu'au bout et avec exactitude.


Juste après le chiffrement de c1, le chiffrement de InfoS s'effectue en
deux couches: inférieure et supérieure.
1) S'il n'y a pas d'accusé de réception on trouve HashSi via 'sia<2>2
xor sib<2>2', et HashSf via 'sfa<2>2 xor sfb<2>2'; puis la partie droite de
InfoS (c'est-à-dire 'HashSi, FichON, TailFich, Tail, Date, VersF') est
cryptée à partir de 'AccON, Acc, HashAcq' à la manière de 'xor(Sfa, ClefAcq)
= Sfa*', donc 'xor(InfoS>, AccON||Acc||HashAcq) = InfoS1>'. Ceci est la 1re
couche (couche inférieure) du chiffrement de InfoS. Ensuite, ce nouveau
InfoS modifié (InfoS1) est crypté via 'K' (la clef personnelle secrète), ce
qui constitue la 2e couche (couche supérieure) du chiffrement de InfoS.
1re couche de c2 = InfoS1 = InfoS<||xor(InfoS>, AccON||Acc||HashAcq)
2 couches de c2 = f2(InfoS<||xor(InfoS>, AccON||Acc||HashAcq), k)
2) S'il y a un accusé de réception on trouve HashSi via 'sia<2>2 xor
sib<2>2', et HashSf via 'sfa<2>2 xor sfb<2>2'; puis Sfa et Sfb sont cryptés
à l'aide de ClefAcq (clef d'acquittement de 42 caractères) pour devenir Sfa*
et Sfb* (ceci est expliqué plus bas à la 1re étape). Ensuite, on fait les
calculs pour trouver HashAcq. Puis, on crypte les caractères de 'InfoS*>'
via ixoration avec la moitié gauche de ClefAcq puis avec la moitié droite de
ClefAcq (donc, 'InfoS*> xor ClefAcq<21 xor ClefAcq>21'); donc, '
'ClefAcq<21' xor 'ClefAcq>21' xor 'HashAcq, HashSi, FichON, TailFich, Tail,
Date, VersF' ' (explication à la 1re étape); ceci est la 1re couche (couche
inférieure) du chiffrement de InfoS. Ensuite, ce nouveau InfoS modifié
(InfoS1) est crypté via 'K' (la clef personnelle secrète); ceci constitue la
2e couche (couche supérieure) du chiffrement de InfoS.
1re couche de c2: 'InfoS1 = InfoS*<||xor(InfoS*>, ClefAcq<21, ClefAcq>21)'
2 couches de c2: 'c2 = f2(InfoS*<||xor(InfoS*>, ClefAcq<21, ClefAcq>21), k)'

À l'inverse donc, lors du déchiffrement de c2, on débute par le
déchiffrement de la couche supérieure (2e couche cryptée) via K. Alors, on
obtient en clair la partie gauche de InfoS qui indique s'il y a un accusé de
réception ou non. Ainsi:
1) s'il n'y a pas d'accusé de réception (AccON = un nombre pair) on a
déchiffré 'Sfa, Sfb, HashSf, AccON, Acc, HashAcq' et si 'sfa<2>2 xor
sfb<2>2' correspond à HashSf, alors à partir de 'AccON, Acc, HashAcq' on
décrypte la couche inférieure, donc la partie droite de InfoS (HashSi,
FichON, TailFich, Tail, Date, VersF). Ensuite, on décrypte c1 via sfa et
sfb.
2) s'il y a un accusé de réception (AccON = un nombre impair) on a
déchiffré 'Sfa*, Sfb*, HashSf, AccON, Acc', et si 'sfa*<2>2 xor sfb*<2>2'
correspond à HashSf et que AccON indique une valeur impaire signifiant qu'on
a besoin d'une clef d'acquittement pour continuer le déchiffrement, alors on
envoie Acc à l'expéditeur pour recevoir en échange ClefAqc avec laquelle on
décrypte les 21 caractères qui constituent la partie droite de InfoS
(HashAcq, HashSi, FichON, TailFich, Tail, Date, VersF); pour ce faire on
ixore avec la moitié gauche de ClefAcq puis avec la moitié droite de ClefAcq
(donc, 'InfoS*> xor ClefAcq<21 xor ClefAcq>21'). Puis, si HashAcq correspond
au condensé de la clef d'acquittement alors on décrypte sfa* et sfb* via
ClefAcq pour trouver sfa et sfb afin de décrypter c1 via sfa et sfb."...

r.h.
Avatar
Cornelia Schneider
mpg wrote in news:g6vkil$195g$:

Puisqu'on parle du tiers de confiance, soyons clair :je ne veux pas
qu'un tiers, fut-il proclamé ® de confiance ¯ puisse lire ma
messagerie privée et c'est pour ça que je ne voudrai jamais de ton
modèle pour mes mails, et beaucoup d'autres personne aussi d'ailleurs.
Avec gpg, je n'ai pas ce genre de problème (même si j'en ai certes
d'autres).



+1

Enfin quelqu'un qui le dit !

Cornelia

--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : www.sts67.org
Music etc : www.bownbend.com
GPG key ID 83FF7452
Avatar
mpg
Le (on) vendredi 01 août 2008 21:13, Raymond H. a écrit (wrote) :

Dans le texte ci-haut, il est dit que le destinataire a ainsi la
preuve
que c'est bien Jacques qui a signé le message. Par contre, Jacques
n'aurait pas de preuve que le destinataire a bien reçu son message. Aie-je
bien raison?



Jacques n'aura la preuve que le destinataire a reçu le message que si ce
dernier lui envoie un accusé de réception signé. Pour une fois ça marche
comme avec la poste (sauf qu'on parle de signature crypto ici, bien sûr).

Dans le cas d'Emile, la preuve ne repose-t-elle pas sur l'organisme
de
confiance? Si oui, n'importe qui de cette organisme pourrait altérer la
vérité et transmettre un mensonge. L'organisme de confiance serait
quelques chose en soit qu'on ne peut pas vraiment avoir confiance à 100%.



Bah oui, « organisme de confiance » ne veut pas dire que l'organisme *est*
digne de confiance, mais qu'il *faut supposer* qu'il est digne de confiance
sinon le système entier s'écroule. En d'autres termes, c'est une grosse
boîte noire sur laquelle repose tout la sécurité du système. Bref, sauf
peut-être dans des circonstances particulières, c'est mal.

Je dis ceci pour souligner le principe qui existe dans mon algorithme
(l'algo RH) qui fournirait la preuve à Jacques que vraiment le
destinataire a reçu son message (à cause de l'accusé de réception que le
destinataire fourni à Jacques);



Il n'y a pas besoin d'un nouvel algorithme pour ça: dès qu'un algo permet de
signer, il permet d'envoyer des accusés de réceptions (comme je disais,
même la poste sait le faire).

Manuel.
Avatar
Raymond H.
"mpg" a écrit dans le message de news:
g715un$21q8$
Le (on) vendredi 01 août 2008 21:13, Raymond H. a écrit (wrote) :



...
... dès qu'un algo permet de
signer, il permet d'envoyer des accusés de réceptions (comme je disais,
même la poste sait le faire).

Manuel.




Etes-vous certains que tous les algorithmes qui signent permettent
aussi les accusés de réception? Dans les faits ce n'est pas le cas.
Parle-t-on des mêmes démarches que l'algo RH concernant l'accusé de
réception et la clef d'acquittement ? Une démarche qui se passe directement
entre l'expéditeur et le destinataire, sans intermédiaire du style
'organisme de confiance'.
Aussi, pour être valide il n'est pas obligatoire que le destinataire
crypte l'accusé de réception de nouveau lorsqu'il le retourne à
l'expéditeur; car seul le destinataire pouvait le connaître (cet accusé) via
sa clef personnelle (comme c'est le cas avec l'algo RH utilisé par le
logiciel AllCrypter); donc, si l'expéditeur reçoit ce numéro (l'accusé de
réception) il sait très bien que c'est le destinataire qui a reçu son
message puisque lui seul (le destinataire) pouvait décrypter ce numéro
(l'accusé) via sa clef avant de le retourner à l'expéditeur. Donc, même si
1000 personnes capteraient ce numéro (l'accusé) via Internet lorsque le
destinataire l'envoie à l'expéditeur, cela ne change rien pour l'expéditeur
car, peut importe de qui l'expéditeur reçoit cet accusé, cela lui confirme
d'une façon ou d'une autre que le destinataire avait bien reçu son message
(cryptogramme), car lui seul (le destinataire) pouvait décrypter cet accusé
via sa clef personnelle, donc dans ce cas cette preuve est faite.
Dans le cas des signatures de plusieurs algos, cela confirme juste au
destinataire que le cryptogramme vient bien de l'expéditeur mais ça ne
confirme pas à l'expéditeur que le destinataire a bien reçu son
cryptogramme; donc, aucune preuve légale que le destinataire a reçu et lu le
message de l'expéditeur; et pourtant on comprend la grande importance de
recevoir la preuve que le destinataire ait bien reçu le cryptogramme (que ce
soit une parution à paraître en cours, une mise en demeure, un
renouvellement de bail pour loyer, etc.).

r.h.
Avatar
User
Non pas du tout,
C'est rare de voir une personne de cet âge sur internet et surtout sur les
NG.

Je vous souhaite un joyeux anniversaire, et bravo pour vos travaux.

User

PS : Je réponds par le haut vu que mon logiciel de messagerie fait comme ça.

"Emile" a écrit dans le message de news:

On 25 juil, 18:16, "User" wrote:
Vous êtes née en 1928 ?

"Emile" a écrit dans le message de news:




Oui effectivement c'est comme ça, j'ai soufflé hier 29 juillet mes
quatre-vingt bougies.
Quelque chose à redire à cela ?

Emile
Avatar
Thierry B.
--{ User a plopé ceci: }--

PS : Je réponds par le haut vu que mon logiciel de messagerie fait comme ça.



P'taing, yen a qui sont fiers de reconnaitre qu'ils utilisent
une bouse intégrale !


--
Very bad coding-style, hard to install, undocumented code.
http://la.buvette.org/devel/libimage/
Avatar
Mathieu SEGAUD
"User" disait le 08/02/08 que :

Non pas du tout,
C'est rare de voir une personne de cet âge sur internet et surtout sur les
NG.

Je vous souhaite un joyeux anniversaire, et bravo pour vos travaux.

User

PS : Je réponds par le haut vu que mon logiciel de messagerie fait comme ça.



peut-être suis-je en train d'halluciner, mais cela empêche-t-il de:
- changer de client, ou
- faire l'effort de formater correctement ?

--
Mathieu