z-kovacs commented on code in PR #20542:
URL: https://github.com/apache/pulsar/pull/20542#discussion_r1228445478
##########
pulsar-client-messagecrypto-bc/src/main/java/org/apache/pulsar/client/impl/crypto/MessageCryptoBc.java:
##########
@@ -106,28 +80,64 @@ public class MessageCryptoBc implements
MessageCrypto<MessageMetadata, MessageMe
private static final SecureRandom secureRandom;
+
+ private static final String providerName;
+ private static BcVersionSpecificCryptoUtility
bcVersionSpecificCryptoUtilityDelegate;
+
static {
- SecureRandom rand = null;
- try {
- rand = SecureRandom.getInstance("NativePRNGNonBlocking");
- } catch (NoSuchAlgorithmException nsa) {
- rand = new SecureRandom();
- }
- secureRandom = rand;
+ providerName = SecurityUtility.getProvider().getName();
+
+ switch (providerName) {
+ case SecurityUtility.BC:
+ SecureRandom rand = null;
+ try {
+ rand = SecureRandom.getInstance("NativePRNGNonBlocking",
providerName);
+ } catch (NoSuchAlgorithmException | NoSuchProviderException
nsa) {
+ rand = new SecureRandom();
+ }
+ secureRandom = rand;
+ break;
+ case SecurityUtility.BC_FIPS:
+ try {
+ secureRandom = SecureRandom.getInstance("NONCEANDIV",
providerName);
+ } catch (NoSuchAlgorithmException | NoSuchProviderException
nsa) {
+ throw new RuntimeException(
+ "In BC FIPS mode, we expect the specific Random
generators to be available!");
+ }
+ break;
Review Comment:
Could you please elaborate on >if "NONCEANDIV" does not work<?
https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf
section 13 explicitly mentions these 2 securerandom generators in BC FIPS.
DEFAULT is the prediction resistant one - so the safest (I think to generate
AES keys), and NONCEANDIV is for nonce and IV generation, exactly what we use
that random generator when sending messages. But the original implementation
was using the on-blocking pseudorandom for both AES key gen and IV generation.
Overall DEFAULT seems to be the stronger one - so depending more on a good
entropy source, so DEFAULT may be more prone to blocking if there is not enough
entropy.
Maybe what you mean that >if the user cannot give access to a good entropy
source, and DEFAULT securerandom is blocking?< - that is definitely worth
drilling into and perhaps document that how the default is configured in BC
FIPS and what are the assumptions.
Thanks for the deep review!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
