Bonjour =E0 tous,
dans l'example que j'ai trouv=E9 sur le site
http://www.rtfm.com/sslbook/examples/c-examples.tar.gz
Dans le programme sserver.c, je vois qu'on utilise deux fonctions :
--->load_dh_params
--->generate_eph_rsa_key
qui sont d=E9finies dans server.c
Or, je ne comprend pas pourquoi on a besoin de cr=E9er les param=E8tres
de Deffie-hellman dans ce cas. Si j'ai bien compris, les cryptages
asym=E9triques sont utilis=E9s pour crypter une cl=E9 secr=E8te sym=E9trique
afin de la transmettre en toute s=E9curit=E9 sur le r=E9seau. Or, ici on
utilise deux fois des algo asym=E9trique =E0 savoir DH et RSA. Je pensais
que le RSA =E9tait suffisant dans ce cas pour crypter une cl=E9 secr=E8te
sym=E9trique et l'envoyer au client qui la d=E9cryptera avec la cl=E9
publique contenue dans le certificat du serveur.
Aussi j'ai pas bien compris l'hisoire de cl=E9 =E9ph=E9m=E8re g=E9ner=E9e
avec les deux fonctions
---> RSA_generate_key + SSL_CTX_set_tmp_rsa
Pour l'instant je pense que ca sera =E0 crypter les cl=E9s sym=E9trique
avec des cl=E9s diff=E9rentes pour chaque client mais je ne suis pas sur.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
pornin
According to :
Or, je ne comprend pas pourquoi on a besoin de créer les paramètres de Diffie-hellman dans ce cas. Si j'ai bien compris, les cryptages asymétriques sont utilisés pour crypter une clé secrète symétrique afin de la transmettre en toute sécurité sur le réseau. Or, ici on utilise deux fois des algo asymétrique à savoir DH et RSA. Je pensais que le RSA était suffisant dans ce cas pour crypter une clé secrète symétrique et l'envoyer au client qui la décryptera avec la clé publique contenue dans le certificat du serveur.
Je suppose qu'il s'agit d'un serveur SSL (dit aussi TLS).
En SSL, le client et le serveur se mettent d'accord sur la façon dont il vont se mettre d'accord sur une clé de session. Ça dépend de ce que le serveur possède comme clé asymétrique, de ce que le client et le serveur supportent, et de ce que le client et le serveur veulent.
Une première méthode d'échange est un bête chiffrement RSA. Ça ne marche que si le serveur possède une clé RSA ; dans ce cas, le client choisit une clé aléatoire, la chiffre avec la clé publique RSA du serveur (celle dans son certificat) et lui envoie le résultat. Le serveur, à l'aide de la clé privée correspondante, fait le déchiffrement et obtient la clé de session.
Une autre méthode est de passer par du Diffie-Hellman : le client et le serveur font du Diffie-Hellman, sur des paramètres envoyés par le serveur. Le serveur utilise alors sa clé (RSA ou DSS) pour _signer_ sa moitié du Diffie-Hellman. Cette méthode d'échange est dite "DHE" (comme "Diffie-Hellman Ephemeral"). Par rapport au RSA brut, les intérêts sont les suivants :
-- ça marche avec des clés de signature (comme clés DSS, ou clés RSA dans un certificat qui restreint l'utilisation à la signature) ;
-- ça permet d'utiliser des certificats de signature, pour lesquels la législation de certains pays est (ou était) moins restrictive que pour les clés de chiffrement (jusqu'à il y a quelques années, aux États-Unis, les clés RSA de chiffrement étaient limitées à 512 bits, alors que celles de signature pouvaient monter à 1024 bits) ;
-- ça ajoute la "Perfect Forward Secrecy" : si le serveur se fait ensuite piquer sa clé privée RSA, la confidentialité des données échangées préalablement n'est pas remise en cause (celui qui a volé la clé privée peut _ensuite_ se faire passer pour le serveur, mais tout ce qui a été envoyé avant est chiffré par une clé de session Diffie-Hellman à laquelle le méchant n'a pas accès).
Le problème majeur de la méthode "DHE" est qu'elle coûte plus cher en temps de calcul, surtout pour le client (grosso-modo, ça multiplie par deux le coût pour le serveur, et par environ 40 pour le client). Mais c'est rarement grave, le client ayant du cpu à perdre.
Tous les détails sont dans la RFC 2246 : http://www.faqs.org/rfcs/rfc2246.html
--Thomas Pornin
PS : "cryptage" et "crypter" n'existent pas en français. On dit "chiffrement" et "chiffrer".
According to <skalli14@yahoo.fr>:
Or, je ne comprend pas pourquoi on a besoin de créer les paramètres
de Diffie-hellman dans ce cas. Si j'ai bien compris, les cryptages
asymétriques sont utilisés pour crypter une clé secrète symétrique
afin de la transmettre en toute sécurité sur le réseau. Or, ici on
utilise deux fois des algo asymétrique à savoir DH et RSA. Je pensais
que le RSA était suffisant dans ce cas pour crypter une clé secrète
symétrique et l'envoyer au client qui la décryptera avec la clé
publique contenue dans le certificat du serveur.
Je suppose qu'il s'agit d'un serveur SSL (dit aussi TLS).
En SSL, le client et le serveur se mettent d'accord sur la façon dont
il vont se mettre d'accord sur une clé de session. Ça dépend de ce que
le serveur possède comme clé asymétrique, de ce que le client et le
serveur supportent, et de ce que le client et le serveur veulent.
Une première méthode d'échange est un bête chiffrement RSA. Ça ne marche
que si le serveur possède une clé RSA ; dans ce cas, le client choisit
une clé aléatoire, la chiffre avec la clé publique RSA du serveur (celle
dans son certificat) et lui envoie le résultat. Le serveur, à l'aide de
la clé privée correspondante, fait le déchiffrement et obtient la clé de
session.
Une autre méthode est de passer par du Diffie-Hellman : le client et
le serveur font du Diffie-Hellman, sur des paramètres envoyés par le
serveur. Le serveur utilise alors sa clé (RSA ou DSS) pour _signer_ sa
moitié du Diffie-Hellman. Cette méthode d'échange est dite "DHE" (comme
"Diffie-Hellman Ephemeral"). Par rapport au RSA brut, les intérêts
sont les suivants :
-- ça marche avec des clés de signature (comme clés DSS, ou clés RSA
dans un certificat qui restreint l'utilisation à la signature) ;
-- ça permet d'utiliser des certificats de signature, pour lesquels la
législation de certains pays est (ou était) moins restrictive que pour
les clés de chiffrement (jusqu'à il y a quelques années, aux États-Unis,
les clés RSA de chiffrement étaient limitées à 512 bits, alors que
celles de signature pouvaient monter à 1024 bits) ;
-- ça ajoute la "Perfect Forward Secrecy" : si le serveur se fait
ensuite piquer sa clé privée RSA, la confidentialité des données
échangées préalablement n'est pas remise en cause (celui qui a volé la
clé privée peut _ensuite_ se faire passer pour le serveur, mais tout ce
qui a été envoyé avant est chiffré par une clé de session Diffie-Hellman
à laquelle le méchant n'a pas accès).
Le problème majeur de la méthode "DHE" est qu'elle coûte plus cher en
temps de calcul, surtout pour le client (grosso-modo, ça multiplie par
deux le coût pour le serveur, et par environ 40 pour le client). Mais
c'est rarement grave, le client ayant du cpu à perdre.
Tous les détails sont dans la RFC 2246 :
http://www.faqs.org/rfcs/rfc2246.html
--Thomas Pornin
PS : "cryptage" et "crypter" n'existent pas en français. On dit
"chiffrement" et "chiffrer".
Or, je ne comprend pas pourquoi on a besoin de créer les paramètres de Diffie-hellman dans ce cas. Si j'ai bien compris, les cryptages asymétriques sont utilisés pour crypter une clé secrète symétrique afin de la transmettre en toute sécurité sur le réseau. Or, ici on utilise deux fois des algo asymétrique à savoir DH et RSA. Je pensais que le RSA était suffisant dans ce cas pour crypter une clé secrète symétrique et l'envoyer au client qui la décryptera avec la clé publique contenue dans le certificat du serveur.
Je suppose qu'il s'agit d'un serveur SSL (dit aussi TLS).
En SSL, le client et le serveur se mettent d'accord sur la façon dont il vont se mettre d'accord sur une clé de session. Ça dépend de ce que le serveur possède comme clé asymétrique, de ce que le client et le serveur supportent, et de ce que le client et le serveur veulent.
Une première méthode d'échange est un bête chiffrement RSA. Ça ne marche que si le serveur possède une clé RSA ; dans ce cas, le client choisit une clé aléatoire, la chiffre avec la clé publique RSA du serveur (celle dans son certificat) et lui envoie le résultat. Le serveur, à l'aide de la clé privée correspondante, fait le déchiffrement et obtient la clé de session.
Une autre méthode est de passer par du Diffie-Hellman : le client et le serveur font du Diffie-Hellman, sur des paramètres envoyés par le serveur. Le serveur utilise alors sa clé (RSA ou DSS) pour _signer_ sa moitié du Diffie-Hellman. Cette méthode d'échange est dite "DHE" (comme "Diffie-Hellman Ephemeral"). Par rapport au RSA brut, les intérêts sont les suivants :
-- ça marche avec des clés de signature (comme clés DSS, ou clés RSA dans un certificat qui restreint l'utilisation à la signature) ;
-- ça permet d'utiliser des certificats de signature, pour lesquels la législation de certains pays est (ou était) moins restrictive que pour les clés de chiffrement (jusqu'à il y a quelques années, aux États-Unis, les clés RSA de chiffrement étaient limitées à 512 bits, alors que celles de signature pouvaient monter à 1024 bits) ;
-- ça ajoute la "Perfect Forward Secrecy" : si le serveur se fait ensuite piquer sa clé privée RSA, la confidentialité des données échangées préalablement n'est pas remise en cause (celui qui a volé la clé privée peut _ensuite_ se faire passer pour le serveur, mais tout ce qui a été envoyé avant est chiffré par une clé de session Diffie-Hellman à laquelle le méchant n'a pas accès).
Le problème majeur de la méthode "DHE" est qu'elle coûte plus cher en temps de calcul, surtout pour le client (grosso-modo, ça multiplie par deux le coût pour le serveur, et par environ 40 pour le client). Mais c'est rarement grave, le client ayant du cpu à perdre.
Tous les détails sont dans la RFC 2246 : http://www.faqs.org/rfcs/rfc2246.html
--Thomas Pornin
PS : "cryptage" et "crypter" n'existent pas en français. On dit "chiffrement" et "chiffrer".
skalli14
Merci beaucoup pour ta réponse trés claire. J'avais des doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer au RSA et ne laisser le clé privée RSA que pour les signature. C'est encore plus prudent.
Une petite question au passage, avec openssl on peut voir les performences de chaque algorithme en faissant : openssl speed rsa (pour avoir les perfs du rsa ) Moi par example j'ai eu les résultats suivant : Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in 9.86s Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in 9.84s
Une paire de clef RSA de 1024 bits prend alors 4,7 secondes a etre generee. Ce n'est pas un peu trop long ....
Merci beaucoup pour ta réponse trés claire. J'avais des doutes sur
tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est
encore mieu de l'associer au RSA et ne laisser le clé privée RSA que
pour les signature. C'est encore plus prudent.
Une petite question au passage, avec openssl on peut voir les
performences de chaque algorithme en faissant : openssl speed rsa (pour
avoir les perfs du rsa )
Moi par example j'ai eu les résultats suivant :
Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in
9.86s
Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in
9.84s
Une paire de clef RSA de 1024 bits prend alors 4,7 secondes a etre
generee. Ce n'est pas un peu trop long ....
Merci beaucoup pour ta réponse trés claire. J'avais des doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer au RSA et ne laisser le clé privée RSA que pour les signature. C'est encore plus prudent.
Une petite question au passage, avec openssl on peut voir les performences de chaque algorithme en faissant : openssl speed rsa (pour avoir les perfs du rsa ) Moi par example j'ai eu les résultats suivant : Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in 9.86s Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in 9.84s
Une paire de clef RSA de 1024 bits prend alors 4,7 secondes a etre generee. Ce n'est pas un peu trop long ....
skalli14
Merci beaucoup pour ta réponse trés claire. Ce que j'en déduit c'est que c'est la clé secrète de DH qui permettra de chiffrer la clé symétrique que le serveur générera et qui permettra de chiffer les communications par la suite. J'avais des doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer au RSA et ne laisser le clé privée RSA que pour les signature. C'est encore plus prudent.
Une petite question au passage, avec openssl on peut voir les performences de chaque algorithme en faissant : openssl speed rsa (pour avoir les perfs du rsa ) Moi par example j'ai eu les résultats suivant : Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in 9.86s Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in 9.84s
Une paire de clef RSA de 1024 bits prendrait alors 4,7 secondes a etre generee. Ce n'est pas un peu trop long ....
Merci beaucoup pour ta réponse trés claire. Ce que j'en déduit c'est
que c'est la clé secrète de DH qui permettra de chiffrer la clé
symétrique que le serveur générera et qui permettra de chiffer les
communications par la suite. J'avais des doutes sur tout ca. Finalement
ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer
au RSA et ne laisser le clé privée RSA que pour les signature. C'est
encore plus prudent.
Une petite question au passage, avec openssl on peut voir les
performences de chaque algorithme en faissant : openssl speed rsa (pour
avoir les perfs du rsa )
Moi par example j'ai eu les résultats suivant :
Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in
9.86s
Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in
9.84s
Une paire de clef RSA de 1024 bits prendrait alors 4,7 secondes a etre
generee. Ce n'est pas un peu trop long ....
Merci beaucoup pour ta réponse trés claire. Ce que j'en déduit c'est que c'est la clé secrète de DH qui permettra de chiffrer la clé symétrique que le serveur générera et qui permettra de chiffer les communications par la suite. J'avais des doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer au RSA et ne laisser le clé privée RSA que pour les signature. C'est encore plus prudent.
Une petite question au passage, avec openssl on peut voir les performences de chaque algorithme en faissant : openssl speed rsa (pour avoir les perfs du rsa ) Moi par example j'ai eu les résultats suivant : Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in 9.86s Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in 9.84s
Une paire de clef RSA de 1024 bits prendrait alors 4,7 secondes a etre generee. Ce n'est pas un peu trop long ....
skalli14
Merci beaucoup pour ta réponse trés claire. J'en déduit que c'est la clé secrète de DH qui permettra de chiffrer la clé symétrique qui permettra de chiffer les communications . J'avais des doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer au RSA et ne laisser le clé privée RSA que pour les signature. C'est encore plus prudent.
Merci beaucoup pour ta réponse trés claire. J'en déduit
que c'est la clé secrète de DH qui permettra de chiffrer la clé
symétrique qui permettra de chiffer les communications . J'avais des
doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais
c'est encore mieu de l'associer
au RSA et ne laisser le clé privée RSA que pour les signature. C'est
encore plus prudent.
Merci beaucoup pour ta réponse trés claire. J'en déduit que c'est la clé secrète de DH qui permettra de chiffrer la clé symétrique qui permettra de chiffer les communications . J'avais des doutes sur tout ca. Finalement ce n'est pas obligé d'utiliser DH mais c'est encore mieu de l'associer au RSA et ne laisser le clé privée RSA que pour les signature. C'est encore plus prudent.
pornin
According to :
Une petite question au passage, avec openssl on peut voir les performences de chaque algorithme en faissant : openssl speed rsa (pour avoir les perfs du rsa ) Moi par example j'ai eu les résultats suivant : Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in 9.86s Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in 9.84s
Une paire de clef RSA de 1024 bits prendrait alors 4,7 secondes a etre generee. Ce n'est pas un peu trop long ....
Attention, je détecte un peu de confusion ici.
Une paire de clés RSA doit être générée, c'est-à-dire créée, à un moment donné. Ce processus est potentiellement assez long ; l'ordre de grandeur est effectivement de quelques secondes sur une machine d'il y a quelques années. Mais cette création est hors-sujet dans le cas de SSL : la clé publique est dans le certificat du serveur, certificat qui doit être obtenu préalablement selon des conditions qui ne regardent pas SSL. Un certificat serveur est typiquement valable 1 ou 2 ans (il y a des dates de validité dans un certificat), donc les 4.7 secondes doivent être dépensée une fois par an...
Ensuite, cette paire de clé peut servir de nombreuses fois. Là, c'est beaucoup plus rapide : les chiffres ci-dessus indique qu'OpenSSL est capable d'effecteur 42929 opérations avec la clé publique (c'est-à-dire chiffrement, ou vérification de signature) en 9.84 secondes, c'est-à-dire environ 0.23 millisecondes par opération, soit plus de 4000 par seconde. Les opérations utilisant la clé privée (déchiffrement, ou génération de signature) sont plus lourdes, mais OpenSSL arrive quand même à faire ça plus de 200 fois par seconde.
Dans un serveur SSL avec échange de clé RSA classique (sans Diffie-Hellman), ça signifie que le serveur encaisse plus de 200 connections clientes par seconde, ce qui est très honorable.
--Thomas Pornin
According to <skalli14@yahoo.fr>:
Une petite question au passage, avec openssl on peut voir les
performences de chaque algorithme en faissant : openssl speed rsa (pour
avoir les perfs du rsa )
Moi par example j'ai eu les résultats suivant :
Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in
9.86s
Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in
9.84s
Une paire de clef RSA de 1024 bits prendrait alors 4,7 secondes a etre
generee. Ce n'est pas un peu trop long ....
Attention, je détecte un peu de confusion ici.
Une paire de clés RSA doit être générée, c'est-à-dire créée, à un moment
donné. Ce processus est potentiellement assez long ; l'ordre de grandeur
est effectivement de quelques secondes sur une machine d'il y a quelques
années. Mais cette création est hors-sujet dans le cas de SSL : la clé
publique est dans le certificat du serveur, certificat qui doit être
obtenu préalablement selon des conditions qui ne regardent pas SSL. Un
certificat serveur est typiquement valable 1 ou 2 ans (il y a des dates
de validité dans un certificat), donc les 4.7 secondes doivent être
dépensée une fois par an...
Ensuite, cette paire de clé peut servir de nombreuses fois. Là, c'est
beaucoup plus rapide : les chiffres ci-dessus indique qu'OpenSSL
est capable d'effecteur 42929 opérations avec la clé publique
(c'est-à-dire chiffrement, ou vérification de signature) en 9.84
secondes, c'est-à-dire environ 0.23 millisecondes par opération, soit
plus de 4000 par seconde. Les opérations utilisant la clé privée
(déchiffrement, ou génération de signature) sont plus lourdes, mais
OpenSSL arrive quand même à faire ça plus de 200 fois par seconde.
Dans un serveur SSL avec échange de clé RSA classique (sans
Diffie-Hellman), ça signifie que le serveur encaisse plus de 200
connections clientes par seconde, ce qui est très honorable.
Une petite question au passage, avec openssl on peut voir les performences de chaque algorithme en faissant : openssl speed rsa (pour avoir les perfs du rsa ) Moi par example j'ai eu les résultats suivant : Doing 1024 bit private rsa's for 10s: 2271 1024 bit private RSA's in 9.86s Doing 1024 bit public rsa's for 10s: 42929 1024 bit public RSA's in 9.84s
Une paire de clef RSA de 1024 bits prendrait alors 4,7 secondes a etre generee. Ce n'est pas un peu trop long ....
Attention, je détecte un peu de confusion ici.
Une paire de clés RSA doit être générée, c'est-à-dire créée, à un moment donné. Ce processus est potentiellement assez long ; l'ordre de grandeur est effectivement de quelques secondes sur une machine d'il y a quelques années. Mais cette création est hors-sujet dans le cas de SSL : la clé publique est dans le certificat du serveur, certificat qui doit être obtenu préalablement selon des conditions qui ne regardent pas SSL. Un certificat serveur est typiquement valable 1 ou 2 ans (il y a des dates de validité dans un certificat), donc les 4.7 secondes doivent être dépensée une fois par an...
Ensuite, cette paire de clé peut servir de nombreuses fois. Là, c'est beaucoup plus rapide : les chiffres ci-dessus indique qu'OpenSSL est capable d'effecteur 42929 opérations avec la clé publique (c'est-à-dire chiffrement, ou vérification de signature) en 9.84 secondes, c'est-à-dire environ 0.23 millisecondes par opération, soit plus de 4000 par seconde. Les opérations utilisant la clé privée (déchiffrement, ou génération de signature) sont plus lourdes, mais OpenSSL arrive quand même à faire ça plus de 200 fois par seconde.
Dans un serveur SSL avec échange de clé RSA classique (sans Diffie-Hellman), ça signifie que le serveur encaisse plus de 200 connections clientes par seconde, ce qui est très honorable.
--Thomas Pornin
skalli14
Au fait je me suis trompé, openssl génère 2271 clé privée de 1024 bits en 9.86s , soit paire de clé pub/pv en 4.57ms tout ca avec un P4 2,4 GHZ. C'est donc trés trés honorable . Pour la géneration de ma paire de clé, je compte le faire biensur une seule fois. Les résultats pour les signatures et verification --> sign verify sign/s verify/s rsa 1024 bits 0.0043s 0.0002s 231.2 4371.7 rsa 2048 bits 0.0271s 0.0008s 36.9 1290.3 Sinon, en simulant un client serveur avec openssl j'optient les résultats suivant avec sslv3 : 1550 connections in 7.18s; 215.88 connections/user sec, bytes read 4698050 1550 connections in 31 real seconds, 3031 bytes read per connection
Je pense qu'avec le TLS ca doit etre un peu plus rapide, je ferai le teste une autre fois. Tout ca me fais trés plaisir car je compte utiliser SSL pour crypter des gros flux de données entre clients et serveur.
Au fait je me suis trompé, openssl génère 2271 clé privée de 1024
bits en 9.86s , soit paire de clé pub/pv en 4.57ms tout ca avec un P4
2,4 GHZ. C'est donc trés trés honorable . Pour la géneration de ma
paire de clé, je compte le faire biensur une seule fois. Les
résultats pour les signatures et verification -->
sign verify sign/s verify/s
rsa 1024 bits 0.0043s 0.0002s 231.2 4371.7
rsa 2048 bits 0.0271s 0.0008s 36.9 1290.3
Sinon, en simulant un client serveur avec openssl j'optient les
résultats suivant avec sslv3 :
1550 connections in 7.18s; 215.88 connections/user sec, bytes read
4698050
1550 connections in 31 real seconds, 3031 bytes read per connection
Je pense qu'avec le TLS ca doit etre un peu plus rapide, je ferai le
teste une autre fois. Tout ca me fais trés plaisir car je compte
utiliser SSL pour crypter des gros flux de données entre clients et
serveur.
Au fait je me suis trompé, openssl génère 2271 clé privée de 1024 bits en 9.86s , soit paire de clé pub/pv en 4.57ms tout ca avec un P4 2,4 GHZ. C'est donc trés trés honorable . Pour la géneration de ma paire de clé, je compte le faire biensur une seule fois. Les résultats pour les signatures et verification --> sign verify sign/s verify/s rsa 1024 bits 0.0043s 0.0002s 231.2 4371.7 rsa 2048 bits 0.0271s 0.0008s 36.9 1290.3 Sinon, en simulant un client serveur avec openssl j'optient les résultats suivant avec sslv3 : 1550 connections in 7.18s; 215.88 connections/user sec, bytes read 4698050 1550 connections in 31 real seconds, 3031 bytes read per connection
Je pense qu'avec le TLS ca doit etre un peu plus rapide, je ferai le teste une autre fois. Tout ca me fais trés plaisir car je compte utiliser SSL pour crypter des gros flux de données entre clients et serveur.
