D'accord, il s'avère que je suce au cryptage / décryptage. Je ne comprends juste pas.
Comment puis-je faire Java Encrypt Si vous avez le temps de fournir le code le plus basique, cela m'aiderait beaucoup.
Aussi 1 question générale sur le cryptage AES, en utilisant le même sel, le même message aura-t-il toujours le même cryptage?
Merci d'avance. String Message1 = "Hello World"; avec STRING SEL = "MYSALT"; Utilisation du cryptage AES? aussi comment puis-je le décrypter une fois crypté?
4 Réponses :
AES n'a pas de concept de sel. Il faut juste des données et une clé. Pour la même entrée, il générera toujours la même sortie.
Comment vous combinez votre message avec votre sel est à vous de choisir. La concaténation de la chaîne est probablement suffisante. Mais notez que les sels n'ont pas vraiment de sens pour quelque chose comme des AES, car ce n'est pas un algorithme de hachage.
AES est juste le chiffre. Le IV fait partie du mode de fonctionnement.
Attendez, maintenant je suis très confus, alors comment pouvez-vous chiffrer une chaîne que vous ne serez capable de déchiffrer avec un "mot de passe" spécifique ou "clé" ou quelque chose?
@cody: Comme je l'ai dit, AES prend Data et une clé .
@cody: Eh bien, je suppose que vous pourriez appeler cela une graine, oui.
Umm, ahh tellement déroutant. Alors pourriez-vous m'aider à créer le code le plus basique qui cryptera un message simple avec une clé simple? S'il te plaît et merci :)
@cody: le code ici semble raisonnable (je suis pas un expert en train de faire spécifiquement des AES en Java). Ce code génère une clé pour vous, vous pouvez toujours enregistrer cela ou le remplacer par vous-même.
@Oli Charlesworth D'accord Merci, BTW, vous avez dit que la graine d'AES n'a pas de sens, quelle cryptage de hachage puis-je utiliser en Java qui me permet d'inverser avec une clé?
@Cody: J'ai dit qu'un sel n'a pas de sens pour les AES. Et vous ne pouvez pas inverser un hachage; exactement!
@oli Charlesworth oh, lol (je suce à cela) Bien merci pour votre aide, je regarde juste le code que vous m'avez envoyé et j'essaie de faire utiliser un sel statique, pas seulement à 100% d'où la clé est.
Lorsque vous utilisez des AES avec une valeur de sel, la valeur du sel diffère du texte à chiffrer - mais la clé reste identique - dans ce cas, vous devez également stocker la valeur du sel.
ici est un bon exemple. ..
Yah, j'ai vu ça, mais je ne pouvais même pas le faire courir, il compilait avec 2 avertissements (qui conviennent à ce code puisqu'il utilise des paquets Sun) mais je ne pouvais pas le faire courir, quelque chose à propos de l'emballage non trouvé .. .: S
Son juste cryptage / décryptage avec normal AES - rien de nouveau - Vous devez simplement ajouter une valeur de sel et vous assurer de la stocker pour le décryptage.
Sel toujours vos fichiers AES. La raison en est que vous avez un répertoire de fichiers JPEG chiffré chiffré avec le même mot de passe, mais vous n'avez pas de sel. Si quelqu'un tire la maintien de ces fichiers, ils verront que tous les fichiers commencent par les mêmes octets (car c'est-à-dire que l'en-tête JPEG et la même phrase secrète seront toujours chiffrées aux mêmes valeurs jusqu'à ce que les octets commencent à différer, au moins avec une CBC) Ils sauront également ce que les premiers blocs du fichier ressembleront à être non crypté. Même s'ils ne savent pas quel type de fichiers ils sont, ils peuvent probablement deviner le type de la longueur de l'avance à ceux qui sont similaires et les différents formats de fichiers là-bas.
Connaître cela, ils peuvent inverser l'ingénieur votre mot de passe d'une manière similaire aux tables arc-en-ciel / la force brute. Salting n'arrêtera pas cela se produire, mais rendra vraiment difficile de craquer au fur et à mesure que chaque fichier (après le sel) sera différent de sorte que l'identification de type de fichier est difficile, plus ils devraient générer une table arc-en-ciel pour chaque sel ou le surcharge de calcul de créer un vecteur d'initialisation pour le sel.
OpenSSSL stocke le sel dans le fichier
E.g. J'ai créé un fichier à l'aide de cette commande avec un mot de passe de «mot de passe»: [James @ web openssltest] $ hexdump message.c et les mêmes données lorsque je dirigeais à nouveau le cryptage: -
[James @ web openssltest] $ hexdump message1.enc Les 4 premiers octets disent que le fichier est salé ( 6153 746C 6465 5F5F ) et sera toujours le même.
Les 4 octets suivants sont le sel aléatoire ( 7AA C4FD 63D8 8C8 pour premier fichier & A876 5394 53F1 BF1A pour le deuxième fichier)
OpenSSL prendra ce sel et construit le vecteur d'initialisation (IV), étant un hachage de MD5 du mot de passe + sel répété 3 fois. Cet IV est ensuite utilisé pour chiffrer le fichier.
Notez que la charge utile des 8 derniers octets de chaque cas est différente.
Si nous avons couru la même commande tout en ne salant pas:
[James @ Web OpensSltest] $ Echo "Randomprhase" | OpenSSL AES-128-CBC -NOSALT -OUT NOSALT.ENCE
[James @ Web OpensSltest] $ Echo "Randomprhase" | OpenSSL AES-128-CBC -NOSALT -OUT NOSALT1.ENCE
[James @ web openssltest] $ hexdump nosalt.enc [James @ web opensSltest] $ hexdump nosalt1.enc Notez que lorsque je l'ai répété en utilisant le même mot de passe et spécifié pour ne pas sel, les charges utiles sont identiques.
Dans une implémentation Java, vous pouvez stocker votre sel séparément, mais la peine de passer votre temps à écrire quelque chose qui émule l'implémentation OpenSSL afin de ne pas avoir à compter sur votre propre code pour déchiffrer un fichier (surtout si vous perdez votre code à certains. Point à l'avenir, le cryptage peut vous contrecarrer autant que cela peut contrecarrer un attaquant).
Echo "Randomprhase" | OpenSSL AES-128-CBC -OUT Message.Ce
Voici le hexdump du fichier résultant: -
0000000 6153 746C 6465 5F5F 7EAA C4FD 63D8 8C8C
0000010 9519 75C9 0497 D449 27F5 2C91 0D34 5EB
0000020
0000000 6153 746C 6465 5F5F A876 5394 53F1 BF1A
0000010 ADCB E1CD DBA9 8034 CF13 8B3F C37C 5048
0000020
0000000 947E F4ab 6DD7 C548 89E4 B587 82F4 5136
0000010
0000000 947E F4ab 6DD7 C548 89E4 B587 82F4 5136
0000010
Avec Spring Security Crypto, il est simplifié (principalement parce qu'ils sont par défaut du cryptage basé sur le mot de passe plutôt que d'autres formes): AES est juste un chiffre et vous pouvez utiliser un IV avec le texte que vous cryptage.
Avec un cryptage symétrique, le sel est utilisé pour la clé / secret que vous chiffriez avec, comme vous pouvez le voir ci-dessus. Dans le monde réel, vous devrez traiter des systèmes distribués, des clés partagées et des sels à travers le Cluster, etc., etc. Beaucoup de plaisir. Sécurité du ressort est une mince abstraction sur JCE, il est donc facile de s'adapter si vous n'utilisez pas le printemps lui-même.
Je trouve cette solution élégante si vous souhaitez implémenter rapidement un système de cryptage.
Dupliqué possible de java 256bit AES cryptage
Quelque chose me dit que vous ne devriez probablement pas essayer de déployer un logiciel important avant d'être beaucoup plus à la maison avec la cryptographie. AES est juste un chiffre, vous devez toujours choisir un mode et une clé et de vecteur d'initialisation schéma. Les sels n'ont rien à voir avec le cryptage (plutôt avec hachage ).
Thilo, j'ai vu cet article, malheureusement, je ne pouvais pas comprendre quoi que ce soit: S Kerrek SB, je sais que je fais juste pour mes propres connaissances, mon expérience.