Algorithme de cryptage de hachage auto-modifiable

Question

Je cherche un algorithme pour changer ses clés à chaque période et je peux encore le déchiffrer. Fondamentalement, je cherche un moyen de maintenir un lien sécurisé entre les clients mobiles et un serveur stationnaire de telle sorte que même si vous avez intercepté le hachage ou même les informations d'authentification eux-mêmes, ils changeraient des deux côtés chaque période.
Cela vous dit quelque chose?
Y a-t-il une meilleure façon de s'assurer que même si vous interceptez les informations d'authentification, elles ne seront valides que pour une certaine requête d'un certain utilisateur?

Answer 1

Je recommanderais SSL au lieu d'implémenter un algorithme de chiffrement vous-même (il SERA cassé si les données que vous essayez de protéger est assez importante!). SSL est bien testé. avec SSL, vous pouvez utiliser des certificats au lieu de logins/mots de passe. SSL empêche la relecture et les attaques intermédiaires (il utilise une poignée de main au début pour s'assurer qu'une nouvelle clé de session est utilisée pour chaque connexion et que les deux parties sont ce qu'elles prétendent être).

Une autre chose intéressante qui vient à l'esprit est le SecurID de RSA. il fournit une clé matérielle qui change toutes les 60 secondes: http://www.rsa.com/node.aspx?id=1156

Answer 2

C'est certainement possible - juste par exemple, le chiffre japonais Purple pendant la seconde guerre mondiale l'a fait. Alors qu'un tel chiffre peut certainement être difficile, il peut également être cassé (Purple était).

La raison est assez simple: votre expéditeur et votre récepteur doivent générer de nouvelles clés synchronisées pour que le destinataire déchiffre les messages. Cela signifie essentiellement que vous avez besoin de quelque chose comme un générateur de nombres aléatoires sécurisé pour générer de nouvelles clés. Bien que cela puisse être difficile à rompre (avec une période assez longue et autres), c'est toujours une technique de cryptage assez normale, et cela dépend d'avoir un générateur de nombres aléatoires sécurisé. Une fois que vous avez cela, cependant, vous ne gagnez généralement pas beaucoup à utiliser la sortie du générateur plus directement (par exemple, comme la clé pour un chiffrement Vernam).

Answer 3

Je suggère simplement d'utiliser SSL. Il est conçu pour être raisonnablement résistant aux attaques de l'homme dans le milieu, ce qui est ce que je suppose être votre préoccupation.

Ou peut-être Kerberos.

Ne pas coder les algorithmes de chiffrement vous-même.

Answer 4

Je suppose que vous parlez de trouver un moyen de changer périodiquement la clé cryptographique utilisée dans votre algorithme, de sorte que même si une clé est découverte, alors seulement les données cryptées avec cette clé serait possible de décoder? Si nous évitons de nous inquiéter du processus de démarrage, alors une façon de le faire serait d'encoder une partie (mais pas toutes) de vos clés suivantes dans l'ensemble de données chiffrées avec une clé, et comme vous changez de clés, crypter partie des clés suivantes avec la nouvelle clé. Par exemple, disons que vos clés ont 8 éléments de largeur (où un élément peut être un octet, un mot de 32 bits ou autre), et nous étiquetons les clés que vous utilisez pour chiffrer un bloc de données donné comme Kn, où 'n' est le bloc de données chiffrées avec cette clé. Nous allons indexer les éléments de la clé en disant Kn [0] pour le 1er élément, jusqu'à Kn [7] pour le 8ème. Nous appellerons également ce bloc de données Dn. Ensuite, le texte en clair Dn inclurait Kn + 1 [0], Kn + 2 [1], Kn + 3 [2], ..., Kn + 8 [7]. Si vous étiez en mesure de décrypter Dn-7 .. Dn, vous aurez reconstruit Kn + 1 entièrement, de sorte que vous puissiez ensuite déchiffrer le bloc de données suivant, et ainsi de suite. Vous devez obtenir le texte en clair pour plusieurs blocs en séquence avant de pouvoir déchiffrer de manière fiable le reste des données, bien que l'obtention du texte en clair pour un bloc donné facilite les attaques contre les clés du reste.

La configuration initiale est un problème plus difficile. SSL serait un bon moyen de distribuer K0, K1 [1..7], K2 [2..7], ..., K7 [7].

Je ne suis pas un cryptographe professionnel, donc je ne suis pas complètement sûr de la sécurité. Cet algorithme vous est offert TEL QUEL, sans garantie d'aucune sorte.