Encryption & Keys
When a partner asks for “your key” while setting up a Files.com exchange, first clarify what the key will do. An SSH login key, a server host key, a PGP encryption key, and an AS2 certificate each serve a different purpose. Knowing that purpose tells you which system needs the key and where it belongs.
Start with the exchange itself: which system connects, which account it uses, and whether the key identifies a server, authenticates a client, or protects a file. A filename such as partner.pem or an algorithm name such as RSA tells you too little to make that decision.
SSH and PGP keys come in matched pairs: the owner uses the private key, while the other system uses the public key. A certificate contains a public key and identity information; its matching private key is separate.
Key Types and Destinations
A single exchange can use several keys, each configured for a particular job. Files.com already manages its default SFTP host identity and TLS certificates, which we recommend using. For keys you need to configure, the direction of the connection and the operation determine the destination:
| Exchange task | Required material | Files.com destination |
|---|---|---|
| A partner signs in to Files.com over SFTP | The partner client's public SSH login key | The intended user's SFTP Keys |
| Files.com signs in to the partner's SFTP server | The private SSH login key Files.com uses | The SFTP Remote Server's authentication settings or its saved credential |
| Files.com checks the identity of the partner's SFTP server | The server's public SSH host key | The Remote Server's Server Host Key setting |
| Files.com encrypts PGP files for the partner | The recipient's public OpenPGP key | The GPG Key Manager, then the appropriate encryption action or folder setting |
| Files.com decrypts PGP files addressed to you | Your matching public and private OpenPGP key pair, plus its passphrase if set | The GPG Key Manager, then the appropriate decryption action or folder setting |
| Files.com signs as your AS2 identity or decrypts its messages | Your public X.509 message certificate and matching private key | Your AS2 Identity |
| Files.com encrypts messages for an AS2 partner or verifies their signatures | The partner's public X.509 message certificate | The AS2 Trading Partner entry |
| Files.com presents a customer-provided TLS certificate | Your TLS/SSL certificate, matching private key, and intermediate certificates | The Custom Domain's SSL Certificate settings |
| An application connects through the API or S3-compatible endpoint | A service-issued API key, or S3 Access Key ID and Secret Access Key | Create it through API Keys, then configure the authorized client |
An API key is a secret credential rather than a public/private key pair. Keep it with the authorized application; it has no public portion to send as onboarding information.
An SSH login key and an SSH host key can have the same file format, but they identify different participants. The login key belongs with the account that the client uses; the host key belongs in the configuration for checking the server's identity. Putting either key in the other's setting leaves the intended login or trust relationship unconfigured.
Likewise, an SSH key cannot serve as a PGP key or an AS2 certificate. Converting a file from one encoding to another preserves its purpose. Key Files & Formats helps identify the material you have and the format the destination accepts.
Key Generation and Ownership
For a public/private pair, have the organization that will use the private key generate the pair, either in its own tools or in the service doing that work. Share the public portion with the other business; keep the private portion with the authorized client, server, or processing service. Choosing an SSH key algorithm explains which type to generate for an SFTP login.
- For SFTP login, the client operator owns the pair. If the partner connects to Files.com, the partner supplies its public key and keeps the private key in its transfer client. For a client you operate, use Files.com's SSH key-generation tools, save the private key during generation, and install it in that client. If Files.com connects to a partner, generate the pair in the SFTP Remote Server configuration and give its public key to the partner.
- For PGP encryption, the recipient generates the pair. To receive files that Files.com decrypts, generate your pair in the GPG Key Manager and give your public key to the sender. To send encrypted files, ask the recipient for their public key. For signatures, the signer owns the private key and gives verifiers its public key.
- For an SFTP server identity, the server operator manages the host key. Files.com already provides one for your endpoint. A custom host key is an explicit choice, such as retaining an existing service identity during migration; its private key belongs in that server configuration.
- For AS2, each business generates its own message certificate and private key. Use generation in the AS2 identity form for your Files.com identity, then exchange public certificates. Each side retains its own private key.
- For TLS, let Files.com manage the certificate and key by default. When supplying your own certificate, your certificate-management process generates the key and certificate signing request (CSR), or uses Files.com's CSR tool. The issuer receives the CSR and returns a public certificate; it does not need your private key.
Providing a private key to Files.com for a specific operation is different from sharing it with a trading partner. Files.com needs the private key when it acts as your SFTP client, decrypts your PGP files, or signs as your AS2 identity. Put it only in that feature's supported configuration, with the matching public material and passphrase where required.
One Exchange, Several Keys
Suppose a supplier uploads PGP-encrypted invoices to Files.com over SFTP. As it connects, the supplier's client checks the host identity managed by Files.com. It then signs in using the supplier's private SSH login key, whose public counterpart is registered on the supplier user account in Files.com.
The invoices use a separate key relationship. Your business owns the PGP recipient pair and gives the supplier its public key for encryption. Files.com decrypts the delivered invoices using your private key from the GPG Key Manager. The supplier's SSH private key stays in its transfer client, while your PGP private key stays with the service that decrypts your files.
Import Checks
Before saving a key, check its purpose, owner, and destination together:
- Identify the protocol and operation, including which business's system performs it.
- Confirm whether the receiving setting needs a public key, a public certificate, or private material. Inspect the file contents, including every block in a multi-block file.
- Confirm the intended account, endpoint, AS2 identity, or file recipient. Register the supplier's public login key on the supplier account, whose folder permissions define its access.
- Compare the public-key or certificate fingerprint with the expected value through the established partner relationship, then test the actual login or file-processing operation.
If the partner sends “a key” without identifying its purpose, ask whether it is for their client login, their server identity, file encryption, or AS2 messages. Settle that question before converting the file or trying it in different settings.
Symmetric and Asymmetric Encryption
A partner asking for an RSA key and AES-256 encryption is describing two parts of the same exchange. The key pair and the encryption algorithm do different work, and the software combines them to protect the transfer.
Symmetric encryption uses the same secret key to encrypt and decrypt data. Algorithms such as AES process large amounts of data efficiently; AES-256 uses a 256-bit secret key. Asymmetric cryptography uses a public/private pair for identity checks, signatures, or protecting a shared secret, according to the algorithm. A key pair lets two businesses work together without sharing their private keys.
Encrypted transfers combine the two:
| Exchange | What the key pair does | What encrypts the contents |
|---|---|---|
| SFTP over SSH | The host key identifies the server; an optional client login key authenticates the account. A separate key exchange derives the connection's shared secrets. | A negotiated symmetric cipher protects the traffic. |
| HTTPS or FTPS over TLS | The certificate and matching private key authenticate the server as part of the handshake. | Symmetric traffic keys derived during the handshake protect the connection. |
| Public-key-encrypted PGP files or AS2 messages | The recipient's public key protects a newly generated message key; its private key lets the recipient recover that key. Signing uses the sender's separate key relationship. | Symmetric encryption protects the file or message contents. |
The software creates the temporary connection or message keys as part of the exchange. You configure the identity keys and certificates that the two businesses need to trust. The SSH login key and the connection's cipher are separate choices; an AES session key has no place in an SFTP login field. Authentication & Negotiation explains how the two systems agree on compatible choices.
Three Encryption Layers
Encryption can protect data as it travels, while it is stored, or within a file that remains encrypted after delivery. SFTP and HTTPS protect their connections. Files.com separately manages encryption for its Native Storage, including the storage keys; those keys are not part of partner connection setup.
PGP file encryption and AS2 message encryption protect the payload separately from its transport, so reading it requires the recipient's private key. Files.com needs that private key when it decrypts files for processing. When only the partner is meant to decrypt a delivery, Files.com can encrypt it with the partner's public key and send it without holding their private key.
Protection Proportional to the Data
For most routine B2B exchanges, we recommend the strong encryption already provided by Files.com's native connections, HTTPS API, or SFTP, together with appropriate authentication and permissions. Additional encryption needs a concrete purpose, such as keeping a delivered file readable only by a designated recipient. More layers and more certificates create work to configure, renew, and troubleshoot; their value depends on the protection your business actually needs.
The consequences of disclosure differ between a routine order for nonsensitive manufactured parts and confidential, time-critical trading records. The latter can warrant much stricter control over who can decrypt each copy and when. Protection should reflect the contents, how long they remain sensitive, and any applicable obligations, rather than the fact that both files happen to move between businesses.
Dependable delivery matters too. For routine order or invoice data, a recurring job interrupted by unnecessary certificate coordination can be a more immediate business concern than the extra encryption layer's benefit. Our AS2 recommendation applies that judgment to a protocol with substantial message-protection and receipt coordination.