Veuillez pardonner mon innacceptable ignorance a ce sujet, alors pour me faire pardonner, je pose la question:

Comment peut on dire que tel nombre peut il être 40 bits ou bien 128 ou même 512?

Par exemple 6023589 est un nombre de combien de bits? J´aimerais juste une explication pour reconnaitre que tel nombre fait tant de bits, parce que j´ai regardé des sites qui traitaient de crypto, j´ai accroché, mais je pigeais pas le système des bits...

Voila,
Merci!!!

Un bit peut prendre deux valeurs 0 ou 1.
Donc faut d´abord que tu convertisses ton nombre au système binaire et après tu peux compter le " nombre de chiffres" ( nombre de bits en fait).
Par exemple 1 donne 1 en système binaire.
2 donne 10 ( ça se lit pas dix mais un zéro) 2 bits au total.
3 donne 11. ( tjrs deux bits)
4 donne 100. ( trois bits)
5 donne 101 ( trois bits)
etc...

Ah oui si tu veux convertir un nombre d´un système à un autre, tu peux utiliser la calculette windows en mode scientifique ( faut choisir le mode dans le menu en haut).
Et si tu veux comprendre comment la calculette fait ça :
http://www.coder-studio.com/?page=tutoriaux_aff&code=autre_2
Ca parle aussi du système héxadécimal qui est aussi pas mal utilisé.

Ok merci beaucoup!

tu prends la puissance de 2 la plus proche supérieure à ce nombre et l´exposant te donne le nombre de bits significatifs du nombre
ex 6023589 => 2^23 => 23 bits
naturellement l´utilisation d´un tel nombre dans un système de cryptage tel que RSA serait plus que catastrophique ( qqes dixièmes de secondes pour le factoriser , dc on utilise souvent des modules de 512 bits ( ce qui représente en notation décimale quelques centaines de chiffres..)

@+

ex 6023589 => 2^23 => 23 bits

nan

ex: 2 = 2^1 => 2 bits ( 10 )

/ kUfa

kufa vérifie, mais il a raison !
6023589 => 2^23 => 10110111110100110100101 => 23 bits

[...] la plus proche *supérieure* à ce nombre [...]
et jusqu´à preuve du contraire la puissance de 2 la plus proche supérieure à 2 c´est 2^2, donc on retrouve bien 2 bits

Ok, et en crypto RSA, la clé qui fait xBits, c´est " n", non?

j ai pas tout lu, je disais juste que ton ex etait faut

Où est-il faut ?
La valeur décimale 6023589 est codé sur 23 bits minimum !

RedRick, oui, c´est " n" c´est a dire le produit des 2 nombres premier qui doit faire 512 bits par exemple.

Car les autre nombre en jeu ( les clef d et e peuvent être très petites sans que la sécurité du système ne soit menacé, se qui n´est pas le cas pour les générateurs p et q qui sont censé être aussi grand que possible l´un et l´autre).

OK, merci beaucoup, c´ets le genre de petit détails dont on parle pas!

Pour stocker le nombre 2^x il faut x+1 bits, on est d accord
ex:

1 = 2^0 => 1 bit
2 = 2^1 => 2 bits
3 = 2^1 + 2^0 => 2 bits

Je suis ok sur l ex: 2^22 < 6023589 < 2^23

J ai juste tjs pas lu: " tu prends la puissance de 2 la plus proche supérieure"

la première pharse du cinquième messages.

« les clef d et e peuvent être très petites sans que la sécurité du système ne soit menacé »

c´est en partie vrai pour l´exposant public e ( sauf situation particulière cf. attaque via théorème des restes chinois), auquel on attribue souvent une petite valeur pour augmenter la vitesse du chiffrement. en revanche l´utilisation d´un exposant privé trop petit ( inférieur au quart de la taille de n) n´est pas sûre, car une méthode mise au point par Wiener permet d´en retrouver la valeur, en se basant sur le développement en fractions continues
(http://www.labri.fr/Perso/~betrema/deug/poly/anne<BR>xes/fc.html ) du quotient e/n, l´un des dénominateurs des réduites obtenues est alors le d.
l´algorithme rsa en lui-même reste relativement sûr, mais s´il est mal implémenté... :p

@+

mal implémentez l´algorithme est un jeu d´enfants ( Cf mon implémentation perso...)

je ne connait pas l´attaque de Wiener dont tu parle, mais puice que le sytème est syétrique, est ce que ça ne voudrait pas dire que e aussi souffre de cette limitation ?

pour moi, e est la clef publique et d la clef privé.
Hors on préconise justement de choisir e le plus grand possible ce qui fait evidemment d plus petit. Mais peut-être que cette spécification est antérieur à la découverte de cette faille.

( ma page sur le sujet : http://perso.wanadoo.fr/sectionpc/tpe_cryptage/crypto/4.htm )

je ne connait pas l´attaque de Wiener dont tu parle, mais puice que le sytème est syétrique, est ce que ça ne voudrait pas dire que e aussi souffre de cette limitation ?

l´inverse est bien sûr possible ( retrouver e en décomposant d/n en fractions continues) mais j´en vois mal l´intérêt, connaître la clé privée impliquant de connaître la clé publique ( qui de toute façon est déjà connue puisque publique!)

pour moi, e est la clef publique et d la clef privé.
Hors on préconise justement de choisir e le plus grand possible ce qui fait evidemment d plus petit. Mais peut-être que cette spécification est antérieur à la découverte de cette faille.

non, c´est justement le contraire, on privilégie toujours la vitesse des opérations publiques ( ie. de chiffrement) aux opérations privées, en donnant une petite valeur à e ( 65537 est généralement un bon choix, du fait de sa représentation binaire constituée principalement de 0 ce qui accroit la vitesse du chiffrement lors des opérations d´exponentiation modulaire). et donc choisir un d trop petit est un danger du point de vue de la sécurité

@+

si on fixe la valeur de e, on ne " choisit" pas celle de d, d étant obtenue par la formule :
e*d congrue à 1 modulo ( p-1)*(q-1)
avec n=p*q ou p et q sont deux très grand nombre premier.

donc, si tu dit : e=65537 alors tu n´a pas le choix pour d.

sans compter que e doit être premier avec ( p-1)*(q-1) donc on ne peut pas arbitrairement choisir 2^16 + 1 ( pa que des zéro dans le nombre).

" et donc choisir un d trop petit est un danger du point de vue de la sécurité" je ne comprend pas le " et donc" tu parle de privilégié la vitesse, pas de sécurité. bien sur, il est evident qu´un d trop petit est un danger ( ne serait-ce que parce qu´on paut le chercher en essayant systématiquement tout les d possible).

si on fixe la valeur de e, on ne " choisit" pas celle de d, d étant obtenue par la formule :
e*d congrue à 1 modulo ( p-1)*(q-1)
avec n=p*q ou p et q sont deux très grand nombre premier.

donc, si tu dit : e=65537 alors tu n´a pas le choix pour d.

bien sûr, étant donné que d est déterminé en fonction de e et n, et donc est unique, que e soit fixé ou non, le terme " choisit" est en effet mal adapté

sans compter que e doit être premier avec ( p-1)*(q-1) donc on ne peut pas arbitrairement choisir 2^16 + 1 ( pa que des zéro dans le nombre).

il est évident que si l´on veut choisir une certaine valeur pour e il faut s´assurer qu´il soit premier avec phi(n).

" et donc choisir un d trop petit est un danger du point de vue de la sécurité" je ne comprend pas le " et donc" tu parle de privilégié la vitesse, pas de sécurité. bien sur, il est evident qu´un d trop petit est un danger ( ne serait-ce que parce qu´on paut le chercher en essayant systématiquement tout les d possible).

oui ma phrase n´était pas très claire =o, avec un e petit, on a un d grand, donc le chiffrement sera plus rapide que le déchiffrement, si on prend un e grand et un d petit ce sera le contraire, mais prendre un d trop petit sera dangeureux cf. attaque énoncée