Discussion :

[Feldunost]

Bonjour,


J'aurais besoin d'une confirmation et d'informations supplémentaires.

Actuellement, je suis en train de réfléchir sur Eclipse au niveau paquets. Théoriquement l'algorithme Blowfish est le même pour tous, seules les clés de cryptage / décryptage changent.
Donc, les classes Java qui traitent de l'algorithme Blowfish sont-elles les mêmes pour toutes (ou la majorité) des applications Java ?


J'ai une clé qui est plus longue que l'autre et théoriquement une seule clé (la même) est utilisée pour crypter et décrypter.
Puisque le client (non modifiable) est censé posséder la clé de cryptage et l'on ne souhaite pas la changer, il est donc nécessaire de réutiliser les clés.
Cependant, si le client possède la clé de cryptage, qui est symétrique dans les implémentations de Blowfish ... n'importe qui pourrait en faire ce qu'il veut, et la sécurité est nulle ?!


J'ai un client et un serveur, je sais à quoi un paquet ressemble plus ou moins, mais y aurait-il un outil permettant de crypter/décrypter rapidement le contenu d'un paquet récupéré, sachant que chaque set de données a une signification précise.



Les informations sont les suivantes:

PBox Key
0x88 0x6A 0x3F 0x24 0x0D3 8 0xA3 0x85 0x2E 0x8A 0x19 0x13 0x44 0x73 0x70 3 0x22 0x38 9 0x0A4 0x0D0
0x31 0x9F 0x29 0x98 0x0FA 0x2E 8 0x89 0x6c 0x4E 0x0EC

SBox Key
0x0A6 0x0B 0x31 0x0D1 0x0AC 0x0B5 0x0DF 0x98 0xDB 0x72 0xFD 0x2F 0x0B7 0x0DF 0x1A 0x0D0 0x0ED 0x0AF 0x0E1
0x0B8 0x96 0x7E 0x26 0x6A 0x45 0x90 0x7C 0x0BA 0x99 0x7F 0x2C 0x0F1 0x47 0x99 0x0A1 0x24 0x0F7 0x6C 0x91 0x0B3
0x0E2 0x0F2 1 8 0x16 0x0FC 0x8E 0x85 0x0D8 0x20 0x69 0x63 0x69 0x4E 0x57 0x71 0x0A3 0x0FE 0x58 0x0A4 0x7E 0x3D
0x93 0x0F4 0x8F 0x74 0x95 0x0D 0x58 0x0B6 0x8E 0x72 0x58 0x0CD 0x8B 0x71 0x0EE 0x4A 0x15 0x82 0x1D 0x0A4
0x54 0x7B 0x0B5 0x59 0x5A 0x0C2

Or, je vois mal à quoi correspondent ces clés, serait-ce un algorithme asymétrique d'après ce que j'ai pu observer ? Comment réutiliser ces deux clés dans une application login (partie serveur) et avec quelles classes ?


C'est un peu confus...

Merci d'avance pour vos éclaircissements.

[Feldunost]

Bon un petit état des connaissances supplémentaires que j'ai pu assimiler:

(Tiré de Wikipédia)
Blowfish utilise une taille de bloc de 64 bits et la clé, de longueur variable, peut aller de 32 à 448 bits.
Blowfish est basé sur un schéma de Feistel avec 16 tours et utilise des S-Boxes de grande taille qui dépendent de la clé. Il ressemble à CAST-128 qui a adopté, quant à lui, des S-Boxes au contenu fixé d'avance.


Or, il semblerait que là, le SBox est fixé d'avance, donc la clé serait la PBox ?


L'algorithme comme on peut le voir ici: http://www.schneier.com/blowfish-download.html
Est le même pour tous, seulement dans Java, la classe MyBlowfish semble pouvoir être utilisée, mais comment définir les Sbox et la PBox ? ...

[Feldunost]

Bonsoir,


Je cherche toujours à comprendre le principe du cryptage blowfish, j'ai pas mal de questions, donc si quelqu'un connaît ne serait-ce un peu mieux ce domaine que wikipédia, je serais pas contre.


Merci.

[Marco46]

Alors en tout premier, un peu de vocabulaire :

Chiffrer : C'est l'acte de rendre illisibles des données en clair. Ca se fait avec les algorithmes symétriques au moyen d'une clef unique, la clef de chiffrement.
Déchiffrer : C'est l'acte de rendre lisibles des données rendues illisibles par un algorithme de chiffrement symétrique en utilisant la même clef qui avait été utilisée pour chiffrer.
Décrypter : C'est l'acte de rendre lisibles des données rendues illisibles par un algorithme de chiffrement symétrique en découvrant quelle a été la clef qui avait été utilisée pour chiffrer.

Quelques algorithmes symétriques : AES, 3DES, Blowfish.

Afin de rendre l'échange de clefs symétriques sécurisé, les algorithmes de chiffrements asymétriques furent inventés. Le fonctionnement est le suivant, l'expéditeur des données à chiffrer effectue son chiffrement symétrique classique, puis il chiffre la clef utilisée (appelée alors clef de session) avec la clef publique du destinataire. Il emballe la clef de session chiffrée avec les données chiffrées et il envoie le tout au destinataire.
Le destinataire utilise sa clef privée correspondant à la clef publique utilisée par l'expéditeur pour déchiffrer la clef de session, puis il déchiffre avec la clef de session les données et les obtient alors en clair.
Notes que les clefs publiques et privées fonctionnent par coupe. Les deux sont générées dans cet exemple par le destinataire, qui met à disposition de tout le monde sa clef publique et uniquement sa clef publique.

Quelques algorithmes asymétriques : RSA, ElGamal.

Tous ces algorithmes utilisent une clef d'une longueur fixée à l'avance. Leurs mécanismes internes (les algorithmes en eux-mêmes) sont basés sur les mathématiques.
Plus la clef est longue, plus l'attaquant qui voudrait décrypter (donc transformer les données chiffrées en données en clair sans posséder la clef) va avoir besoin de temps pour tester toutes les combinaisons possibles.
En d'autres termes, plus la clef est longue, plus c'est dur à casser, et dans certains cas c'est même considéré comme impossible en l'état actuel. Par exemple AES avec des longueurs de clefs de 256 bits ou RSA avec des longueurs de clefs de 2048 bits sont considérés comme inviolables.

J'espère que ça pourra t'aider.

Au fait, tu veux faire quoi ?

Sur tes questions :

Actuellement, je suis en train de réfléchir sur Eclipse au niveau paquets. Théoriquement l'algorithme Blowfish est le même pour tous, seules les clés de cryptage / décryptage changent.
Donc, les classes Java qui traitent de l'algorithme Blowfish sont-elles les mêmes pour toutes (ou la majorité) des applications Java ?

Oui et non. Blowfish en lui-même est une sorte de norme. Il indique en "pseudo-code" comment mettre en oeuvre Blowfish.
Le JDK contient des classes qui permettent de mettre en oeuvre cet algorithme. Le pseudo-code a été codé par Sun, à la manière de Sun. C'est une implémentation.
BouncyCastle implémente également l'algorithme Blowfish, à sa sauce à lui.
Il y a dans la JCA un mécanisme de Provider permettant de choisir quelle implémentation ton application Java va choisir par défaut pour effectuer les opérations de sécurité.

Puisque le client (non modifiable) est censé posséder la clé de cryptage et l'on ne souhaite pas la changer, il est donc nécessaire de réutiliser les clés.
Cependant, si le client possède la clé de cryptage, qui est symétrique dans les implémentations de Blowfish ... n'importe qui pourrait en faire ce qu'il veut, et la sécurité est nulle ?!

Oui. C'est pourquoi on utilise un algorithme asymétrique pour chiffrer la clef symétrique.

J'ai un client et un serveur, je sais à quoi un paquet ressemble plus ou moins, mais y aurait-il un outil permettant de crypter/décrypter rapidement le contenu d'un paquet récupéré, sachant que chaque set de données a une signification précise.

Crypter n'existe pas.
Décrypter c'est quand on connait pas la clef, donc probablement qu'on est dans un cas où l'on cherche à pirater les donnes.
Déchiffrer c'est quand on a la clef, généralement fourni via un algorithme asymétrique.

Or, je vois mal à quoi correspondent ces clés, serait-ce un algorithme asymétrique d'après ce que j'ai pu observer ?

Ces clefs sont utilisées dans la mécanique interne de l'algorithme Blowfish. Elles sont spécifiques à Blowfish et tu n'as pas à t'en préoccuper. Pour infos elles servent à rendre le décryptage (et pas le déchiffrement, tu noteras l'importance d'utiliser le bon vocabulaire) plus difficile.

Comment réutiliser ces deux clés dans une application login (partie serveur) et avec quelles classes ?

Tu n'as pas à les utiliser. Ignores les.

Du coup j'ai répondu à ton 2ème post.


D'une manière générale, la cryptographie est un domaine compliqué qui nécessite de maitriser au préalable des concepts théoriques généraux (hash, algorithme symétrique, algorithme asymétrique, signature électronique, PKI, certificats ...) avant de rentrer dans le détail des algorithmes. Je te suggère de commencer par là.