Encryption Algorithms
TLDR - Quick Summary
What: Configure allowed SFTP encryption algorithms via web UI (v3.5.0+)
Location: Settings page > Encryption Algorithms section
Categories: HMACs, Public Keys, SSH2 Ciphers, Key Exchanges
Default: PARANOID + STRONG algorithms enabled; toggle to Editing mode to customize
Recommendations:
- Maximum Security: Ed25519 + Curve25519 + AEAD ciphers + ETM HMACs only
- Balanced (most users): Modern algorithms preferred with compatibility fallbacks
- Always disable: SHA-1 algorithms, 3DES, DSA/DSS
Overview
In SFTP Gateway version 3.5.0, we added a section under the Settings page for configuring SFTP encryption algorithms.
Under the Encryption Algorithms section, you can specify exactly which HMACs, Public Keys, SSH2 Ciphers and Key Exchange algorithms that the server supports.
By default, only the PARANOID and STRONG algorithms will be allowed. Clicking Reset to Default will reset to the default configuration as seen in the image above.
In order to make edits, change the mode from Viewing to Editing. Any changes made are saved automatically.
Understanding Encryption Algorithms
SFTP (SSH File Transfer Protocol) uses multiple layers of cryptography to secure your connections. Before diving into specific settings, let's understand what each category does.
What Are SSH2 Ciphers?
Ciphers (also called encryption algorithms) protect the confidentiality of your data. They scramble the actual file contents and commands so that anyone intercepting the traffic sees only random noise.
Think of a cipher as a lockbox: it takes your plaintext data, combines it with a secret key, and produces ciphertext that can only be unlocked with the same key.
Key concepts:
- AES (Advanced Encryption Standard): The most widely used cipher today. AES-128 and AES-256 refer to the key size in bits—larger keys provide more security margin.
- ChaCha20: A modern alternative to AES, designed by cryptographer Daniel Bernstein. Particularly fast on devices without hardware AES acceleration.
- Block cipher modes:
- GCM (Galois/Counter Mode): Provides both encryption AND integrity verification in one operation (called AEAD—Authenticated Encryption with Associated Data). This is the modern best practice.
- CTR (Counter Mode): Encryption only. Requires a separate MAC for integrity verification.
- 3DES (Triple DES): A legacy cipher from the 1990s. Its 64-bit block size makes it vulnerable to birthday attacks. Deprecated by NIST in 2023.
What Are HMACs?
HMAC stands for Hash-based Message Authentication Code. While ciphers protect confidentiality (keeping data secret), MACs protect integrity (detecting if data was modified).
When you send a message, the MAC algorithm creates a short "fingerprint" of the content. The recipient recalculates this fingerprint and compares them—if they don't match, the message was tampered with.
Key concepts:
- SHA-2 family (SHA-256, SHA-512): Modern, secure hash functions. No known practical attacks.
- SHA-1: An older hash function with known collision vulnerabilities. Deprecated by NIST and most compliance frameworks.
- ETM (Encrypt-then-MAC): The order of operations matters. ETM variants (indicated by
-etm@openssh.com) apply the MAC after encryption, which is cryptographically superior. Standard SSH applies MAC and encryption together, which can leak information in certain attacks. - Truncated variants (-96): Some MACs are truncated to 96 bits for efficiency. This reduces the security margin unnecessarily—avoid these when full-length versions are available.
What Are Key Exchanges?
Before two parties can communicate securely, they need to agree on a shared secret key—but they can't just send it over the network (an attacker could intercept it). Key exchange algorithms solve this problem mathematically.
Key concepts:
- Diffie-Hellman (DH): The classic key exchange algorithm from 1976. Both parties contribute random values and mathematically combine them to produce a shared secret that an eavesdropper cannot calculate.
- ECDH (Elliptic Curve Diffie-Hellman): A more efficient version using elliptic curve math. Achieves the same security with smaller key sizes.
- Curve25519: A modern elliptic curve designed for security and performance. Widely recommended.
- NIST curves (P-256, P-384, P-521): Government-standardized curves. Secure in practice, but some cryptographers prefer Curve25519 due to concerns about the NIST curve generation process.
- DH group sizes: Larger groups (measured in bits) provide more security but are slower. NIST recommends 3072-bit minimum for new deployments.
What Are Public Key Algorithms?
Public key algorithms handle authentication—proving you are who you claim to be. In SFTP, this is how the server verifies client identity (and vice versa).
Each user has a key pair: a private key (kept secret) and a public key (shared freely). You can sign a message with your private key, and anyone with your public key can verify the signature came from you.
Key concepts:
- Ed25519: A modern signature algorithm based on Curve25519. Fast, secure, and resistant to implementation errors.
- ECDSA: Elliptic Curve Digital Signature Algorithm using NIST curves. Secure, but requires careful implementation to avoid nonce-reuse vulnerabilities.
- RSA: The classic public key algorithm. Still secure with modern SHA-2 signatures and large keys (3072+ bits), but slower than elliptic curve alternatives.
- DSA/DSS: An older algorithm limited to 1024-bit keys in SSH. Considered broken by modern standards.
- Certificate variants (-cert-v01): These support SSH certificates for centralized key management rather than individual public keys.
Algorithm Reference
HMACs
HMAC implementation is provided by Bouncy Castle.
| Algorithm | Tier | Security | Notes |
|---|---|---|---|
hmac-sha2-512-etm@openssh.com | PARANOID | Excellent | Recommended. ETM mode with SHA-512. |
hmac-sha2-512 | PARANOID | Good | SHA-512, standard mode. |
hmac-sha2-512-96 | PARANOID | Acceptable | Truncated output reduces security margin. |
hmac-sha2-256-etm@openssh.com | STRONG | Excellent | Recommended. ETM mode with SHA-256. |
hmac-sha2-256 | STRONG | Good | SHA-256, standard mode. |
hmac-sha2-256-96 | STRONG | Acceptable | Truncated output reduces security margin. |
hmac-sha1-etm@openssh.com | WEAK | Poor | SHA-1 is deprecated. |
hmac-sha1 | WEAK | Poor | SHA-1 is deprecated. |
hmac-sha1-96 | WEAK | Poor | SHA-1 deprecated + truncated. |
Public Keys
| Algorithm | Tier | Security | Notes |
|---|---|---|---|
ssh-ed25519 | PARANOID | Excellent | Recommended. Modern, fast, secure. |
ssh-ed25519-cert-v01@openssh.com | PARANOID | Excellent | Certificate variant of Ed25519. |
ssh-ed448 | PARANOID | Excellent | Larger curve, conservative security margin. |
ecdsa-sha2-nistp256 | STRONG | Good | NIST P-256 curve. |
ecdsa-sha2-nistp256-cert-v01@openssh.com | STRONG | Good | Certificate variant. |
ecdsa-sha2-nistp384 | STRONG | Good | NIST P-384 curve. |
ecdsa-sha2-nistp384-cert-v01@openssh.com | STRONG | Good | Certificate variant. |
ecdsa-sha2-nistp521 | STRONG | Good | NIST P-521 curve. |
ecdsa-sha2-nistp521-cert-v01@openssh.com | STRONG | Good | Certificate variant. |
rsa-sha2-512 | STRONG | Good | RSA with SHA-512 signatures. Use 3072+ bit keys. |
rsa-sha2-256 | STRONG | Good | RSA with SHA-256 signatures. Use 3072+ bit keys. |
ssh-rsa | WEAK | Poor | Uses SHA-1 signatures. Vulnerable. |
ssh-rsa-cert-v01@openssh.com | WEAK | Poor | Certificate variant, still SHA-1. |
ssh-dss | WEAK | Broken | DSA limited to 1024-bit keys. Do not use. |
SSH2 Ciphers
| Algorithm | Tier | Security | Notes |
|---|---|---|---|
chacha20-poly1305@openssh.com | PARANOID | Excellent | Recommended. AEAD cipher, excellent performance. |
aes256-gcm@openssh.com | PARANOID | Excellent | Recommended. AEAD cipher, hardware-accelerated. |
aes128-gcm@openssh.com | PARANOID | Excellent | AEAD cipher, hardware-accelerated. |
aes256-ctr | STRONG | Good | Requires separate HMAC for integrity. |
aes192-ctr | STRONG | Good | Requires separate HMAC for integrity. |
aes128-ctr | STRONG | Good | Requires separate HMAC for integrity. |
3des-ctr | WEAK | Poor | 64-bit block size. Vulnerable to Sweet32 attack. Deprecated. |
Key Exchanges
| Algorithm | Tier | Security | Notes |
|---|---|---|---|
curve25519-sha256 | PARANOID | Excellent | Recommended. Modern ECDH. |
curve25519-sha256@libssh.org | PARANOID | Excellent | Same algorithm, older identifier. |
diffie-hellman-group18-sha512 | PARANOID | Excellent | 8192-bit DH. Very conservative. |
diffie-hellman-group17-sha512 | PARANOID | Excellent | 6144-bit DH. |
diffie-hellman-group16-sha512 | PARANOID | Excellent | 4096-bit DH. |
diffie-hellman-group15-sha512 | PARANOID | Good | 3072-bit DH. NIST minimum recommendation. |
ecdh-sha2-nistp521 | STRONG | Good | NIST P-521 curve. |
ecdh-sha2-nistp384 | STRONG | Good | NIST P-384 curve. |
ecdh-sha2-nistp256 | STRONG | Good | NIST P-256 curve. |
diffie-hellman-group-exchange-sha256 | STRONG | Good | Custom DH parameters. |
diffie-hellman-group14-sha256 | STRONG | Acceptable | 2048-bit DH. Minimum threshold. |
rsa2048-sha256 | STRONG | Acceptable | RSA key exchange. Uncommon. |
diffie-hellman-group14-sha1 | WEAK | Poor | Uses SHA-1. Avoid. |
Configuration Recommendations
Choosing the right algorithm configuration isn't just about picking "the most secure" options—it's about finding the right balance for your environment. A configuration that's perfect for a defense contractor handling classified data would be overkill (and potentially problematic) for a small business exchanging invoices with vendors running decade-old SFTP clients.
The profiles below represent battle-tested starting points. Each one makes deliberate trade-offs between security, performance, and compatibility. Read through the scenarios to find the closest match to your situation, then adjust based on your specific client requirements and compliance obligations.
How to use these profiles:
- Identify which scenario best matches your environment
- Start with that profile's recommended algorithms
- Test connectivity with your actual clients before deploying to production
- Document any deviations and the business justification for them
Maximum Security
This profile represents the current state-of-the-art in SSH cryptography. Every algorithm here has been designed with modern security principles, rigorously audited, and deployed at scale by security-conscious organizations worldwide.
Use when: Security is the absolute priority. You control both client and server environments, or you can mandate client upgrades. Common in government, defense, financial, and healthcare environments handling sensitive data.
Trade-offs: Some older clients (pre-2015) may not connect. Slightly higher CPU usage for key exchange due to larger DH groups.
| Category | Enable These Only |
|---|---|
| HMACs | hmac-sha2-512-etm@openssh.com, hmac-sha2-256-etm@openssh.com |
| Public Keys | ssh-ed25519, ssh-ed25519-cert-v01@openssh.com |
| Ciphers | chacha20-poly1305@openssh.com, aes256-gcm@openssh.com |
| Key Exchange | curve25519-sha256, curve25519-sha256@libssh.org |
Why these choices:
- ETM-only HMACs eliminate encrypt-and-MAC vulnerabilities
- Ed25519-only avoids RSA/ECDSA implementation risks and NIST curve concerns
- AEAD-only ciphers provide authenticated encryption
- Curve25519-only uses the most modern, audited key exchange
Before you deploy this profile: Test with every client that will connect to your server. The most common issue you'll encounter is older Java-based SFTP clients (particularly those built on JSch) that don't support Ed25519 or Curve25519. If a critical integration fails, consider the Balanced profile instead and document the security exception.
Maximum Performance
A common misconception is that "more security = slower performance." In reality, modern cryptographic algorithms are designed to be both secure and fast. The algorithms in this profile are no less secure than what you'd use in a high-security environment—they're simply optimized for throughput rather than maximizing every possible security margin.
Use when: Throughput and connection speed are critical. Large file transfers, high-volume batch processing, or resource-constrained environments. Security is still important but you're optimizing for speed.
Trade-offs: Slightly reduced security margin compared to maximum security profile, but still fully secure by modern standards.
| Category | Enable These Only |
|---|---|
| HMACs | hmac-sha2-256-etm@openssh.com, hmac-sha2-256 |
| Public Keys | ssh-ed25519, rsa-sha2-256 |
| Ciphers | aes128-gcm@openssh.com, chacha20-poly1305@openssh.com |
| Key Exchange | curve25519-sha256, curve25519-sha256@libssh.org |
Why these choices:
- SHA-256 HMACs are faster than SHA-512 with negligible security difference
- AES-128 is faster than AES-256; both remain unbroken
- Curve25519 is the fastest secure key exchange
- Ed25519 signatures are faster than RSA; RSA included for compatibility
Performance notes:
- On CPUs with AES-NI (most modern Intel/AMD),
aes128-gcmwill be fastest - On ARM devices or CPUs without AES-NI,
chacha20-poly1305is typically faster - Ed25519 key operations are ~10-30x faster than 3072-bit RSA
Tuning for your hardware: If you're unsure whether your server has AES-NI support, check with grep aes /proc/cpuinfo on Linux or look for "AES" in your CPU specifications. Most Intel processors since 2010 (Westmere) and AMD processors since 2013 (Bulldozer) include hardware AES acceleration. When AES-NI is available, AES-GCM ciphers will dramatically outperform ChaCha20—often by 3-5x for bulk data transfer.
Balanced (Recommended Default)
If you're unsure which profile to choose, start here. This configuration represents the sweet spot for most organizations: it maintains strong security while accommodating the diverse client landscape you'll encounter in production—everything from modern OpenSSH to enterprise Java applications to embedded devices running older SFTP libraries.
The key principle behind this profile is "secure by default, compatible where it matters." Modern algorithms are listed first (and will be preferred during negotiation), but fallback options ensure connections succeed even with clients that haven't been updated recently.
Use when: You need broad client compatibility while maintaining strong security. Suitable for most production deployments with diverse client environments.
Trade-offs: Includes some algorithms with minor theoretical concerns (NIST curves) that remain secure in practice.
| Category | Enable These |
|---|---|
| HMACs | hmac-sha2-512-etm@openssh.com, hmac-sha2-256-etm@openssh.com, hmac-sha2-512, hmac-sha2-256 |
| Public Keys | ssh-ed25519, ssh-ed25519-cert-v01@openssh.com, rsa-sha2-512, rsa-sha2-256, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 |
| Ciphers | chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com, aes256-ctr, aes128-ctr |
| Key Exchange | curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, diffie-hellman-group16-sha512 |
What to avoid: Even in balanced mode, never enable WEAK tier algorithms. The security risks they introduce outweigh the compatibility benefits. If a client truly requires a WEAK algorithm, use the Legacy Compatibility profile and document a migration plan.
Monitoring recommendation: Enable connection logging to track which algorithms clients actually negotiate. After a few weeks of data collection, you may discover that no clients are using certain fallback algorithms—at which point you can safely remove them and tighten your configuration.
Partner Integration: Financial Services Example
When connecting to major financial institutions, you'll often need to configure your algorithms to match their specific requirements. Unlike the general profiles above, partner integrations require you to work within someone else's constraints—you need algorithms that both sides support.
This section uses J.P. Morgan's Host-to-Host (H2H) SFTP service as a real-world example. Their published algorithm requirements demonstrate what you'll encounter when integrating with enterprise financial partners.
Why this matters: Financial institutions typically publish their supported algorithms, and connections will fail if you don't have at least one algorithm in common for each category. Before any integration, obtain your partner's algorithm documentation and configure accordingly.
J.P. Morgan Configuration
J.P. Morgan's requirements reflect a security-conscious financial institution that has moved away from legacy algorithms while maintaining broad compatibility. Notably, they support modern options like Curve25519 and Ed25519 alongside NIST curves—giving you flexibility in your configuration.
| Category | Enable These |
|---|---|
| HMACs | hmac-sha2-512, hmac-sha2-256 |
| Public Keys | ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, rsa-sha2-256, rsa-sha2-512 |
| Ciphers | aes256-gcm@openssh.com, aes128-gcm@openssh.com, aes256-ctr, aes128-ctr |
| Key Exchange | curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group18-sha512, diffie-hellman-group16-sha512, diffie-hellman-group14-sha256, diffie-hellman-group-exchange-sha256 |
What you can safely disable: J.P. Morgan does not support SHA-1 algorithms, 3DES, or DSA—which aligns with security best practices. You don't need to enable any WEAK tier algorithms for this integration.
Important timeline: J.P. Morgan has announced that CTR-mode ciphers (aes128-ctr, aes192-ctr, aes256-ctr) will be deprecated by Q1 2026. If you're setting up a new integration, prefer the GCM ciphers (aes256-gcm@openssh.com, aes128-gcm@openssh.com) as your primary options.
Legacy Compatibility
Sometimes you don't have a choice. That industrial control system from 2008 isn't getting a firmware update. Your partner's mainframe-based SFTP client only speaks algorithms that were deprecated years ago. The vendor went out of business and nobody has the source code.
This profile exists for exactly these situations—but it should make you uncomfortable. Every algorithm listed here has known weaknesses, and enabling them increases your attack surface. The goal isn't to stay on this profile permanently; it's to keep business operations running while you work toward a solution.
Use when: You must support older clients that cannot be upgraded (embedded systems, legacy applications, vendor constraints). Plan a migration path to remove these algorithms.
Trade-offs: Includes deprecated algorithms with known weaknesses. Use only when absolutely necessary and implement compensating controls (e.g. IP allowlisting).
| Category | Add These (in addition to Balanced) |
|---|---|
| HMACs | hmac-sha1-etm@openssh.com (if SHA-1 required) |
| Public Keys | ssh-rsa (if SHA-1 RSA required) |
| Ciphers | aes192-ctr (rarely needed) |
| Key Exchange | diffie-hellman-group14-sha256, diffie-hellman-group-exchange-sha256 |
Never enable, even for compatibility: ssh-dss, 3des-ctr, diffie-hellman-group14-sha1. These algorithms are so thoroughly broken that the security risk outweighs any compatibility benefit. If a client requires them, that client is a security liability that needs to be addressed at a higher level than SFTP configuration.
Creating a migration plan: Document every client that requires legacy algorithms, who owns that system, and what would be required to upgrade or replace it. Set a review date (quarterly is reasonable) to reassess whether the legacy requirement still exists. Many organizations discover that legacy systems they thought were immovable have actually been decommissioned or upgraded—they just forgot to update their SFTP configuration.
Compliance-Specific Configurations
Regulatory compliance adds another layer of constraints to your algorithm selection. Compliance frameworks often lag behind cryptographic best practices—you may find yourself unable to use the most modern, secure algorithms simply because they haven't been formally certified yet.
The guidance below reflects requirements as of 2024. Compliance frameworks evolve, and you should always verify current requirements with your compliance team or auditor. When in doubt, document your configuration decisions and the reasoning behind them.
FIPS 140-2/3 Compliance
FIPS (Federal Information Processing Standards) compliance is required for U.S. federal agencies and contractors handling sensitive government data. The key constraint: only NIST-approved algorithms are permitted.
This creates an interesting tension. ChaCha20-Poly1305 and Curve25519—arguably the most modern and well-designed algorithms available—are not FIPS-approved because they weren't developed through the NIST standardization process. You'll need to rely on AES and NIST elliptic curves instead.
| Category | FIPS-Compliant Options |
|---|---|
| HMACs | hmac-sha2-512, hmac-sha2-256 (non-ETM variants are FIPS-validated) |
| Public Keys | rsa-sha2-512, rsa-sha2-256, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521 |
| Ciphers | aes256-gcm@openssh.com, aes128-gcm@openssh.com, aes256-ctr, aes128-ctr |
| Key Exchange | ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group16-sha512, diffie-hellman-group15-sha512 |
Important: FIPS compliance isn't just about algorithm selection—it also requires using a FIPS-validated cryptographic module.
PCI-DSS Compliance
PCI-DSS (Payment Card Industry Data Security Standard) focuses on protecting cardholder data. From a cryptographic standpoint, the requirements are straightforward: disable deprecated algorithms, particularly SHA-1 and 3DES, which PCI explicitly calls out as inadequate.
Use the Balanced or Maximum Security profile—both satisfy PCI requirements out of the box. The key validation points for your PCI audit will be:
- No SHA-1 in use for authentication or integrity
- No 3DES (Sweet32 vulnerability)
- TLS/SSH protocols at current versions
FedRAMP / NIST 800-53
FedRAMP (Federal Risk and Authorization Management Program) builds on NIST 800-53 security controls and applies to cloud services used by federal agencies. The cryptographic requirements align with NIST SP 800-131A guidelines:
- Key sizes: 3072-bit minimum for RSA and DH groups, 256-bit minimum for elliptic curves
- Hash functions: SHA-2 family required; SHA-1 prohibited for digital signatures
- Deprecated algorithms: Must be disabled, not just "not preferred"
The Maximum Security or Balanced profile meets these requirements. Document your algorithm configuration as part of your System Security Plan (SSP).
Algorithms to Disable
Security isn't just about enabling the right algorithms—it's equally important to disable the wrong ones. An attacker doesn't need to break your strongest cipher if they can convince your server to negotiate a weaker one instead. This is why "defense in depth" means removing vulnerable options entirely, not just hoping clients won't choose them.
The algorithms below have known, practical vulnerabilities or have been formally deprecated by standards bodies. Disabling them is not optional hardening—it's baseline security hygiene.
Must Disable
These algorithms should be disabled in all production environments, regardless of compatibility concerns:
| Algorithm | Category | Why Disable |
|---|---|---|
hmac-sha1 | HMAC | SHA-1 deprecated (collision attacks demonstrated in 2017) |
hmac-sha1-96 | HMAC | SHA-1 deprecated + truncated output |
hmac-sha1-etm@openssh.com | HMAC | SHA-1 deprecated |
ssh-dss | Public Key | DSA limited to 1024-bit keys, trivially breakable |
ssh-rsa | Public Key | SHA-1 signatures, vulnerable to Terrapin attack (CVE-2023-48795) |
ssh-rsa-cert-v01@openssh.com | Public Key | SHA-1 signatures |
3des-ctr | Cipher | 64-bit block size, vulnerable to Sweet32 attack (CVE-2016-2183), deprecated by NIST |
diffie-hellman-group14-sha1 | Key Exchange | SHA-1, minimum DH group size |
What to do if a client requires these: Don't enable them. Instead, work with the client owner to upgrade their software, establish a dedicated legacy gateway with compensating controls, or accept the business risk of not supporting that client. The security implications of enabling these algorithms affect all connections, not just the legacy client.
Should Disable
These algorithms aren't broken, but they provide no benefit over better alternatives. Disabling them simplifies your configuration and reduces your attack surface:
| Algorithm | Category | Why Consider |
|---|---|---|
hmac-sha2-512-96 | HMAC | Truncated output provides no benefit over full variant |
hmac-sha2-256-96 | HMAC | Truncated output provides no benefit over full variant |
The truncated HMAC variants (-96) were designed for bandwidth-constrained environments that no longer exist in practice. They reduce the MAC from 256 or 512 bits to 96 bits—still secure against brute force, but why accept any reduction when the full-length versions are universally supported?
Known Vulnerabilities
Understanding why certain algorithms are deprecated helps you make informed decisions and explain those decisions to stakeholders. The vulnerabilities below represent real-world attacks that have shaped modern SSH security recommendations.
CVE-2023-48795 — Terrapin Attack
Discovered in late 2023, Terrapin was a wake-up call for the SSH community. It demonstrated that even well-designed algorithms could be vulnerable to protocol-level attacks that exploit the interaction between multiple cryptographic components.
- Severity: Medium (CVSS 5.9)
- Affects:
ssh-rsa,chacha20-poly1305@openssh.com, and CTR cipher + HMAC combinations - Impact: Prefix truncation attack allowing security-critical handshake messages to be stripped
- Mitigation: Apply patches implementing strict key exchange. The cipher itself isn't flawed—this is a protocol-level issue.
What this means for you: If you're running patched software (OpenSSH 9.6+, or equivalent patches backported to your distribution), the attack is mitigated regardless of which algorithms you enable. However, this vulnerability is a good reason to prefer AEAD ciphers (GCM modes) over CTR+HMAC combinations when possible—AEAD ciphers have simpler security properties that are less susceptible to protocol-level attacks.
CVE-2016-2183 — Sweet32 Birthday Attack
Sweet32 demonstrated a fundamental limitation of 64-bit block ciphers. Due to the birthday paradox, after encrypting about 32GB of data with the same key, collisions become likely enough that an attacker can recover plaintext.
- Severity: Medium (CVSS 5.3)
- Affects:
3des-ctrand all Triple DES variants - Impact: With ~32GB of captured traffic, an attacker can recover plaintext
- Mitigation: Disable all 3DES ciphers.
What this means for you: 32GB might sound like a lot, but it's a single large file transfer or a few hours of sustained traffic. The attack requires capturing encrypted traffic, which is feasible for nation-state adversaries or anyone with network access. 3DES has no place in a modern deployment.
SHA-1 Collision Attacks
The SHAttered attack in 2017 produced the first practical SHA-1 collision—two different documents with the same SHA-1 hash. While this doesn't directly break HMAC-SHA1 (which has different security properties), it definitively ended SHA-1's status as a trusted cryptographic hash function.
- Affects: All SHA-1 algorithms (
hmac-sha1*,ssh-rsa,diffie-hellman-group14-sha1) - Impact: Practical collision attacks demonstrated in 2017 (SHAttered)
- Mitigation: Use SHA-2 alternatives in all categories.
What this means for you: The writing has been on the wall for SHA-1 since 2005, when theoretical weaknesses were first published. Major browsers, certificate authorities, and standards bodies have all deprecated SHA-1. Any organization still relying on SHA-1 algorithms is using cryptography that the security community abandoned years ago. The migration path is clear: SHA-256 and SHA-512 are drop-in replacements available in all modern SSH implementations.