On 31 juil, 00:09, mpg <m...***elzevir.fr> wrote:
>Donc en gros que quand on chiffre avec une clef de 128 bits avec SED,
>c'est au mieux comme si on chiffrait avec un clé de 64 bits avec un bon
>algo. C'est pas brillant. En fait, SED est censé avoir quoi de plus qu'un
>bon vieil AES des familles ?

Comment expliquer encore une fois de plus que le test des 2^64 steps
de Kula qui permettrait de casser le SED, c'est de la foutaise de A à
Z !!! Je n'ai pas su mettre le doigt sur l'erreur de Kula, je ne suis
pas mathématicien de formation. Toutefois, je pense que les relations
d'isomorphisme dont Kula fait état ne sont pas applicables pour
évaluer le SED. L'avis d'un matheux serait souhaitable.

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

Le DES et l'AES doivent être considérés comme étant des algorithmes
de première et de deuxième génération. La première génération, c'est
le DES lequel est constitué de 8 boîtes (S1 ... S8) de substitution
composées chacune de 4*16 nombres de quatre bits et opérant suivant le
principe de Feistel. Dans ce cas, des trois éléments, le texte clair,
le texte chiffré et la clef, deux de ces éléments sont reliés par une
relation linéaire tandis que la relation de deux autres éléments est
non linéaire par la mise en place des boîtes S de substitution. Cette
disposition permet de restituer le texte clair à partir du texte
chiffré, mais comme les boîtes de substitution ne se composent que de
nombres de 4 bits et que les blocs à chiffrer sont formés de 64 bits
pour le DES, il importe d'effectuer de nombreuses rondes (16 rondes
pour le DES) qui se chevauchent séquentiellement. La petite taille des
boîtes de substitution est visiblement la cause des clefs faibles et
semi-faibles.

Dans la seconde génération avec l'algorithme AES, on s'affranchit de
la trop petite taille des boîtes de substitution du DES en
introduisant le principe, utilisé aussi par d’autres algorithmes,
entre autres certains du « Block Cypher Lounge », dans lequel les
textes clairs et chiffrés et la clef se situent parmi quatre éléments
lesquels répondent aux relations qui lient un dividende, un diviseur
et un quotient et un reste. En attribuant des valeurs définies à trois
éléments, le quatrième élément est automatiquement défini. C'est la
filière qui permet de restituer le texte clair à partir du texte
chiffré. Avec cette procédure, il n'est plus nécessaire de dénommer
les boîtes comme dans le DES. Pour l'AES, les boîtes de substitution
sont formées en quelque sorte par quatre ensembles de 32 bits. Ici
aussi comme avec le DES, il importe de faire chevaucher les
différentes opérations en effectuant dix rondes. 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.

La troisième génération (le SED) est caractérisée par l'application
de deux transformations consécutives opérées dans deux groupes
multiplicatifs différents, mais l’ensemble des deux groupes ne se
comporte pas comme un groupe. Tout nombre entier positif de 127 bits
peut être considéré comme un élément faisant partie des N (= 2^n-1)
états du LFSR: X^127+ X^63+1. Ce nombre, ou texte clair d'entrée, a
un certain logarithme discret et il est possible de calculer le nombre
qui a comme logarithme discret, celui du nombre d'entrée multiplié par
la clef k modulo N dans ce LFSR, et cela sans en connaître le
logarithme discret en question. C'est en fait une exponentiation dans
le corps fini défini par le LFSR. Le vecteur résultat ainsi obtenu
existe également dans la séquence du LFSR: X^127+X^30+1, une et une
seule fois, mais avec un tout autre logarithme discret et peut
également faire l'objet d'une seconde exponentiation dans le second
LFSR. C’est le fait du passage du logarithme discret du résultat
obtenu dans la première exponentiation au logarithme discret du
vecteur d’entrée de la seconde exponentiation que l’on crée une boîte
de substitution formée de n bits. Les deux polynômes caractéristiques
susmentionnés sont primitifs car leurs racines standards forment des
groupes multiplicatifs d’ordre N (=2^n-1), c’est à dire égal à la
séquence maximum.

Avec le SED, il y a (2^127-1)/e (e=2,71828...) boites de substitution
différentes, c'est ce qui se passerait également en générant 2^127-1
nombres aléatoires de 127 bits (voir loi de Poisson). C'est l'optimum
que l'on peut réaliser avec des nombres de 127 bits en nombres
aléatoires différents. A un facteur près, on peut dire que le rapport
du vecteur chiffré au vecteur clair modulo (2^127-1) est un des
nombres aléatoires susmentionnés. Etant donné la structure de l'AES,
la comparaison des deux algorithmes est difficile à établir en ce qui
concerne le rôle des nombres aléatoires pour l'AES. Pour le SED, on
peut prétendre qu'on atteint l'optimum, tandis que pour l'AES on ne
peut que difficilement faire des suppositions. Je rappelle ici que la
vitesse de chiffrement du SED en software est relativement basse à
cause du très large volume des opérations à effectuer. Par contre, en
hardware, la vitesse des chiffrements serait égale au tiers de la
fréquence horloge.

>Mettre en place une expérience pour casser en 2^{64} opérations un
>clé SED de 128 bits, mine de rien ça doit prendre du temps et des
>ressources et si personne ne le fait, c'est peut-être parce que ça n'en
>vaut pas la peine.

Faut-il encore rappeler que les 2^64 opérations de Kula qui pourrait
casser le SED, c'est de la foutaise. Si le test de Kula n'a pas pu
fonctionner avec 7 bits, contrairement à ce que l'auteur prétend, le
test des 2^64 opérations ne fonctionnera non plus.

>> Je devrais plutôt lui demander dommages et intérêts pour avoir
>> discréditer le SED

>Belle mentalité. Laisse-moi te dire que ta vision de la recherche n'a rien
>à voir avec la mienne, et que l'expérience (que tu aimes) tant montre
>que la mienne est plus efficace.

Il va de soi les dommages et intérêts sont à prendre au second degré.

>Bah, c'est un des nombreux problèmes de tes raisonnements : croire
>que si on truc marche pour n=7, il marche aussi pareil pour des valeurs
>de n plus grandes. C'est un raisonnement heuristiques : ça donne des
>raisons de penser que, donc de chercher à démontrer que, mais c'est
>très loin d'être une preuve en soi.

Dans la première publication (MIT/LCS/TM-82) du RSA, les trois
auteurs donnent un exemple de fonctionnement de l'algorithme avec de
petits nombres: p=47, q=59 n=2773, d=157, e=17, et 948^157=920
modulo-2773. Je crois que personne mettrait en doute le fait que si le
RSA fonctionne avec des petits nombres, il fonctionnera également avec
des grands nombres. Je ne vois pas la différence qu'il pourrait y
avoir entre un RSA qui permet des petits et des grands nombres et le
SED qui n'aurait pas cette possibilité. La réduction du SED avec n=17
bits confirme en mieux les résultats déjà obtenus avec n=7.

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. 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.

Emile

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.

"Emile" <emilemusyck***gmail.com> a écrit dans le message de news:
df6a1683-368f-41fa-afd7-9e6106f487d4...roups.com...On 28
juil, 11:05, Stéphane CARPENTIER
<stef.carpent...***gratuit.fr.invalid> 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/p...oit_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/p...oit_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...ication02.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||Fic hON||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||F ichON||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.

"mpg" <mpg***elzevir.fr> a écrit dans le message de news:
g715un$21q8$1***talisker.lacave.net...
> 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.

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" <emilemusyck***gmail.com> a écrit dans le message de news:
a8639916-ae00-4787-a133-59df3f3cbc03...oglegroups.com...
On 25 juil, 18:16, "User" <u...***free.invalid> wrote:
> Vous êtes née en 1928 ?
>
> "Emile" <emilemus...***gmail.com> a écrit dans le message de news:
> 9e6ec8cf-296c-4ac5-8215-1e57d422e...***d77g2000hsb.googlegroups.com...

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

Emile

"mpg" <mpg***elzevir.fr> a écrit dans le message de news:
g72v1s$e93$1***talisker.lacave.net...
> Le (on) samedi 02 août 2008 20:10, Raymond H. a écrit (wrote) :
>
>> Etes-vous certains que tous les algorithmes qui signent permettent
>> aussi les accusés de réception?
>
> Bah il me semble bien que oui. Que dites-vous par exemple du protocole
> suivant : A envoie un message à B (chiffré ou non, signé ou non, je pense
> qu'on s'en fout ici) ; à la réception, B signe le message qu'il a reçu et
> renvoie la signature à A. Ce dernier est alors en mesure de prouver que B
> a
> reçu la message, car il ne peut pas signer sinon, et personne ne peut
> signer à sa place.
>
> J'ai manqué quelque chose ?

Si je comprend bien, d'un point de vue juridique la preuve doit être
apportée concernant l'intégrité du message que B reçoit; encore plus, la
preuve doit être faite que le message soit indissociable de la signature.
Dans votre exemple, le message envoyé à A ne rencontrerait pas ces
conditions s'il n'est pas crypté et si la signature n'y fait pas partie
intégrante. Le message doit donc obligatoirement être signé ici. Donc, sans
signature le message ne serait pas recevable comme preuve, et sans lien
indissociable entre la signature et le message, il ne serait pas recevable
non plus.
Dans votre exemple, si B signe un message qui n'avait jamais été
crypté, cela ne lui donne pas non plus (à B) la certitude que le message
soit intact et ainsi il aurait pu être remplacé par un faux en chemin.
Donc, lorsque A recevrait la signature de B alors A n'aurait aucune
certitude que c'est bien son message que B a reçu car il aurait pu aussi
bien être altéré ou remplacé lorsqu'il était en chemin de A à B.

> Par contre il faut que le destinataire accepte de transmettre l'accusé de
> réception. Là je ne sais pas du tout si des protocoles plus élaborés
> permettent ou pas de ne délivrer le message qu'en échange d'un truc qui
> prouve sa réception.
>
> Manuel.
>
Comme mentionné plus haut on doit avoir la preuve que le message a un
lien sûr avec la signature. Ce qui fait que le message doit être livré avec
et faisant parti d'un tout avec la signature dès le départ de A et que le
tout devrait être crypté au départ afin qu'on puisse avoir la preuve qu'il
n'a pas été altéré en chemin; aussi un mécanisme de contrôle des données
comparant les données d'avant le chiffrement avec ces mêmes données après le
déchiffrement doit être disponible dans l'algo utilisé. L'algo RH fait tout
cela.
Voici quelques extraits du site
http://www.mascre-heguy.com:80/htm/f...oit_preuve.htm
sur ce sujet:

*************
II. LA LOI DU 13 MARS 2000 PORTANT ADAPTATION DU DROIT DE LA PREUVE AUX
TECHNOLOGIES DE L'INFORMATION ET RELATIVE A LA SIGNATURE ELECTRONIQUE
....
1. L'écrit électronique admis comme preuve
1.1 Une nouvelle définition de l'écrit
Selon le nouveau texte, "la preuve littérale, ou preuve par écrit, résulte d'une
suite de lettres, de caractères, de chiffres ou de tous autres signes ou
symboles dotés d'une signification intelligible, quels que soient leur
support et leurs modalités de transmission".
....
1.2 La reconnaissance du document électronique comme mode de preuve
....
L'admissibilité de l'écrit sous forme électronique comme preuve est ainsi
soumise à une double condition. En premier lieu, l'écrit doit révéler l'identité
de celui dont il émane. En d'autres termes, une vérification doit être
opérée. En pratique, l'identification sera réalisée au moyen du certificat
qualifié émis dans les conditions prévues par la Directive. En second lieu,
l'écrit sous forme électronique doit être établi et conservé dans des
conditions de nature à en garantir son intégrité.
....
2. La reconnaissance juridique de la signature électronique
2.1 La définition générale et fonctionnelle de la signature
Paradoxalement, le législateur n'avait jusqu'à présent pas retenu une
définition de la signature. Aux termes de la nouvelle loi, la signature se
voit reconnaître une double fonction : elle ".identifie celui qui l'appose
et manifeste son consentement aux obligations qui découlent de cet acte ".
....
2.2 La définition de la signature électronique
La nouvelle loi définit la signature électronique comme 'usage d'un "procédé
fiable d'identification garantissant son lien avec l'acte auquel elle s'attache.".
....
Il convient de relever enfin qu'un lien indissociable doit exister entre la
signature électronique et le document électronique.

*************

Bonne journée
Raymond Houle

> Dans votre exemple, le message envoyé à A ne rencontrerait pas ces
> conditions s'il n'est pas crypté et si la signature n'y fait pas partie
> intégrante. Le message doit donc obligatoirement être signé ici. Donc,
> sans signature le message ne serait pas recevable comme preuve, et sans
> lien indissociable entre la signature et le message, il ne serait pas
> recevable non plus.

Ici j'ai fait une petite erreur d'inattention. On devrait lire "Dans
votre exemple, le message envoyé à B ne rencontrerait pas ces conditions
s'il n'est pas crypté et si la signature n'y fait pas partie intégrante. Le
message doit donc obligatoirement être signé ici par A au départ; le message
et la signature doivent être dans le même cryptogramme pour prouver leur
caractère indissociable. Donc, sans signature le message ne serait pas
recevable comme preuve, et sans lien indissociable entre la signature et le
message, il ne serait pas recevable non plus.".

Donc, B ne signe rien, mais confirme via l'accusé de réception qu'il
envoie à A; ce qui donne la preuve à A que B a reçu son message intact, et A
retourne alors une clef d'acquittement à B pour la suite du processus de
déchiffrement du message que A sait que B a en sa possession.

:-)
Raymond H.