Cryptosystème ClassicSys

Mathieu SEGAUD wrote on 02/08/2008 23:47:

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 ?

voire de cliquer (oui c'est technique) en bas pour y placer le caret
(très technique aussi).

et pour effacer les citations inutiles, l'User peut également tenter
la touche "Suppr".

Sylvain.

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 ?

Dans les faits ce n'est pas le cas.

Ah bon ? Quels faits ?

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

Je parle toujours dans organisme « de confiance ». Ma proposition ci-dessus
ne fait aucune autre hypothèse que « on sait signer et vérifier les
signatures ».

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.

"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/fr/publications/avocat_signature_droit_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.

Le (on) dimanche 03 août 2008 08:00, Raymond H. a écrit (wrote) :

"mpg" <mpg@elzevir.fr> a écrit dans le message de news:

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.

Si je comprend bien, d'un point de vue juridique la preuve doit être

Vu qu'on est pas sur fmd, je préférerai qu'on parle de crypto et d'un point
de vue technique.

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.

Bah oui, mais c'est bien ce que je proposais. B renvoie à A sa signature
*appliqué au message qu'il a reçu*. Ceci garanti l'intégrité. Sinon, c'est
que le protocole de signature est cassé, mais là on part de l'hypothèse que
non.

je le répète, ce que je dis c'est : *si* on a un protocole qui permet de
signer de façon sûre (à savoir : (1) on est sûr de l'auteur de la signature
(2) on est sûr de la teneur du message signé), *alors* on peut utiliser ce
protocole pour faire des accusés de réception.

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.

Dans ma proposition, B renvoie à A sa signature du message qu'il a reçu de
A. Donc oui, c'est signé. Et histoire de bien séparer les problèmes, je ne
m'intéresse pas au fait que :
- seul B puisse lire le message
- seul A puisse lire la signature
- B puisse s'assurer de l'intégrité du message reçu et de l'identité de son
auteur.

Tout ce qui m'intéresse ici, et que j'appelle accusé de réception, c'est que
B puisse fournir à A un truc dont A puisse se servir pour s'assurer (et
prouver) que B a bien reçu le message.

Les autres problèmes sont aussi résolus par les protocoles classiques, soit
dit en passant.

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.

Avez-vous vraiment lu ma proposition ? B renvoie à A le message reçu, signé
avec sa clé privée (à B).

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.

Comme je l'ai dit, c'est un autre problème.

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.

Si, il en a la certitude, car la signature ne collera pas avec le message
qu'il a envoyé. Vous êtes conscient du fait que quand je parle de signature
il ne s'agit pas d'un truc indépendant du message (en crypto, contrairement
à la vraie vie) ?

Manuel.

On 1 août, 20:27, mpg <m...@elzevir.fr> wrote:

Puisqu'on parle du tiers de confiance, soyons clair : je ne veux pas
qu'un tiers, fut-il proclamé « de confiance » puisse lire ma message rie
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.

Une telle levée de boucliers à l'encontre du principe de l' Autorité
de confiance, m'étonne et j'essaie de comprendre pourquoi. Pour
certains, c'est une association de voyeurs de l'informatique cherchant
à se complaire en lisant les mails d'autrui. Pour d'autres, il y a des
intérêts financiers à protéger.

Tous les crypto-systèmes opérant avec une autorité de confiance ont
en commun le fait que l'utilisateur n'a pas à s'occuper de la gestion
des clefs. Il en est ainsi pour ClassicSys, mais aussi pour Skype. Ce
dernier est génial, entièrement gratuit et a dépassé le cap de plus de
10 millions de correspondants opérant simultanément. Il me permet de
converser, son et vision, avec mes enfants situés à plusieurs milliers
de kilomètres de chez moi. Skype ne fait pas que des heureux. La
police allemande ne parvient pas à décrypter le système pour la traqu e
des terroristes. Voir:
http://www.generation-nt.com/skype-chiffrement-telecommunications-telephoni e-ip-actualite-49717.html
http://actes.sstic.org/SSTIC06/Castle_in_the_Skype/SSTIC06-Desclaux-Castle_ in_the_Skype.pdf.

Pourquoi deux poids et deux mesures?

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

Il existe un programme de démonstration de l'algorithme SED. Entre
les deux exponentiations, il y a une multiplication arithmétique
modulaire avec la même clef. Cette multiplication occupe de l'ordre
d'un % du temps du chiffrement.
voir: http://www.ulb.ac.be/di/scsi/classicsys/classicdemo.exe
et le programme source:
Voir: http://www.ulb.ac.be/di/scsi/classicsys/classicdemosource.zip
Je me pose la question: pourquoi s'intéresser au code source du SED et
ne pas vouloir essayer le système Classicsys?

Emile

On 2 août, 21:04, "User" <u...@free.invalid> wrote:

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

Un grand merci pour vos aimables souhaits.
Emile

Emile wrote on 03/08/2008 21:56:

Une telle levée de boucliers à l'encontre du principe de l' Autorité
de confiance, m'étonne et j'essaie de comprendre pourquoi.

vraiment ? tu essaies et tu ne réponds pas, ne commentes pas cette face
cachée de ton machin ! je suis très surpris.

Pour certains, c'est une association de voyeurs de l'informatique
cherchant à se complaire en lisant les mails d'autrui. Pour d'autres,
il y a des intérêts financiers à protéger.

disons que tu as soigneusement caché cette caractéristique de tes
premiers exposés (premiers posts), laissant le fil se pourrir de
débats inutiles principalement axés sur la protection de la
messagerie personnelle en milieu professionnelle.

or, précisemment ce milieu (l'entreprise) sait très bien protéger
ses intérêts financiers - et se tape complètement de ces quelques
glandeurs qui détourneraient l'outil informatique.
en entreprise donc, toutes les clés (asyum.) de chiffrements émisses
par la CA interne sont backupés (ont une procédure d'escrow), tandis
que les clés de signatures sont non stockées et si possible générées
dans des dispositifs protégés (carte à puce) - n'est-ce pas Erwan;
raisons évidentes: l'entreprise protège ses intérêts financiers,
y compris lorsqu'un employé tombe malade ou change de service ou
toute autre raison qui rappelerait qu'il n'est pas propriétaire
des engagements de cette entreprise.

l'escrow n'est pas nouveau et se comprend parfaitement lorsqu'il
garantit la périnité (dont économique) d'une entreprise.
ton modèle ne vise pas cela - protéger une communauté ayant fait
ce choix - mais au contraire à permettre la surveillance de tous
les individus, et de préférence sans leur dire (notamment aucune
mention dans la license de ton soft, aucune mise de garde, etc).

dès lors fonder son escrow sur un 09/11 répété 4 fois dans
l'argumentaire ne montre que le manque d'argumentaire et la
volonté de mentir, non tu as réfuté ce terme, disons alors
manipuler et surveiller.

Tous les crypto-systèmes opérant avec une autorité de confiance ont
en commun le fait que l'utilisateur n'a pas à s'occuper de la gestion
des clefs. Il en est ainsi pour ClassicSys, mais aussi pour Skype.

tu as presque oublié le GSM.

ce sont des modèles commerciaux, de manipulation ou de vol d'information
cela t'a échappé ??

tu présentais ton truc comme un garant des libertés individuelles, au
moins cette comparaison est plus honnête.

Ce dernier est génial, entièrement gratuit et a dépassé le cap de plus
de 10 millions de correspondants opérant simultanément. Il me permet de
converser, son et vision, avec mes enfants situés à plusieurs milliers
de kilomètres de chez moi. Skype ne fait pas que des heureux.

10 millions sur 6 milliards, je pensais qu'il y aurait plus de neuneux
pour croire n'importe quel démagogue , c'est rassurant.

pour info, skipe est (de plus en plus) interdit et bloqué dans les
entreprises; c'est un système de vol d'info., il est traité comme tel.

Pourquoi deux poids et deux mesures?

non le même, 2 systèmes prétendent offrir un service, dissimulent leur
contenu sous un mauvais packaging et sont donc aussi nuisible.

Je me pose la question: pourquoi s'intéresser au code source du SED et
ne pas vouloir essayer le système Classicsys?

euh parce que sur f.m.c. on préfère davantage parler d'algo (voir leur
finesse, leur possibilité d'implémentation, leur faiblesse aussi) que
de parler d'un clicodrome débile mystificateur et malhonnête, comme ton
classictruc ou la bousse de l'imbélice heureux.

ça te parait pas évident ?
tu te croyais à la foire de Paris ? ou de Genève ?

Sylvain.

Le (on) dimanche 03 août 2008 21:56, Emile a écrit (wrote) :

On 1 août, 20:27, mpg <m...@elzevir.fr> wrote:

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.

Une telle levée de boucliers à l'encontre du principe de l' Autorité

Enlevons-lui déjà sa majuscule, histoire de rester neutre.

de confiance, m'étonne et j'essaie de comprendre pourquoi. Pour
certains, c'est une association de voyeurs de l'informatique cherchant
à se complaire en lisant les mails d'autrui.

C'est juste que le principe quand tu chiffres est que tu ne veux pas que
quelqu'un d'autre que je destinataire (et toi peut-être) puissent
déchiffrer. Le principe de ton tiers qui a les clés (appellation somme tout
beaucoup plus factuelle même si moins vendeuse que « Autorité de
Confiance ») va à l'encontre de cela. Point-barre.

Tous les crypto-systèmes opérant avec une autorité de confiance ont
en commun le fait que l'utilisateur n'a pas à s'occuper de la gestion
des clefs.

Toutes les dictatures du monde ont en commun que le citoyen n'a pas à se
préoccuper de la gestion de son bulletin de vote.

Je préfère gérer mes clés moi-même.

des terroristes. Voir:

Je trouve cette argument pour le tiers-qui-détient-les-clés vraiment mauvais
si ce n'est fallacieux. Tu est vraiment assez naïf pour croie que les
terroristes vont utiliser ClassicSys ou autre sachant que le gouvernement
peut déchiffrer, alors qu'ils ont 10000 autres moyens de communiquer
peinards ?

C'est comme d'habitude (promoteurs de DRM si vous m'entendez) : ça n'emmerde
que les honnêtes gens.

Je me pose la question: pourquoi s'intéresser au code source du SED et
ne pas vouloir essayer le système Classicsys?

Classicsys utilise SED, non ? Et si tu en est à te demander pourquoi des
gens voudraient voir les sources qu'un truc avant de l'utiliser, en matière
de sécu, il y a du chemin...

Manuel.

Le (on) lundi 04 août 2008 01:42, Sylvain SF a écrit (wrote) :

or, précisemment ce milieu (l'entreprise) sait très bien protéger
ses intérêts financiers

Je ne peux m'empêcher de penser à un fil récent sur fcs... Enfin oui,
certaines entraprises savent très bien.

dès lors fonder son escrow sur un 09/11 répété 4 fois dans
l'argumentaire ne montre que le manque d'argumentaire et la
volonté de mentir, non tu as réfuté ce terme, disons alors
manipuler et surveiller.

Sans compter que les terroristes ne sont pas naïf comme je le disais, et
souvent pas enclin à respecter la loi non plus (c'est dommage, hein ?)

pour info, skipe est (de plus en plus) interdit et bloqué dans les
entreprises; c'est un système de vol d'info., il est traité comme tel.

Le dernière fois que j'en avais entendu parler, en milieu « recherche
publique », donc pourtant pas le plus parano qui soit, on nous conseillait
fortement de ne pas l'utiliser pour des conversations importantes qui
devraient être confidentielles.

Manuel.