Post-Quantum Cryptography readiness: E2EE uses RSA-2048, SSE uses RSA-4096 — both quantum-vulnerable

[netanmangal]

Tip

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

---

Is your feature request related to a problem? Please describe.
France's ANSSI will stop certifying security products without post-quantum cryptography starting in 2027 - the first hard regulatory deadline of its kind globally. Additional mandates: US NSA CNSA 2.0 (2027), NIST IR 8547 (deprecation by 2030, disallowed by 2035), EU critical infrastructure (2030).

Summary

Nextcloud's encryption layers use quantum-vulnerable asymmetric cryptography:

Layer	Algorithm	Quantum Status
E2EE metadata key exchange	RSA-2048 OAEP	Broken by Shor's algorithm
E2EE file encryption	AES-128-GCM	Reduced to 64-bit security (borderline)
Server-Side Encryption key wrapping	RSA-4096	Broken by Shor's algorithm
Identity Proof keys	RSA-2048 / ECDSA P-256	Both broken by Shor's

An adversary performing "harvest now, decrypt later" on encrypted Nextcloud data
could recover all file encryption keys by breaking a single RSA key.

Why This Matters

• Nextcloud is used by the German federal administration (ITZBund)
• BSI TR-02102 recommends post-quantum migration
• BSI + 20 EU states issued "Securing Tomorrow, Today" (Nov 2024) urging PQC transition
• NIST IR 8547 deprecates classical asymmetric cryptography by 2030

Describe the solution you'd like

Priority 1: E2EE Key Encapsulation

Replace RSA-2048 OAEP with hybrid ML-KEM-768 + X25519 (FIPS 203) for
metadata-key exchange. This directly addresses the HNDL threat on encrypted files.

Priority 2: Symmetric Upgrade

Upgrade AES-128-GCM to AES-256-GCM for 128-bit post-quantum security.

Priority 3: SSE Key Wrapping

Replace RSA-4096 multiKeyEncrypt() with hybrid ML-KEM + classical key wrapping.

Priority 4: Identity Proof Keys

Replace RSA-2048/ECDSA P-256 with hybrid ML-DSA + classical signatures.

Priority 5: Cryptographic Agility

Add algorithm negotiation and version fields to the E2EE RFC to enable
future transitions without breaking backward compatibility.

Technical Feasibility

PHP 8.1+ can use PQC via:

• OpenSSL 3.5+ (ML-KEM and ML-DSA providers)
• paragonie/ext-pqcrypto (Rust extension, ML-KEM/ML-DSA)
• paragonie/pqcrypto_compat (pure PHP polyfill)

Describe alternatives you've considered
N/A

Additional context

References

• France ANSSI 2027 Mandate
• BSI TR-02102 Cryptographic Mechanisms
• NIST FIPS 203 (ML-KEM)
• Nextcloud E2EE RFC v2.1
• RFC Issue #65 (algorithm upgrade discussion)

[nickvergessen]

PHP 8.1+ can use PQC via:

• OpenSSL 3.5+ (ML-KEM and ML-DSA providers)
• paragonie/ext-pqcrypto (Rust extension, ML-KEM/ML-DSA)
• paragonie/pqcrypto_compat (pure PHP polyfill)

Instead of a library with 9 and 11 stars, we should simply continue to use phpseclib.

[netanmangal]

Great point @nickvergessen . We can use phpseclib.

The core issue remains the same regardless of library choice:

1. E2EE metadata key exchange uses RSA-2048 OAEP → needs ML-KEM hybrid
2. SSE key wrapping uses RSA-4096 → same
3. Identity Proof keys use RSA-2048/ECDSA P-256 → needs ML-DSA

I can look into what phpseclib currently supports for ML-KEM/ML-DSA and use that instead. Thanks for the heads up!