D'un point de vue théorique, si tu considères que ton algorithme de chiffrement est parfait, la 'sécurité' du chiffrage ne dépend que de la longueur de la clef.
Donc, si ton algo est parfait et si tu as une clef de 1024 bits, la seule solution pour le "méchant cracker vilain pas beau" est de passer en revue les 2 EXP 1024 clefs possibles (donc, en moyenne, il trouvera la clef après 2 EXP 1023 essais).
Mais en pratique, tu peux avoir des 'failles' qui te permettent d'éviter de devoir passer toutes les clefs possibles en revue.
Soit c'est l'implémentation de l'algo qui est défectueuse. Soit c'est l'algo lui meme qui contient des 'raccourcis' (voulus ou pas).
En fait, la sécurité absolue existe : c'est le One-Time-Pad. Ca consiste (en gros) à générer *vraiment* aléatoirement une clef aussi longue que ton message. C'est pas facile à mettre en oeuvre, ça ne peut servir qu'une fois, mais c'est le chiffrement ultime (enfin à mon sens hein :-) )
[^] # Re: 1024, 2048, etc
Posté par Salica . En réponse à la dépêche Fork d'OpenBSD. Évalué à 10.
Donc, si ton algo est parfait et si tu as une clef de 1024 bits, la seule solution pour le "méchant cracker vilain pas beau" est de passer en revue les 2 EXP 1024 clefs possibles (donc, en moyenne, il trouvera la clef après 2 EXP 1023 essais).
Mais en pratique, tu peux avoir des 'failles' qui te permettent d'éviter de devoir passer toutes les clefs possibles en revue.
Soit c'est l'implémentation de l'algo qui est défectueuse. Soit c'est l'algo lui meme qui contient des 'raccourcis' (voulus ou pas).
En fait, la sécurité absolue existe : c'est le One-Time-Pad. Ca consiste (en gros) à générer *vraiment* aléatoirement une clef aussi longue que ton message. C'est pas facile à mettre en oeuvre, ça ne peut servir qu'une fois, mais c'est le chiffrement ultime (enfin à mon sens hein :-) )