0
votes

Erreur Mismatch Tag Lors de la déchiffrement de la clé à l'aide de Google Tink Library

Je suis nouveau à la cryptographie. Je travaille sur un POC pour chiffrer et décrypter une chaîne. Lorsque je déchiffre la chaîne cryptée, cela fonctionne parfois, mais d'autres fois lance une erreur d'inadéquation des balises. Est-ce que je manque quelque chose?

Voici mon code: xxx

exception: Info: Prefix CIPHERText correspond à une clé, mais ne peut pas déchiffrer: Javax.Crypto.aadbadTagException: MisMatch Tag! com.Cencryption.api.service.cryptionServiceImpltest> Décrypte a échoué xxx

Décryptage a échoué Java.Security.GeneralSecurityException: Décryptage échoué chez com.google.crypto.tink.aead.Aeadfactory $ 1.Decrypt (Aeadfactory.java:109) à com.cryption.api.service.cryptionServiceImpl.decrypt (encryptionserviceImpl.java:53) à com.cryption.api.service.cryptionServiceImpltest.decrypt (encryptionserviceImpltest.java:25) sur sun.reflect.nativeméthodaccessorimpl.invoke0 (méthode natif) à sun.reflect.nativemethodaccessorimpl.invoke (NativeMethaccessorimpl.java:62) À Sun.Refflect.DelegingMethodaccessorimpl.invoke (DéléguerMethodaccessorimpl.java:43) à java.lang.reflect.method.invoke (méthode.java:498) à org.junit.runners.model.frameworkMethod $ 1.RunReflectivecall (FramewordMethod.java:50) à org.junit.internal.runners.model.reflecturectiveCallable.run (reflectreCallable.java:12) à org.junit.runners.model.frameworkMethod.invokeExplosivité (frameworkmethod.java:47) à org.junit.internal.runners.statifs.invokemethod.évaluez (invoquethod.java:17) à org.junit.runners.parentrunner.runleaf (Partrunner.java:325) à org.junit.runners.blockjunit4ClassRunner.runchild (blockjunit4ClassRunner.java:78) à org.junit.runners.blockjunit4ClassRunner.runchild (blockjunit4ClassRunner.java:57) à org.junit.runners.parentrunner $ 3.Run (Partrunner.java:290) à org.junit.runners.parentrunner $ 1.schedule (Partrunner.java:71) à org.junit.runners.parentrunner.runchildren (Partrunner.java:288) à org.junit.runners.parentrunner.access $ 000 (Partrunner.java:58) à org.junit.runners.parentrunner $ 2.Valuat (Partrunner.java:268) à org.junit.runners.parentrunner.run (Partrunner.java:363) à org.gradle.api.internal.tasks.testing.junit.junittestestClassexecuter.RunestClass (JunittestClassexecuter.java:114) à org.gradle.api.internal.tasks.testing.junit.junittestClassexecuter.execute (junitestclassexecuter.java:57) à org.gradle.api.internal.tasks.testing.junit.junittestClassProcessor.Processtestclass (junitestClassProcessor.java:66) à org.gradle.api.internal.tasks.testing.SuitéTestSclassProcessor.ProcessTestClass (SuitestestClassProcessor.java:51) sur sun.reflect.nativeméthodaccessorimpl.invoke0 (méthode natif) à sun.reflect.nativemethodaccessorimpl.invoke (NativeMethaccessorimpl.java:62) À Sun.Refflect.DelegingMethodaccessorimpl.invoke (DéléguerMethodaccessorimpl.java:43) à java.lang.reflect.method.invoke (méthode.java:498) à org.gradle.internal.dispatch.reflectiondispatch.dispatch (reflexionDispatch.java:35) à org.gradle.internal.dispatch.reflectiondispatch.dispatch (réflexionDispatch.java:24) à org.gradle.internal.dispatch.ContextClassloaderDisPatch.dispatch (contextClassLoaderDispatch.java:32) à org.gradle.internal.dispatch.proxydispatchadapter $ DispatchingInvocalisationHandler.invoke (proxydispatchadapter.java:93) à com.sun.proxy. $ proxy1.Processtestclass (source inconnue) à org.gradle.api.internal.tasks.testing.worker.testworker.Processtestclass (testworker.java:108) sur sun.reflect.nativeméthodaccessorimpl.invoke0 (méthode natif) à sun.reflect.nativemethodaccessorimpl.invoke (NativeMethaccessorimpl.java:62) À Sun.Refflect.DelegingMethodaccessorimpl.invoke (DéléguerMethodaccessorimpl.java:43) à java.lang.reflect.method.invoke (méthode.java:498) à org.gradle.internal.dispatch.reflectiondispatch.dispatch (reflexionDispatch.java:35) à org.gradle.internal.dispatch.reflectiondispatch.dispatch (réflexionDispatch.java:24) à org.gradle.internal.remote.internal.hub.MessageHubbackedObjectConnection $ Dispatchwrapper.dispatch (MessageHubbackedObjectConnection.java:146) à org.gradle.internal.remote.internal.hub.MessageHubbackedObjectConnection $ Dispatchwrapper.dispatch (MessageHubbackedObjectConnection.java:128) à org.gradle.internal.remote.internal.hub.MessageHub $ handler.run (messageHub.java:404) à org.gradle.internal.concurrent.ExecutivePolicy $ CatchandrecordFailures.onxecute (Executorpolicy.java:63) à org.gradle.internal.concurrent.ConCurrentExecutorImpl $ 1.Run (ManagementEdexecutorImpl.java:46) À Java.Util.ConCurrent.Trunworker (ThreadpoolExecutor.java:1149) à Java.Util.ConCurrent.TrunderPoolEcutor $ travailleur.Run (threadpoolexecutor.java:624) à org.gradle.internal.concurrent.threadfactoryImpl $ gasthedTheadRunable.run (TrainFactoryImpl.java:55) à java.lang.thread.run (thread.java:748)

1 test Terminé, 1 échec


0 commentaires

3 Réponses :


2
votes

Si la séquence d'octets d'un message crypté est stockée dans une chaîne, un encodage approprié doit être utilisé. Un moyen approprié signifie que l'encodage doit permettre à tous les octets ou combinaisons d'octets dans la séquence. Si ce n'est pas le cas, les valeurs de la séquence d'octets sont automatiquement modifiées et inaperçues pendant le stockage. Si un tableau d'octets est ensuite reconstruit à partir de la chaîne pendant le décryptage, les tableaux d'octets d'origine et reconstruits diffèrent et le décryptage échoue. Ceci est très bien expliqué ici .

Depuis AES-GCM génère un nouveau vecteur d'initialisation pour chaque cryptage, le crypté Le message est différent pour chaque cryptage, même avec un texte clair identique.

Les deux conduisent au fait que, dans votre exemple, le cryptage fonctionne parfois et parfois non: chaque fois que la séquence d'octets est compatible avec le codage que vous utilisez, les travaux de décryptage, sinon pas.

Si vous souhaitez être indépendant d'un codage, utilisez simplement le tableau des octets lui-même, c'est-à-dire que le chiffrement -Method renvoie le tableau d'octet au lieu d'une chaîne et analogue, au lieu d'une chaîne Byte-Array est transmis au Decrypt -Method.


4 commentaires

Merci pour l'aide. Cela a fonctionné après avoir ajouté le codage ISO-8859-1 comme suggéré dans le lien que vous avez partagé.


Par souci de complétude: si le message crypté est déjà stocké dans une chaîne, le codage de base64- et hexadécimal doit également être pris en compte. Carte chaque la valeur de tous les caractères lisibles, que ISO-8859-1 ne fait pas (par exemple, les valeurs des 0x80 à 0x9f ne sont pas attribué à n'importe quel caractère de l'ISO-8859-1). Parfois, ça compte. Mais malgré cela, la norme ISO-8859-1 résout bien sûr le problème actuel. Juste un rappel, au lieu d'une chaîne, le tableau d'octets peut être utilisé directement, de sorte qu'il n'y ait aucune dépendance sur le codage du tout.


J'ai évité la chaîne et traiter directement avec le cryptage Byte-Array et Base64. Je vois toujours ce problème parfois ... Voici mon code changé:


Pour que tout le monde joue avec ce temps lors de l'utilisation de Testng: Testg convertira vos billets [] en cordes lorsque vous appelez Assergequals (octets [], octets []) et cela conduira au problème décrit ici.



0
votes

J'ai révisé le code mais je vois toujours que le déchiffrement échoue pour la même demande parfois. xxx

}


1 commentaires

Je ne trouve pas de bogue dans le code actuel. J'ai adapté l'ancien test Junit et j'ai testé le nouveau code. Aucune erreur ne s'est produite dans 100 points. À titre de comparaison: le taux d'erreur de l'ancien code était d'environ 50%. Donc, je ne peux pas reproduire la question. Êtes-vous éventuellement utiliser le mauvais test? Mais il y a aussi des informations manquantes pour une analyse plus détaillée, par ex. À quoi ressemble le test Junit du nouveau code et quel texte brut est utilisé? Le message d'erreur est-il identique? À quelle fréquence l'erreur se produit-elle?



0
votes

Je n'ai aussi pas eu d'erreur dans le code lorsque j'ai couru dans la machine locale. Mais quand j'ai déployé dans Cloud (Google Cloud) J'ai commencé à voir une erreur.

Voici mon code junit: xxx

}


5 commentaires

La connexion avec le cloud Google aurait été une information importante que vous auriez pu mentionner plus tôt. Le problème actuel n'est probablement pas un problème de cryptage, mais dépend de l'environnement de test choisi. Essayez la modification suivante: Modifiez le modificateur d'accès du utils -Constructeur de privé à public et utilisez un distinct -Instance dans le chiffrer -Method du test JUNIT et analogue, un distinct - -Instance dans le Decrypt -method de Le test Junit-Test chacun avec Utils Cryptologicutils = Nouveaux Utils () . Vérifiez à nouveau si le problème persiste.


Je recommande également de ne pas envoyer de réponses avec plus de questions. Au lieu de cela, vous pouvez modifier votre ancienne question, ajouter un commentaire ou poser une nouvelle question. Sinon, il va devenir déroutant.


On dirait que je ne pourrai pas déchiffrer la même chaîne de différentes instances Aead. J'ai modifié le code et a créé le pubic Utils et créé une nouvelle instance pour chiffrer et une nouvelle instance pour déchiffrer. Le Decrypt a échoué avec une erreur d'échec du déchiffrement. Comme ce que je vois dans le nuage. Voici mon code de test: @Test Public Void Decrypt () lance IoException, généralesCryptionException {String Cryptedtext = Nouveau Utils2 (). Crypter ("Bonjour 123456"); String DecrypedText = Nouveau Utils2 (). Decrypt (chiffrementText); assertThat (Decrypedtext, Matchers.is ("Bonjour 123456")); }


C'est probablement ce qui se passe dans le nuage. J'ai deux cas dans le nuage avec chacun ayant sa propre instance d'Alead. Le texte crypté d'une instance ne peut pas être déchiffré dans un autre cas


J'ai créé un nouveau message pour ajouter une certaine clarté à ma question - Stackoverflow.com / Questions / 55692186 / ...