For Encryption and Decryption of data we are using Private and Public keys with Base64 Encoded including subkey, which were generated using GNUPG 2.2.x tool, this tool has been suggested by Pega team but we are still getting data Job failure passing these key.
Here’s the quick fix path. First, don’t double-Base64 the keys: use the ASCII-armored outputs from GnuPG directly and paste the full BEGIN/END blocks into Enable data protection on the File Data Set; ASCII armor is already Base64. Second, export the actual encryption subkey, not just the primary key: gpg --export -a > public.asc and gpg --export-secret-subkeys -a > private.asc; then supply the passphrase in Pega if the key is protected. Third, use OpenPGP/PGP (not X.509/SSH) and RSA 2048+; avoid ECC unless your Pega version explicitly lists it as supported. Fourth, keep manifest, data, and token in the same repository folder; the manifest’s file paths must be relative to the repo root, and the token file is what triggers the job. Fifth, validate the manifest fields and record count; mismatches or a missing token commonly cause “data job” failures. Sixth, test decryption outside Pega on the same files with gpg --decrypt to rule out key or passphrase issues. Finally, if it still fails, switch to a single-subkey keypair (no extra subkeys), re-export armored keys, and retry—this aligns with Pega’s import job encryption expectations and known troubleshooting for token/manifest jobs