Skip to content

Data At Rest Encryption (DARE)

SFTPGo supports transparent data-at-rest encryption via its cryptfs virtual filesystem. When enabled, files are automatically encrypted during upload and decrypted during download — the files stored on disk are always encrypted while clients see and work with the unencrypted content.

Data At Rest Encryption is available for the local filesystem backend. For cloud storage backends (S3, GCS, Azure Blob), use their native server-side encryption features.

How it works

SFTPGo uses AES-256-GCM or ChaCha20-Poly1305 for authenticated encryption (AES-GCM is selected automatically when the CPU has hardware support). Each file is encrypted with a unique, randomly generated key derived from the configured passphrase. The per-file key is never stored — it is derived on the fly from the passphrase and a random initialization vector using HKDF (RFC 5869). The initialization vector is stored alongside the encrypted file.

The file size visible to clients (via SFTP, FTP, etc.) is the decrypted size, automatically computed by SFTPGo. The actual on-disk size is slightly larger due to encryption overhead.

Configuration

Parameter Description
Passphrase The master passphrase used to derive per-file encryption keys. Required. It must be high-entropy random key material, not a memorable password — see Passphrase strength. Stored encrypted according to your KMS configuration. If this passphrase is lost, all encrypted files become unrecoverable.
Read buffer size Buffer size in MB for read (decryption) operations. 0 means no buffering. Increasing this value may improve read performance for large files.
Write buffer size Buffer size in MB for write (encryption) operations. 0 means no buffering. Increasing this value may improve write performance for large files.

⚠ When setting up an encrypted filesystem for a user, the home directory must point to an empty directory. If it contains existing unencrypted files, SFTPGo will attempt to decrypt them and fail.

Passphrase strength

The passphrase is key material, not a memorable password. The confidentiality of the encrypted data is bounded by its entropy: an attacker who obtains the encrypted files (for example a leaked disk or backup) can brute-force a weak passphrase offline, with no rate limiting. Choose it the way you would choose an encryption key, not a login password.

SFTPGo enforces a minimum entropy through the common.secret_min_entropy setting (default 80). The check runs when the passphrase is set or changed in plain text; passphrases that are already stored are not re-validated, so raising the threshold does not break existing users. The same gate applies to the S3 SSE-C key.

This threshold is a heuristic estimate (character-set and length based) meant to reject weak secrets such as dictionary words or short strings. It is not a measure of cryptographic strength: the estimator over-scores human-structured input, so a high number does not by itself guarantee a strong key. The robust control is to supply key material generated by a CSPRNG (see below), which scores far above any reasonable threshold and is genuinely strong. The setting accepts any value — raise it to push harder toward random key material, set it to 0 to disable the check — but it does not replace using random bytes.

Generate the value with a cryptographically secure random generator, for example:

  • Linux / macOS: head -c 32 /dev/urandom | base64 or openssl rand -base64 32
  • Windows (PowerShell): [Convert]::ToBase64String([System.Security.Cryptography.RandomNumberGenerator]::GetBytes(32))

⚠ Store the passphrase in a safe place and keep a backup. It cannot be recovered: if it is lost, every file encrypted with it is permanently unreadable. To attach a new user to a folder that already contains data encrypted with a legacy weak passphrase, lower or set common.secret_min_entropy to 0 and plan a re-encryption (download with the old passphrase, upload to an account configured with a strong one).

Limitations

  • Upload resume is not supported — encryption is sequential and stream-based; random-access writes are not possible.
  • Truncate is not supported.
  • Opening a file for both reading and writing at the same time is not supported — clients that require advanced filesystem-like features (e.g., sshfs) are not supported.