Security
Private today. Private after quantum computers, too.
Security in BlazeSCP isn't a setting to find. It's how every connection is made, and the app tells you exactly what you got.
Why post-quantum, and why now
SSH sessions are protected by keys that client and server agree on at the start. With classical key exchange (Diffie-Hellman, X25519), a large enough quantum computer could work out those keys from a recording of the handshake, and decrypt everything sent in that session.
Nobody has that computer yet. But traffic recorded today can be stored until someone does. For files that need to stay confidential for years (contracts, source code, medical or financial records), the time to protect them is before they're sent.
What BlazeSCP does
For SFTP, BlazeSCP offers hybrid post-quantum key exchange first: a post-quantum algorithm combined with X25519. The session key depends on both, so it's at least as strong as classical SSH even if the newer algorithm were ever broken.
mlkem768x25519-sha256: ML-KEM-768 (FIPS 203) with X25519. Default in OpenSSH 9.9 and later.sntrup761x25519-sha512@openssh.com: Streamlined NTRU Prime with X25519. Default in OpenSSH 9.0 to 9.8, supported since 8.5.
If the server supports neither, the same handshake falls back to classical curve25519 (or ECDH and Diffie-Hellman for older servers). Connections never fail because of it.
You always know
Quantum-safe connections carry a PQC tag in the sidebar and a shield in the pane, with the exact algorithm on hover. A classical connection is shown as such, with a note that a newer OpenSSH on the server adds post-quantum protection.
Check your server
On the server, list the key exchanges sshd offers:
sshd -T | grep -i kexalgorithms
If you see mlkem768x25519-sha256 or a sntrup761x25519 entry, BlazeSCP will use it.
What PQC covers, and what it doesn't
- Confidentiality of SFTP sessions against recorded-traffic attacks.
- Works with your existing server keys and SSH keys.
- –FTPS, WebDAVS and S3 use TLS, where post-quantum support depends on the server.
- –Host and user key signatures are still classical, as in OpenSSH. They matter at connection time, not for recorded traffic.
Every layer, not just the handshake
Host keys, verified
The first time you connect, BlazeSCP shows the server's key fingerprint and asks before trusting it. Your existing ~/.ssh/known_hosts is honoured. If a known server's key changes, the connection is refused with a clear warning, not a checkbox to click through.
Certificates, pinned
FTPS and WebDAV over HTTPS verify certificates against your system's trust store. Self-signed servers can be trusted explicitly by fingerprint, and that exact certificate is pinned from then on.
Credentials stay with you
Saved passwords and key passphrases live in the macOS Keychain, Windows Credential Manager or the Linux Secret Service. Quick Connect passwords are kept in memory only. The interface never receives a stored secret back.
Two-factor sign-in
When a server asks for a one-time code or other answer, BlazeSCP shows the question as the server words it. Answers go only to that server and are never stored.
Signed updates
Every update is signed with our release key and verified before it's installed. Nothing installs in the background: you choose when.
No telemetry
No analytics, no crash reporting to us, no account. Apart from the update check (which you can turn off), BlazeSCP only connects to the servers you open.
Found a vulnerability?
Please tell us privately first. We'll confirm receipt, keep you updated and credit you if you'd like.