[Cryptographie] Algorithme asymétrique en java

Bonjour à tous,

J'ai un gros problème de cryptage.
En effet je souhaiterai faire la chose suivante :

-Alice génère une clef A en fonction de son environnement et la donne (par téléphone) à Bob.
-Bob génère une nouvelle clef B à partir de cette première clef.
-Bob utilise cette clef B pour crypter un fichier et envois ce fichier à Alice qui le décrypte avec la clef A.

Aujourd'hui j'arrive à crypter / décrypter un fichier avec un algo symétrique (avec une clef unique), mais il me faudrait un algorithme plus complexe...

Quelqu'un aurait il une idée ?

Salut,

Autant utiliser un protocole et un algorithme connu et sûr, plutôt que de réinventer la roue qui sera en plus surement ovale :)
Pour L'échange de clefs : Diffie-Hellman et en Java : http://www.rsa.com/products/bsafe/do...__DH__JCE.html
Ceci dit j'ai un problème avec ce que tu as décrit, je ne vois pas ce que ça apporte.
Le principe des algortihmes asymétriques est justement que tu peux diffuser ta clef publique sans risque que la privée soit retrouvée. La personne qui veut chiffrer quelque chose pour toi utilise ta clef publique et n'a rien d'autre à générer.

Peux-tu réexpliquer ton but ?

A plus

Bonjour,

Depuis hier mon problème a légèrement évolué.

En effet, je m'oriente effectivement dans une solution de type RSA.
Néanmoins, celle ci me fais butter sur de nouveaux problèmes de néophytes.

Pour rappel, je souhaiterai avoir le modèle suivant:
Alice génère une clef A (nombre premier ou non) et l'envoie à Bob.
Bob générer une clef B à partir de la clef A, de telle sorte que seule la clef A peut décrypter le message crypté par la clef A.

A terme il faudrait que Alice soit incapable de connaitre la clef B ou son moyen de calcul.

Il me semble que l'algo RSA peut parfaitement remplir ce rôle, néanmoins j'ai des complications avec l'obtention de la clef de cryptage B tout en ayant déjà la clef de décryptage...

Je ne comprends pas où est la sécurité dans ton modèle... Tu inverses le logique des algorithmes à clef publiques/privées
La clef qui sert à déchiffrer (A dans ton cas apparemment) est la seule qui doit rester privée et connue uniquement de la personne qui doit déchiffrer le message. Dans ton cas, si je suis Eve, j'intercepte A quand Alice l'envoie à Bob, puis dans l'autre sens j'intercepte le message chiffré, et TADADAM, comme j'ai A, je peux déchiffrer...
Donc là j'ai l'impression de ce que tu expliques que tu as inversé la logique. Renseigne toi plus sur le fonctionnement des algorithmes asymétriques, car ça me semble pas clair tout ça :)
Ou alors j'ai pas compris ton problème

Ce que tu décris ressemble un peu à un principe de signature plutôt que de chiffrement, car une seule personne peut "chiffrer" (signer on dit dans ce cas) et tout le monde peut vérifier que c'est à partir d'une clef calculée á aprtir de A, mais lá encore n'importe qui peut créer une clef C à aprtir de A, et Alice pourra penser que ça vient de Bob.

Bref, utilise plutôt des standards, mais avant définis nous ton besoin réel, que veux-tu exactement réaliser (pas avec des Alice et Bob, mais dans ton cas) et on pourra mieux t'orienter

En fait il m'importe peu que quelqu'un intercepte ou non le message.

Plus concrètement je suis dans le cas d'attribution d'une licence.

Le client m'envoie une première clef A composée d'informations personnelles (MAC, Numéro de série de composant, numéro de version...).

A partir de cette clef, je dois en générer une seconde (clef B) qui permettra le cryptage d'un fichier qui ne pourra être décrypté que par la clef A.

Le hic, c'est que le client ne doit pas être en mesure de retrouver comment nous avons calculer la clef B afin de ne pas générer autant de licence qu'il le souhaite (puisque notre fichier une fois crypté ne pourras être décrypté que par une et une seule machine, celle qui a générée la clef A).

RSA ne semble pas en mesure de me satisfaire (j'y ai passé la matinée, et j'ai eu le même constat que vous venez d'exposer). Je vais donc devoir utiliser un autre algorithme ou contourner le problème...

Ok donc tu es dans le cas de la signature numérique et RSA peut très bien servir à ceci... Concrètement comment ça marche ?
Le client t'envoie ses données, toi tu as une paire de clef RSA. Avec ta clef privée tu "chiffres" les données du client (dans ce cas on dit signer) et tu lui envoies le résultat. Comme tu as fait cette opération avec ta clef privée, personne d'autre ne peut faire la même chose. Par contre le client peut lui bien vérifier le contenu en "déchiffrant" ce que tu lui envoies avec ta clef publique, il retrouve alors ses données. C'est la vérification de signature, tout le monde peut vérifier ce que tu as signé, mais toi seul peut signer.
Bon il y a des subtilités, mais heureusement un standard existe (regarde du côté de PKCS#7)
Ne te lance pas dans ta solution maison, à moins d'être expert en crypto (mais je pense que tu demanderais pas ici ;)), car ça sera facilement cassable.

Ton programme utilise ta clef publique pour vérifier que B vient bien de toi. Bref tout cela existe bel et bien et avec RSA :D

Sinon avec Diffie-Hellman on peut faire un truc du genre, mais a priori je dirais plutôt PKCS#7 au premier abord.

Merci, je vais continuer de creuser en ce sens, je vous tient au courant...

Citation:

---

Envoyé par George7

Ton programme utilise ta clef publique pour vérifier que B vient bien de toi. Bref tout cela existe bel et bien et avec RSA :D

---

J'ai parlé avec niluje en privé pour l'aider et en fait le problème est qu'il faudrait que la clé publique puisse être générée par l'appli chez le client. Car la clé publique doit dépendre de l'environnement. C'est ça le plus complexe je pense.

Car en fait son but est d'interdire l'utilisation du logiciel sur un autre PC. Donc dans l'idéal il faudrait que le client génère une clé en fonction de son pc, la donne à niluje qui va générer la clé privée, crypte le logiciel, envoie le logiciel et chez le client à chaque utilisation le logiciel va recalculer la clé publique en fonction du PC et va se décrypter. Ainsi si on met le logiciel sur un autre pc la clé générée ne sera pas la même et le logiciel ne pourra pas se lancer.
Dans l'idée c'est ça je crois.

Citation:

---

Envoyé par Deamon

J'ai parlé avec niluje en privé pour l'aider et en fait le problème est qu'il faudrait que la clé publique puisse être générée par l'appli chez le client. Car la clé publique doit dépendre de l'environnement. C'est ça le plus complexe je pense.

Car en fait son but est d'interdire l'utilisation du logiciel sur un autre PC. Donc dans l'idéal il faudrait que le client génère une clé en fonction de son pc, la donne à niluje qui va générer la clé privée, crypte le logiciel, envoie le logiciel et chez le client à chaque utilisation le logiciel va recalculer la clé publique en fonction du PC et va se décrypter. Ainsi si on met le logiciel sur un autre pc la clé générée ne sera pas la même et le logiciel ne pourra pas se lancer.
Dans l'idée c'est ça je crois.

---

A mais dans mon idée c'est plutôt comme ça (et je l'ai déjà vu plusieurs fois). Les infos de l'ordi sont signée par le distributeur (adresse IP et tout). Au demarrage l'application vérifie la signature des informations pour éviter de falsifier, et utilise ces données signée. Donc on atteint le même but avec des algo éprouvés. La clef est la même mais c'est le principe de signature, ce qui est important est ce qui est signé, c'est là que les informations sont.
Sinon si vous voulez absolument que la clef soit dépendante du client, il faut passer par une procédé genre diffie-hellman mais ça complique énormément tout, car il faudra générer des nombres premiers dépendants de la configuration, et à bon courage...
Donc je pense personnellement que le principe de signer adresse IP, mac, wasauchimmer, est de vérifier au démarrage que la signature est vraie est mieux. En plus j'ai relu l'algorithme proposé et je suis quasi sûr qu'il offre 0 sécurité et que la falsification est plus que simple car, il n'y a aucun secret pour le client vu qu'il est maître de la génération de clef.