PGP encryption and decryption

CFT provides end-to-end security by decrypting files for scanning and re-encrypting them before delivery. This ensures continuous security while allowing for malware detection.

Quick reference

• Standard: OpenPGP RFC 4880 compliant. Any tool compliant with this standard should work seamlessly with CFT.

• Default behaviour: Data is encrypted at-rest and in-transit even if PGP is disabled.

• Key ownership: Decryption is only possible for files encrypted with a CFT-generated key. To understand more about the process, continue reading below.

Prerequisites

Before configuring your workflow, ensure your PGP keys and encrypted files adhere to the following security standards.

Inbound transfers (sender file decryption)

If you are sending encrypted files to CFT for decryption, your encryption tool must support and enable the following:

• Enable Modification Detection Code (MDC) in encrypted files

  • Modification Detection Code (MDC) is a packet in a PGP-encrypted file which is used to detect message modification, protecting the integrity of the encrypted file. Refer to RFC 4880 for more information.

  • Encrypted files uploaded with missing or incorrect MDC will fail decryption, and the file will not be transferred successfully. This is to ensure that the file was not tampered with by an attacker, and also serves as a form of authentication to verify that the file was encrypted by the expected sender.

• Supported algorithms:

  • Hash algorithms: SHA1, SHA224, SHA256, SHA384, SHA512, SHA3_256, SHA3_512
  • Cipher algorithms: AES128, AES192, AES256, Triple DES, CAST5

Outbound transfers (receiver file encryption)

If CFT is encrypting your files for the receiver, your provided public key must meet these criteria:

• Ensure that the Encrypt Communications binary flag (0x04) is part of the Receiver key signature.

  • This flag indicates that the key may be used to encrypt communications, i.e. files to be encrypted for the receiver. Refer to RFC 4880 for more information.

  • If a key lacks this flag, CFT will not accept it as a valid key for encryption due to several security considerations. For instance, using a key for unintended purposes can lead to unexpected behaviour or weak encryption. Additionally, if a key gets compromised, it can lead to key revocation issues.

• Validate the public key for encryption using GPG. Follow the steps provided here.

• Ensure that the key is in either PGP ASCII-armored or Binary format.

• Ensure that the key size is not more than 2048 bits.

Important notes

• Only PGP ASCII-armored and binary formats are supported.

• Public certificates and keys generated by CFT have a default and recommended validity of 1 year. Do not input a validity of more than 1 year without first contacting CFT for the required waivers and processes.

• When PGP decryption is enabled, the .pgp file extension is automatically removed from the filename post-decryption. Conversely, when PGP encryption is enabled, the .pgp file extension is appended to the filename.

Setup guide

PGP sender decryption setup

Follow these steps to set up PGP sender decryption.

PGP receiver encryption setup

Follow these steps to set up PGP receiver encryption.

Validate PGP public key for encryption using GPG

Before adding your PGP public key to the CFT Admin Portal for Receiver encryption, you can validate it using GPG.

Prerequisites

• Install GnuPG (GPG)

  • For Windows, install GPG4Win.
  • For Mac, install GPG using Homebrew by running brew install gnupg on your Terminal.

• Ensure your PGP public key is imported into your GPG keyring. You can import a key using this command gpg --import <path-to-key-file> on your Command Prompt or Terminal.

On your Command Prompt or Terminal, do the following:

1. Use the command gpg --list-keys to list your keys.

2. Identify the key you want to validate.

3. Run the following command gpg --edit-key <key-id>, replacing <key-id> with your actual key ID or email.

4. Type list in the gpg edit mode to see the key details.

5. Look for usage: E in the key details.

   • E indicates that the key (or subkey) can be used for encryption.

   • If the primary key has E, it can be used for encryption, but it’s recommended to use a subkey for this purpose.

   • If the primary key lacks E, encryption won’t work without a subkey.

     Note: Use a subkey for encryption to minimise exposure of your primary key.

Troubleshooting

If you encounter errors, refer to PGP Error Troubleshooting.