Conseil cryptage de flux

Bonjour à tous :D,

Je vais être amené dans quelques mois à réaliser une application en C sur du AIX, qui va transmettre et recevoir des flux de données, qu'il faudra crypter. J'aurais souhaité avoir des conseils d'experts ou des vétérans en la matière, savoir quels sont les avantages de telle ou telle méthode.

Je me suis renseigné sur l'AES et le RSA. Je ne sais pas quel algorithme est adapté au C, si il existe des librairies ? Les deux sont des algorithmes respectivement symétriques et asymétriques, quel serait le meilleur choix pour du transfert principalement basé sur des chiffres ?

J'ai des connaissances en C, mais malheureusement en crypto ... à part installer des certificats SSL ... :cry:

Merci de vos précieux conseils, je poste ça dès maintenant, mais évidemment je vais continuer de tout comparer et me renseigner :mrgreen:

Je ne saurais trop te conseiller d'utiliser openssl. C'est une bibliothèque cryptographique.

Avec cette bibliothèque, tu vas pouvoir créer un flux réseau chiffré (comme avec un flux ssh) avec les algorithmes de ton choix, RSA et AES (ainsi que beaucoup d'autres) sont supportés.

En plus, j'ai vu que openssl supportait AIX maintenant, faut voir les versions et comment cela s'intègre dans ton environnement de développement.

Bonsoir ram-0000,

Merci beaucoup je vais me renseigner sur cette bibliothèque.
En revanche, j'aurais une question :

l'AES est à privilégier pour du transfert chiffré de valeurs numériques (integer, float, ...) ?

Alors alors alors....
Attention !

AES est un chiffrement symétrique, créé pour supplanter le DES trop ancien.
Symétrique = une clé de chiffrement commune entre les 2 personnes qui souhaitent communiquer.
Cette clé doit donc être échangée de façon "sécurisée" entre les 2 personnes : donc pas de mail ou autre...

RSA est un chiffrement asymétrique, donc à paire de clés publique/privée.
Un émetteur utilise une clé privée (qu'il garde EXCLUSIVEMENT pour lui) pour chiffrer avant l'envoi, et émet des clés publiques à tous les destinataires souhaités pour que ceux-ci puissent déchiffrer les messages.
L'asymétrique s'emploie donc pour des destinataires qui n'ont pas encore de secret commun.

L'asymétrique est "plus lourd" à utiliser, et moins "safe" à cause de la longueur de clé plus faible.
Le symétrique est plus léger, et donc plus "safe" car les clés peuvent être beaucoup plus longues.

L'utilisation "classique" sera : création d'une paire de clés asymétriques chez l'émetteur, pareil chez le destinataire [communications secrètes entre eux] + utilisation de certificats pour assurer l'identité des 2 communicants [assurance que le destinataire est bel et bien celui qu'il dit être], puis échange d'une clé symétrique qui permettra ensuite d'alléger le coût en CPU du chiffrement/déchiffrement.


Ca c'est la partie théorie cryptographique.
En pratique : entraîne toi sur OpenSSL sur un Linux/BSD comme le suggère ram-000.
N'oublie pas que AIX = IBM = Serveur dédié = matériel et libs dédiées made in IBM.
Tu peux être quasiment sûr qu'une lib cryptographique sera fournie par IBM, et utilisera du matériel dédié.
Le matériel sera normalement "transparent" pour toi, tu n'auras qu'à utiliser les fonctions que la documentation te dira d'utiliser.
Tant que tu ne connais pas le travail "exact", fais des petits tests sur OpenSSL pour bien comprendre comment créer des canaux sécurisés, échanger des informations, etc...

Metalman merci pour ces précisions :D

J'ai regardé comment fonctionnait l'AES, et c'est vraiment un procédé super compliqué, qui en plus se répète jusqu'à 14 fois (pour du 256 bits). Translations, polynômes, rotations ... tout y est pour répartir les valeurs depuis la matrice d'origine. Et j'ai donc vu qu'il était incassable au dessus de 9 tours pour une clé de 256 bits.

Bon, comme tu me conseille d'utiliser l'AES, car plus léger, je ne demanderais pas ce qu'il en est de l'algo RSA.

En tout cas je te remercie, toi et ram également.

Je vais commencer des tests de transmissions cryptées, tout d'abord entre deux processus locaux, puis sur du client/serveur TCP et observer les trames, voir ce que ça donne.

Je vous redirais ce que ca donne. Bonne soirée :)

Oulalala !
Tu n'as pas tout compris en fait... :P

1) L'AES n'est pas "incassable" de fait.
Il est considéré comme "sûr" en l'état actuel des machines avec leur puissance de calcul, par rapport à la taille de clé.
Rien n'empêche de faire un gigantesque dictionnaire de toutes les combinaisons possibles des 3 valeurs : "clair" + "clé" = "chiffré"
Juste qu'il faudra être TRES patient et avoir BEAUCOUP de disque pour stocker tout cela.

2) Les 2 méthodes sont nécessaires dans un échange complet.
Tu ne pourras probablement pas tout simuler, car c'est long et contraignant j'en conviens, mais si tu veux un test complet :
- créer une PKI (hrem... bonne chance.)
- générer une paire de clés RSA à un client avec signature dans un certificat
- générer une paire de clés RSA à un serveur avec signature dans un certificat
- générer une clé AES sur le serveur
- faire communiquer serveur et client en RSA
- vérifier les 2 certificats auprès de la PKI
- transmettre la clé AES du serveur vers le client
- ouvrir une communication via tunnel chiffré AES
- fermer la communication RSA
- .... [faire les échanges du programme] ....
- fermer la communication AES

Cet exemple suppose que les communications vers la PKI (vers la black-list et d'autres services de vérification) sont sûrs...

Pour le moment ce que je te conseille :
- code un échange de données "simple" en AES
- code un échange de données "simple" en RSA
- code un échange de clé via RSA, puis utilise celle-ci pour envoyer une clé AES, fermer la connexion RSA, et échanger des données en AES (le mélange des 2 précédents ! ;) )

3) Rassures-toi, les matrices et tout le tralala internes ne sont pas spécialement nécessaires à connaitre si tu les utilises simplement.
Evite juste de te reposer sur des algorithmes bizarres ou issus de ton imagination... c'est l'erreur numéro 1 que font encore certains "experts en sécurité" malgré TOUTES les recommandations des chercheurs qui passent leurs journées à casser les algos, et démontrer que très peu d'entre eux sont réellement "sûrs" à un moment T.

AES et RSA sont les algorithmes du moment sur les ordinateurs "classiques", utilise-les, maitrise les dans des situations tordues... puis n'hésite pas à les étudier en interne ! :)

ok très bien merci encore pour les infos.

Mais j'avais tout de même vu qu'il était incassable et qu'il n’existait pas de manière réelle de déchiffrer un message, sauf en brute force (avec un super-calculateur comme la machine Chinoise de 33 Petaflops et quelques lol).

Mais j'ai maintenant mieux compris les étapes et le principe. Le RSA permet de générer nos clés pour authentifier les machines comme étant celles qu'elles annoncent être (permettant de vérifier les certificats), puis l'AES nous permet de transférer les données dans un "tunnel" crypté (comme un VPN)

Bon, je vais en premier lieu faire un travail de documentation, maintenant que tu m'as aiguillé vers les grosses étapes à effectuer.
:mouarf:

Citation:

---

Envoyé par Metalman

L'asymétrique est "plus lourd" à utiliser, et moins "safe" à cause de la longueur de clé plus faible.
Le symétrique est plus léger, et donc plus "safe" car les clés peuvent être beaucoup plus longues.

---

:nono:

AES ==> clé de 128, 192 ou 256 (peut être même 512 bits maintenant, je ne sais pas)
RSA ==> clé de 1024, 2048 ou 4096 bits

En fait, en RSA, les clés doivent être plus longues car l'algorithme est moins puissant que AES à protéger ses clés (à taille de clé égale, c'est plus facile de retourner RSA que AES)

Ici, un article qui explique brièvement les différentes méthode de chiffrement : Introduction à la Cryptographie (du code de César à la crypto quantique en passant par Vigenère et Enigma)

Ah, j'avais oublié que la taille des clés avaient été adaptées du même coup...

Mais ça ne retire "que" la partie safe/unsafe.
Ca ne change pas le fait que l'asymétrique sera toujours beaucoup plus lourd à utiliser que le symétrique.

Citation:

---

Envoyé par Metalman

Ca ne change pas le fait que l'asymétrique sera toujours beaucoup plus lourd à utiliser que le symétrique.

---

Effectivement, en général, on dit que l'asymétrique (RSA) est 1000 fois plus lent que le symétrique (AES) au niveau usage de la CPU (je pense que c'est lié à la taille des nombres manipulés, on ne manipule pas des nombres de 2048 bits comme des nombres de 256 bits, les opérations sont un peu plus longues).

Exact...

Déjà, on a du matériel pour "faciliter" les opérations sur les matrices en AES... et ces opérations sont répétitives.

A l'inverse, RSA n'a pas l'air de beaucoup répéter les opérations, et travaille directement sur le bloc de la taille de la clé... et faire un chip avec 1024 * 3 pins autour... hrem... c'est très comique sur papier, et un peu moins à la fonderie... (et on ne va même pas parler des versions 2048 et 4096)