Encryption and Key Ownership

Encryption protects different stages of a file's lifecycle. Connection encryption protects a transfer. Storage encryption protects retained data in the storage service. GPG encryption protects the file itself so that decrypting a delivered copy requires the corresponding private key. Decide which stage needs protection and who must be able to read the content before choosing the controls.

Storage and Transfer Encryption

Files.com Native Storage encrypts retained file contents and backups. Authorized Files.com operations can still read those contents: storage encryption does not replace folder permissions or prevent an authorized preview, download, or workflow from using a file. A Remote Server's own storage controls govern the copies retained there.

Connection encryption protects traffic between systems. When a transfer ends, its encrypted connection ends too. If a recipient must retain an encrypted file, or another system must store it without being able to read its contents, use file encryption as part of the delivery process.

Public and Private Keys

GPG uses a public key to encrypt a file and the corresponding private key to decrypt it. You can distribute a public key to senders without giving them the ability to decrypt files encrypted with it. The private key identifies who can recover the content and must be held by the intended decrypting party.

Signing serves a separate purpose: a private key signs a file and the matching public key verifies that signature. A signature alone does not conceal the file's contents. Files.com can encrypt an upload for one or more public keys and optionally sign it with a private key. When a file is encrypted for multiple recipients, any corresponding private key can decrypt it; recipients do not need to combine their keys.

A TLS certificate's private key and an SFTP server host key establish a server's identity. A user's SSH key authenticates a user. These keys have different roles from a GPG key that protects file contents, and changing one does not rotate the others.

Choosing Where Decryption Happens

If Files.com holds only a recipient's public key, it can prepare encrypted deliveries for that recipient without holding the private key needed to decrypt them. If you configure Files.com to decrypt incoming files, Files.com needs the corresponding private key and processes the resulting readable content. That choice determines which systems must be trusted with the contents.

The GPG Key Manager stores keys used by folder processing. Automatic decryption can use a selected private key or any matching stored key available in the same workspace. Selecting a particular key makes the accepted delivery relationship explicit. The option to use any matching key requires Site or Workspace Administration because it permits decryption with the workspace's matching keys.

Folder Administrators can configure applicable folder processing, so delegation includes decisions about how incoming files are encrypted or decrypted. Review that authority together with the folder's upload and download permissions. Encryption of a file does not undo copies already supplied to recipients who could read them.

Processing New Uploads

Automatic GPG encryption and decryption apply to new uploads in the configured scope. Turning a setting on does not process files already stored in the folder. Establish the receiving folder's settings before starting a delivery, and separately plan any conversion of existing files.

When processing is required before delivery to a Remote Server, Files.com may temporarily stage the upload. The retained encrypted file and any temporary processing copies answer different questions about data handling. Transfer Data Paths and Temporary Storage explains that distinction.

Expiration and Removal

Keys must remain valid for the configured work. Files.com does not use expired GPG keys or expired required subkeys to encrypt, sign, or decrypt files. This includes decrypting older files that were encrypted before expiration. Renewing the same key can preserve the ability to decrypt those files; an unrelated replacement key cannot decrypt content encrypted for the old key.

Manual key deletion requires removing the key from its folder configurations first. Automatic key lifecycle rules can remove a key even while a folder still references it. Processing that requires the removed or expired key then fails rather than delivering a file without the configured processing. Review key lifecycle rules, folder settings, and the recipient's key requirements together so scheduled cleanup does not interrupt a needed delivery.