z-kovacs opened a new issue, #20373:
URL: https://github.com/apache/pulsar/issues/20373

   ### Search before asking
   
   - [X] I searched in the [issues](https://github.com/apache/pulsar/issues) 
and found nothing similar.
   
   
   ### Motivation
   
   my firm would like to use Pulsar but using Bouncycastle FIPS approved libs 
in approved mode for E2E encryption.
   
   Currently the `MessageCryptoBc` is the only `MessageCrypto` implementation 
(non FIPS), and it is explicitly referenced from `ProducerImpl` and 
`ConsumerImpl` - unless overridden.
   
   I think it would be greate if someone adds an encryption key and a 
CryptoKeyReader, based on the loaded modules pulsar would use the fips or 
non-fips implementation. As related job has been done in pulsar to separate out 
different version (non-fips or fips) of BouncyCastle dependencies, we could 
expand on it.
   
   ### Solution
   
   An idea about the tasks:
   1. Create a new MessageCrypto implementation using only bouncycastle FIPS 
provider and API calls and add it to a new 
`org.apache.pulsar:pulsar-client-messagecrypto-bcfips` module 
(`pulsar-client-messagecrypto-bc` already exists).
   2. ProducerImpl and ConsumerImpl should check which version (bc or bc-fips) 
of MessageCrypto can be found on the classpath and that should be used. 
Decision should be logged. Defaulting back to the origial non-fips solution for 
backward compatibility if both are on classpath.
   
   
   ### Alternatives
   
   n/a
   
   ### Anything else?
   
   Notes:
   - ECDSA keys cannot be used to wrap/encrypt keys - in BC's FIPS library only 
RSA or ELGAMAL cyphers can wrap keys 
(https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf, 
chapter 4)
   - in MessageCryptoBc data key encryption is using encrypt/decryp mode of 
cypher, but it should use wrap and unwrap (please confirm)
   - SecureRandom should be changed probably in the new MessageCryprto 
implementation: maybe using "NONCEANDIV" for IV generation (what is done for 
each message), and another "DEFAULT" type for AES data key generation (DEFAULT 
may exhaust entropy if used for Nonce and IV generation)
   
   ### Are you willing to submit a PR?
   
   - [X] I'm willing to submit a PR!


-- 
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]

Reply via email to