Cryptage pyramidal

votre super méthode

Que le système actuel soit bien fondé, éprouvé, c'est évident. Qu'il est
négligeable en terme de coût de calcul de crypter tout en asymétrique ou en
version hybride me semble vrai pour la plupart des cas.
Que ma méthode révolutionne le cryptage? Je n'y crois pas! Je sais qu'une
bonne méthode de cryptage repose sur des pilliers solides, les failles sont
immensément nombreuse. Or je suis à dix mille lieu d'avoir effectué tout le
travail nécessaire pour tester la solidité et l'efficacité de la méthode. Je
la considère donc a priori comme très mauvaise. Ce que je veux évaluer,
c'est comment est-elle mauvaise? Quelles barrières est-elle capable de
franchir par rapport aux attentes. C'est sans prétention.

Puisque tout le monde parle de vitesse, puiqu'on a conçu un système hybride
je pense donc qu'il est possible d'avoir une vague idée de la différence de
vitesse qui existe entre RSA et AES, aussi subjectif que soit tout résultat,
il me semble qu'il est objectif qu'il y ait un écart réel de vitesse.
Est-ce un non sens de chercher à savoir en quoi précisment consiste cet
écart pour connaitre le réel intérêt de gain de la méthode hybride?

Quand à ce que ma méthode dépasse la vitesse d'AES, j'en suis loin, loin
très loin... voilà déjà une mesure qui m'interesse.

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in
news:bqqcu7$d7q$1@news.tiscali.fr:

dans les protocole public ? Il m'a sembé comprendre que c'est à cause
de sa lenteur,

Pas seulement. Mais c'est l'obstacle dont on parle en premier lieu.

qu'est-ce qui l'empécherait de l'utiliser de façon
continue.

Par exemple des manipulations, résultats etc... qui ne seraient pas
alignables sur des barrières naturelles telles que 32 ou 64 bits ou qui
n'utiliseraient pas une quantité constante de mémoire.

Pour accélérer cela, on va même jusqu'à programmer l'algorithme
directement dans des µprocesseurs et on reste en dessous, très largement
en dessous des implémentations d'algorithmes symétriques

Si l'inconvénient est bien sa lenteur j'imagine qu'il y a
moyen de dire celui là est lent celui là est plus rapide. Et donc
qu'il existe des moyens de donner une certaine idée de la différence.

Et bien oui, mesurer telle ou telle implémentation. Pour porter le foin
à la prairie, le tracteur suffit. Il existe des tracteurs deux fois plus
rapides que d'autres, mais on ne passe pas son temps à comparer leur
vitesse ou accélération à Saturn 5 (un facteur 1000 plus ou moins) en
disant "si le tracteur allait plus vite, on l'enverrait dans la lune."

s'apercevoir que RSA est réellement plus lent qu'AES, et donc par
quelques chiffres qui établisse toute sorte de point de
comparaison possible dans des conditions différente, on puisse se
faire finalement une idée de la vitesse comparée de chacune des

On parle de 1000 fois à la grosse louche.

méthode. (Une vision précise incluera naturellement les
conditionnements qui favorise tel ou telle méthode).

Oui, comme par exemple implémenter Huffman en Java en nommant chaque
bit...

Ce n'est pas parce qu'on fait jamais quelque chose qu'on ne peut pas
s'interroger sur
*pourquoi on le fait jamais*, et il me semble que c'est une question
de *vitesse qui est la base*, est-ce que je me trompe?

Non, puisqu'on vous le dit depuis le début, il doit y avoir un fond de
vérité.

Ou-est ce que je me trompe? A moins que je n'ai pas le droit de
m'interesser à 'quelle vitesse crypterait RSA, si on cryptait
uniquement avec lui', puisque cela ne se fait pas?

Si, vous avez parfaitement le droit, mais ce n'est pas nécessairement un
sujet qui déchaine l'intérêt des foules.

En résumé, puisqu'on m'a fourni des données pour AES (merci à 'salus')

Vous avez au moins cliqué sur le lien que je vous aid donné?

quelqu'un connaitrait-il des éléments de vitesse de cryptement par
RSA, (je me chargerai seul d'en estimer toute la subjectivité. En me
trompant certainement, car je ne connais pas toute la subtilité de la
sécurité des algorithmes mais tant pis pour moi. La connaissance
progresse toujours par approximation et simplification)

Comparez AES 128 à RSA 128 est débile puisque le niveau de sécurité
offert par l'AES 128 est immense et celui de RSA 128 est nul.

J'attends vos suggestions pour un test significatif - attention, il y a
quelques pièges...

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in
news:bqqe1b$ei1$1@news.tiscali.fr:

L'intention de ma demande est de savoir ''de combien les systèmes
asymétriques sont trop lents'' pour concurencer les systèmes
symétriques dans le cryptage en continu.
Cette question ne possède-t-elle pas une réponse ?
Forcément nuancer vu les difficultés de comparaison, mais entre
nuancer et impossible il y a une mesure.
Est-ce que je me trompe quelque part ?

Quand on a un facteur de 1 à 1000 (à un order de grandeur près en fonction
de très nombreux facteurs) on ne parle pas de nuance. On parle de Saturn 5
et d'un tracteur.

Merci, voilà un commentaire qui me plait, qui me semble constructif et
surtout qui répond à ma question.
J'ignorais ce facteur 1 contre 1000 et je cherchais à le connaitre.
"Il y a peu d'espoir de voir un jour l'asymétrique remporter la lutte,
c'est probablement le prix de son avantage".
Ca, je l'avais bien compris, mais je cherchais à en connaitre une mesure. Je
m'attendais à beaucoup plus grand.
Je sais qu'il est difficile d'instruire les ignorants, je suis prof (et
c'est un plaisir pour moi), mais ce n'est pas toujours facile de comprendre
où en est son élève.
Merci encore de votre coopération.


Pierre Vandevenne <pierre@datarescue.be> a écrit dans le message :
Xns9448DFEBD1A47pierredatarescuebe@195.238.3.180...

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in
news:bqqcu7$d7q$1@news.tiscali.fr:

dans les protocole public ? Il m'a sembé comprendre que c'est à cause
de sa lenteur,

Pas seulement. Mais c'est l'obstacle dont on parle en premier lieu.

qu'est-ce qui l'empécherait de l'utiliser de façon
continue.

Par exemple des manipulations, résultats etc... qui ne seraient pas
alignables sur des barrières naturelles telles que 32 ou 64 bits ou qui
n'utiliseraient pas une quantité constante de mémoire.

Pour accélérer cela, on va même jusqu'à programmer l'algorithme
directement dans des µprocesseurs et on reste en dessous, très largement
en dessous des implémentations d'algorithmes symétriques

Si l'inconvénient est bien sa lenteur j'imagine qu'il y a
moyen de dire celui là est lent celui là est plus rapide. Et donc
qu'il existe des moyens de donner une certaine idée de la différence.

Et bien oui, mesurer telle ou telle implémentation. Pour porter le foin
à la prairie, le tracteur suffit. Il existe des tracteurs deux fois plus
rapides que d'autres, mais on ne passe pas son temps à comparer leur
vitesse ou accélération à Saturn 5 (un facteur 1000 plus ou moins) en
disant "si le tracteur allait plus vite, on l'enverrait dans la lune."

s'apercevoir que RSA est réellement plus lent qu'AES, et donc par
quelques chiffres qui établisse toute sorte de point de
comparaison possible dans des conditions différente, on puisse se
faire finalement une idée de la vitesse comparée de chacune des

On parle de 1000 fois à la grosse louche.

méthode. (Une vision précise incluera naturellement les
conditionnements qui favorise tel ou telle méthode).

Oui, comme par exemple implémenter Huffman en Java en nommant chaque
bit...

Ce n'est pas parce qu'on fait jamais quelque chose qu'on ne peut pas
s'interroger sur
*pourquoi on le fait jamais*, et il me semble que c'est une question
de *vitesse qui est la base*, est-ce que je me trompe?

Non, puisqu'on vous le dit depuis le début, il doit y avoir un fond de
vérité.

Ou-est ce que je me trompe? A moins que je n'ai pas le droit de
m'interesser à 'quelle vitesse crypterait RSA, si on cryptait
uniquement avec lui', puisque cela ne se fait pas?

Si, vous avez parfaitement le droit, mais ce n'est pas nécessairement un
sujet qui déchaine l'intérêt des foules.

En résumé, puisqu'on m'a fourni des données pour AES (merci à 'salus')

Vous avez au moins cliqué sur le lien que je vous aid donné?

quelqu'un connaitrait-il des éléments de vitesse de cryptement par
RSA, (je me chargerai seul d'en estimer toute la subjectivité. En me
trompant certainement, car je ne connais pas toute la subtilité de la
sécurité des algorithmes mais tant pis pour moi. La connaissance
progresse toujours par approximation et simplification)

Comparez AES 128 à RSA 128 est débile puisque le niveau de sécurité
offert par l'AES 128 est immense et celui de RSA 128 est nul.

J'attends vos suggestions pour un test significatif - attention, il y a
quelques pièges...

Vous avez au moins cliqué sur le lien que je vous aid donné?
Ne connaissant pas tous les sigles j'ai parcouru la page en passant par

dessus ceux qui m'interessaient. Veuillez m'en excusez.
Et merci encore pour ce lien, me voilà comblé

"Klopfenstein Michaël" <m.klofpenstein@libertysurf.fr> wrote in
news:bqqu0r$dae$1@news.tiscali.fr:

Je sais qu'il est difficile d'instruire les ignorants,

Nous sommes tous ignorants de tas de choses, ignorance et intelligence sont
deux choses différentes et il ne fait aucun doute que vous avez
suffisamment de la seconde ;-)

Je crois que la pierre d'achoppement, c'est peut être une mauvaise
perception de ce qu'est la crypto actuellement: on ne cherche pas
l'algorithme incassable, on cherche à résoudre des problèmes liés par aux
contraintes de cartes à puces, au nombre de connection ssl gérables en x
minutes etc...

Diffie et Hellman cherchaient à résoudre le problème de l'établissement de
communication sûre sur un canal non sûr. Rivest, Shamir et Adleman
cherchaient comment obtenir des signatures dans le cadre d'un système
public. Les concepteurs du DES cherchaient à remplacer les boîtes style
enigma par du logiciel.

Dans chaque cas, un problème spécifique à résoudre, avec une réponse
précise.

C'est en fait de l'ingénérie, très proche des aspects théoriques purs. Il
ne me vient à l'esprit, à part l'analyse de signaux numériques, aucun autre
domaine où des maths si fondamentales soient si proche de la pratique.

C'est surement de l'ignorance de ma part.

Bonjour,

On Fri, 5 Dec 2003, Klopfenstein Michaël wrote:

Ce n'est pas parce qu'une méthode asymétrique ne fait que transporter une
clé, qu'il est interdit
de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique
plus rapide qu'une méthode symétrique, n'y aurait-il pas intérêt à utiliser
uniquement la cryptage asymétrique (par exemple pour crypter des flux de
donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans cesse
une nouvelle clé).

L'avantage présenté ici est négligeable à mesure que la quantité de
données transmises avec la même clé symétrique augmente. Pour un RSA1024,
on ajoute 128 octets de données pour transmetter cette clé de session,
auxquels on ajoute encore quelques octets pour la structure, le protocole,
etc.

Il reste un gros problème, au moins en France. Il est interdit de chiffrer
des données avec une clé de plus de 128 bits (interdit ou difficile
d'accès, c'est à peu près la même chose pour vous et moi). Donc même si on
arrive à faire en sorte que le RSA1024 devienne très rapide, aussi rapide
que l'AES, pas moyen de l'utiliser pour chiffrer les données, je serais
limité à du RSA128, ce qui est ridiculement faible (ça tient environ 30
secondes sur ma brouette à 333 MHz).

Un autre problème avec le RSA, et probablement d'autres cryptosystèmes
asymétriques, il faut 'réserver' quelques octets pour effectuer un padding
(voir PKCS#1, OAEP, et un autre papier ISO "je-sais-plus-combien"), cela
fait donc autant de données transmises en moins, et ce pour chaque bloc
(un bloc fait 128 octets pour une clé RSA1024). Avec un cryptosystème
symétrique par blocs (tel que l'AES), on ajoute quelques octets à la fin
du flux transmis, c'est tout.

Si c'est le cas il devient réellement très utile d'avori
une petite idée de comparé RSA et AES. Mais évidemment, il me semble avoir
compris que ce n'est pas le cas, il me semble que RSA est plus lent, est-ce
faux ?

RSA est effectivement plus lent que l'AES, à sécurité égale, ce qui ne pas
être montré par la comparaison entre un AES128 et un RSA128. Mais je pense
que même un RSA128 est plus lent qu'un AES128.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Nos ennemis sont les ennemis de Jehovah, s'ils se fâchent. Il est à Lui,
pas nous. Je vois que mes français sont un aussi bon que votre anglais.
-+-J in: Guide du Neuneu Usenet - Le nombre ne fait rien à l'affaire -+-

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

Ce n'est pas parce qu'une méthode asymétrique ne fait que transporter une
clé, qu'il est interdit
de s'interroger sur : et si l'on parvenait à faire une méthode asymétrique
plus rapide qu'une méthode symétrique, n'y aurait-il pas intérêt à
utiliser

uniquement la cryptage asymétrique (par exemple pour crypter des flux de
donnée, cela présenterait un réel avantage : pas besoin d'envoyer sans
cesse

une nouvelle clé). Si c'est le cas il devient réellement très utile
d'avori

une petite idée de comparé RSA et AES. Mais évidemment, il me semble
avoir

compris que ce n'est pas le cas, il me semble que RSA est plus lent,
est-ce

faux ?
Vous vous intéressez à la vitesse de cryptage du RSA pour la comparer à

d'autres algorithmes symétriques. Je n'ai pas compris dans le site
http://www.eskimo.com/~weidai/benchmarks.html (merci à Pierre Vandevenne
pour l'information du site) qu'on fasse une distinction entre les vitesses
de chiffrement et déchiffrement en prenant une clef particulière (k).
Etant donné que la vitesse de chiffrement est fonction du nombre de bits
égaux à 1, on peut estimer que statiquement la moitié des bits sont égaux à
1, l'autre moitié à 0. Pourquoi ne pas faire le test suivant? On part d'une
entrée et d'une clef égales et aléatoires, et on chiffre un très grand
nombre de fois en adoptant à chaque fois comme donnée et clef, le résultat
du chiffrement précédent. Ainsi on pourra obtenir une meilleure valeur
moyenne de la vitesse de chiffrement pour une longueur de clef déterminée.
C'est cette méthode que j'ai utilisée pour mesurer la vitesse de chiffrement
de mon algorithme SED. En effet, l'algorithme SED
doit être considéré comme ayant une structure semblable au RSA avec la
différence qu'on travaille modulo-2 et que les multiplications arithmétiques
modulaires sont remplacées par des multiplications matricielles. On effectue
1000 chiffrements consécutifs, au premier chiffrement la clef (128 bits) et
vecteur d'entrée sont égaux et pris au hasard, ensuite à chaque chiffrement,
on reprend la clef et le vecteur d'entrée égales au résultat du chiffrement
précédent. Mon ordinateur travaille à 1 Ghz et je trouve comme résultat 1,8
seconde pour 16000 caractères. Les petites variations sont
vraisemblablement dues à des microcoupures commandées par le
microprocesseur. voir www.ulb.ac.be/di/scsi/classicsys/classicvite.zip

Vous dites "pas besoin d'envoyer sans cesse une nouvelle clef". Je suis
entièrement de votre avis et c'est la méthode utilisée par mon cryptosystème
ClassicSys. L'algorithme SED utilise deux clefs différentes, l'une pour le
chiffrement et l'autre pour le déchiffrement. Chaque utilisateur dispose
d'une clef privée et la clef conjuguée est recalculable par l'organisme de
confiance avec le chiffrement du numéro d'affiliation de cet utilisateur et
la clef secrète de l'organisme de confiance. La clef privée de l'utilisateur
sert à calculer les clefs de session et cette clef ne figure nulle part en
clair. Vous me direz peut-être qu'un bidouilleur est capable de la
recalculer. C'est vrai, mais si la clef est enfouie dans un circuit intégré
qui effectue les chiffrements, la chose n'est plus possible.

ClassicSys est un programme servant à démontrer la faisabilité d'un
cryptosystème utilisant l'algorithme SED, celui-ci étant enfoui dans un
circuit intégré avec la clef privée. Néanmoins, il est possible d'adopter
une solution "tout software", mais dans ces conditions, tout chiffrement à
l'aide de la clef privé pour produire une signature doit être entérinée par
l'organisme de confiance.

Bien à vous

Emile