Expose peer signature algorithm and ML-DSA constants#511
Open
johnhurt wants to merge 1 commit into
Open
Conversation
Add Rust bindings for identifying the signature algorithm used by a TLS
peer, including the post-quantum ML-DSA family.
Adds to SslSignatureAlgorithm:
- ML_DSA_44 / ML_DSA_65 / ML_DSA_87 constants
- name() - wraps SSL_get_signature_algorithm_name
- Display - formats as the algorithm name or 'unknown (0xNNNN)'
Adds to SslRef:
- peer_signature_algorithm() - wraps SSL_get_peer_signature_algorithm,
returning None when BoringSSL reports the zero sentinel (pre-handshake,
session resumption, or protocol errors).
Co-authored-by: Luke Valenta <lvalenta@cloudflare.com>
lukevalenta
reviewed
Jun 2, 2026
| // `include_curve = true` returns the TLS 1.3 form for ECDSA algorithms | ||
| // (e.g. `ecdsa_secp256r1_sha256` rather than the TLS 1.2 `ecdsa_sha256`), | ||
| // matching what BoringSSL keylogs and modern TLS tooling use. | ||
| let ptr = ffi::SSL_get_signature_algorithm_name(self.0, true as c_int); |
Contributor
There was a problem hiding this comment.
To match surrounding style in the codebase:
Suggested change
| let ptr = ffi::SSL_get_signature_algorithm_name(self.0, true as c_int); | |
| let ptr = ffi::SSL_get_signature_algorithm_name(self.0, 1); |
| } else { | ||
| // SAFETY: BoringSSL returns a pointer to a static, NUL-terminated C string | ||
| // when non-null, and the documented contract guarantees valid UTF-8. | ||
| Some(str::from_utf8_unchecked(CStr::from_ptr(ptr).to_bytes())) |
Contributor
There was a problem hiding this comment.
To match surrounding style in the codebase (https://github.com/cloudflare/boring/blob/master/boring/src/ssl/error.rs#L89, https://github.com/cloudflare/boring/blob/master/boring/src/error.rs#L264), and then we can drop the SAFETY comment.
Suggested change
| Some(str::from_utf8_unchecked(CStr::from_ptr(ptr).to_bytes())) | |
| CStr::from_ptr(ptr).to_str().ok() |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add Rust bindings for identifying the signature algorithm used by a TLS peer, including the post-quantum ML-DSA family added in the recent BoringSSL bump.
Changes
SslSignatureAlgorithmML_DSA_44/ML_DSA_65/ML_DSA_87— constants for the ML-DSA (FIPS 204) signature schemes (SSL_SIGN_ML_DSA_44, etc.)name()— wrapsSSL_get_signature_algorithm_name, returning a human-readable name like"ecdsa_secp256r1_sha256"or"mldsa65". Usesinclude_curve=truefor TLS 1.3-style names.Display— formats as the algorithm name, or"unknown (0xNNNN)"for unrecognized codepoints.SslRefpeer_signature_algorithm()— wrapsSSL_get_peer_signature_algorithm, returning the signature scheme the peer used to authenticate the most recent handshake. ReturnsNonewhen BoringSSL reports the zero sentinel (pre-handshake, session resumption, or protocol errors).These bindings enable callers to identify post-quantum signature algorithms negotiated during TLS handshakes, which is needed for ML-DSA deployment monitoring and compliance.
Co-authored-by: Luke Valenta lvalenta@cloudflare.com