refactor: Use strong libcrypto randomness instead of custom random#5726
Merged
kaukabrizvi merged 23 commits intoaws:mainfrom Feb 25, 2026
Merged
refactor: Use strong libcrypto randomness instead of custom random#5726kaukabrizvi merged 23 commits intoaws:mainfrom
kaukabrizvi merged 23 commits intoaws:mainfrom
Conversation
maddeleine
reviewed
Feb 17, 2026
CarolYeh910
reviewed
Feb 19, 2026
maddeleine
reviewed
Feb 19, 2026
maddeleine
reviewed
Feb 19, 2026
6b3f106 to
65239a0
Compare
Contributor
Author
|
@maddeleine @CarolYeh910 thank you for the feedback. After reviewing this more closely, I determined that the chunking logic is unnecessary because libcrypto already handles large request sizes internally. I’ve removed that logic. With chunking removed, we’re also no longer passing RAND_*bytes through a generic function pointer, so the adapter logic is no longer needed either. |
maddeleine
reviewed
Feb 24, 2026
CarolYeh910
approved these changes
Feb 24, 2026
maddeleine
approved these changes
Feb 25, 2026
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
3 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.
Goal
This change brings us one step closer to deprecating s2n's custom DRBG by sourcing entropy from strong backend libcrypto's randomness implementation when available.
Why
Over the years, maintaining our own custom DBRG implementation has led to several issues, most of which relate to portability concerns. See #4348 and docs/design/DRBG.md in this PR for more.
How
We currently gate libcrypto backend delegation for randomness based on wether or not s2n is built in FIPS mode. This PR refactors the logic to delegate randomness based on libcrypto feature detection.
With these changes, we delegate randomness to the libcrypto if it supports a seperate public/private module for randomness. This is required to uphold our security guarantee that public entropy which is visible on the wire cannot be used to leak information about the private entropy.
As part of this PR, I modified tests which previously exercised the "backend randomness in use" path by observing FIPS mode to now gate based on the
random_uses_libcryptoindicator instead. I also added fixes to typos in two randomness tests as part of this PR which I noticed when looking over the files.Callouts
This PR does not completely remove the DRBG module in s2n-tls because there are still two libcrypto cases that do not meet our standard: OpenSSL 1.0.2 and versions of AWS-LC prior to aws/aws-lc#2963 do not support public/private random. These cases will be handled in a follow-up PR alongside full deprecation of the DRBG module.
Testing
Since this PR re-factors existing randomness branching, I updated tests that relied on previous assertions as to when the backend libcrypto randomness was being utilized.
#4348
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.