Erreur mdc lors du décryptage du message GPG

Question

J'ai un système client et serveur qui exécute régulièrement des tâches planifiées et communique via des fichiers xml qui ont été cryptés par gpg. Toutes les clés publiques requises ont été échangées avec succès entre le client et le serveur. Les appels de cryptage et de décryptage sont effectués à partir d'un fichier de traitement par lots.

encrypt syntaxe

gpg.exe --batch --yes --recipient% 1 --output% 4% 5 --passphrase --local utilisateur% 2% 3 --sign --encrypt

decrypt syntaxe

gpg.exe --batch --yes --output% 3% 4 --passphrase --decrypt% 2 2>% 1

Le client crée un fichier xml, crypte avec gpg en utilisant la clé publique du serveur, signe avec la clé privée et la télécharge sur le site ftp du serveur. Le serveur vérifie régulièrement les nouveaux fichiers dans le dossier ftp. Pour tout nouveau fichier, il décrypte en utilisant gpg, puis traite le fichier XML dans le fichier.

Pour certains des fichiers XML que le serveur tente de déchiffrer, je reçois une erreur comme suit:

GPG: block_filter 00AA8400: erreur de lecture (taille = 7841, a-> size = 395)

GPG: mdc_packet avec encodage incorrect

GPG: Echec du déchiffrement: paquet invalide

GPG: block_filter: octets en attente!

Le point à noter est que cela ne se produit pas avec tous les fichiers mais avec seulement quelques fichiers. Je n'ai pas été en mesure de trouver des points communs entre les fichiers sur lesquels il échoue.

Est-ce que quelqu'un connaît ce que cette erreur signifie? toutes les suggestions pour aider à suivre ce sont les bienvenus.

Answer 1

Enfin compris. gpg n'était pas le coupable ici. Lorsque le serveur recherchait des fichiers dans le dossier spécifié, il utilisait la méthode Append (fileHandler) sur Delphi pour tester si le fichier pouvait être ouvert. Mais cette méthode avait une condition particulière comme si elle trouvait le caractère ascii 26 (c.-à-d. CTRL + z) dans le dernier bloc de 128 octets du fichier, il supprimerait tout de ce caractère jusqu'à la fin du fichier. Cela a provoqué la suppression d'une partie des fichiers cryptés, ce qui a provoqué l'erreur ci-dessus lors du décryptage via gpg. Après avoir remplacé la méthode Append avec Reset (fileHandler), les fichiers cryptés ne sont plus modifiés et le décryptage fonctionne parfaitement.