docs: Add a Http/Json Post-Quantum Cryptography Guide - #13963
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive Post-Quantum Cryptography (PQC) User Guide for HTTP/JSON Java Client Libraries. The guide details the quantum threat, library support, Conscrypt integration, platform compatibility, and custom configurations. The review feedback correctly identifies that NetHttpTransport.Builder lacks a setSecurityProvider method in the custom configuration example and provides a valid code suggestion to configure an SSLContext with the custom provider instead.
… steps and locally scoped security providers
…k flow, and format JDK 27 as addendum
…and custom provider builder examples
…JDK 27 addendum scope
… callout on user responsibility
- Frame PQC concepts with beginner-friendly explanations and the two-lock hybrid analogy. - Clarify transport scope: focus exclusively on HTTP/JSON transport and note gRPC coverage in a future PR. - Document handshake size overhead (~1-2KB) and negligible runtime API latency impact due to connection pooling. - Detail deployment compatibility matrix covering glibc Linux, Alpine/musl fallback, and hardened noexec /tmp filesystems. - Add prominent warning on silent fallback tradeoff between high availability and strict regulatory compliance. - Provide step-by-step verification instructions using GAX debug logs and JVM -Djavax.net.debug=ssl:handshake output. - Present modular, non-prescriptive configuration choices (default Conscrypt, classical-only X25519, pure JDK JSSE, dependency exclusion, and custom Bouncy Castle provider). - Add future outlook on OpenJDK native ML-KEM support in JDK 27+.
67661f5 to
4470661
Compare
- Add Wikipedia link to Shor's algorithm. - Remove conversational introductory phrasing in threat section. - Frame hybrid key exchange as an example rather than a standard. - Remove redundant audience phrasing and generalize endpoint references. - Remove gRPC transport scope section to keep guide focused on HTTP/JSON. - Add OpenJDK link to JEP 496. - Align default named groups list with DEFAULT_CONSCRYPT_NAMED_GROUPS in gax-httpjson. - Clarify fallback to configured security provider (defaulting to standard JDK JSSE). - Moderate latency assertions and encourage user benchmarking. - Remove unsubstantiated CPU benchmark assertions. - Neutralize Alpine Linux options and suggest alternative security providers like Bouncy Castle. - Clean up custom configuration options to only include actionable alternative setups.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive Post-Quantum Cryptography (PQC) user guide for HTTP/JSON Java client libraries. The feedback points out that the code examples in the custom configuration section use non-existent methods on NetHttpTransport.Builder (specifically setSslSocketConfigurator and setSecurityProvider). To resolve this, the examples should be updated to configure a custom SSLSocketFactory or SSLContext and apply it via setSslSocketFactory.
…ps, and fallback section
…arning example, and rename to Fallback Implications
| The cryptographic landscape is continually advancing. The OpenJDK community is integrating standardized post-quantum algorithms directly into the Java platform: | ||
| - **[JEP 496](https://openjdk.org/jeps/496) (ML-KEM)**: Introduces native implementations of NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism) into OpenJDK's standard security providers (`SunJSSE` and `SunJCE`), targeted for **JDK 27+**. | ||
| - **What this means for Google Cloud Java**: Once JDK 27 becomes standard in production environments, Java applications will be capable of negotiating hybrid and pure post-quantum TLS natively without requiring JNI shared libraries or third-party dependencies like Conscrypt. | ||
| - **Future-Proofing**: As native JDK capabilities mature, Google Cloud Java client libraries will adapt to take advantage of built-in JVM providers, preserving a seamless, zero-maintenance security upgrade path for all users. |
There was a problem hiding this comment.
| - **Future-Proofing**: As native JDK capabilities mature, Google Cloud Java client libraries will adapt to take advantage of built-in JVM providers, preserving a seamless, zero-maintenance security upgrade path for all users. |
I don't think we want to commit to this.
…e-proofing commitment
Part 1 of a stack to add pqc guide. This guide is first about Http/Json and a follow up will be with gRPC.