[openssl-users] Custom Random number generation while in Fips mode

[Thomas Francis, Jr.]

> On Jul 28, 2016, at 11:00 AM, pratyush parimal <pratyush.parimal at gmail.com> wrote:
> 
> Hi Thomas,
> 
> Thanks for your response! It clears up matters a lot :)
> 
> There's one thing that I thought of though -- even though I'm generating the salt via non-OpenSSL means, the actual function that I'm using for hashing is "SHA512" from FIPS OpenSSL.
> Does the mere usage of salt that was generated via a non-FIPS-recommended approach violate my compliance ?

You used what is typically considered a cryptographic function (some form of RNG) from a source other than your cryptographic module running in approved mode.  Unless you can fully justify that use as for non-cryptographic purposes, your product is not complying with FIPS 140.  Given that it’s a salt for hashing passwords, I think you’ll have a really hard time convincing customers and auditors that the salt generation is for non-cryptographic purposes.  After all, if that’s not cryptographic, why didn’t you use something more deterministic (like a counter, or a user name) for the salt?

> I understand what you mean by "I'm not an auditor or a lawyer" , but I'd still appreciate your opinion / experience in the matter :)

In my limited experience, auditors are not computer security experts.  They’re smart people, but they tend to fall back on very simple guidelines when it comes to things outside their own expertise (like what’s a cryptographic algorithm, and what’s a cryptographic purpose).  You might be able to get away with it, but I wouldn’t want to stake a sale on it.  Especially not if there are penalties attached for failing an audit.

TOM

> Thanks,
> Pratyush.
> 
> On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. <thomas.francis.jr at pobox.com> wrote:
> 
> > On Jul 27, 2016, at 8:18 PM, pratyush parimal <pratyush.parimal at gmail.com> wrote:
> >
> > Hi all,
> >
> > I work on a consumer application which is striving to be fips-140-2 compliant.
> >
> > I'm using OpenSSL as recommended in the fips guide by invoking fips_mode_set(). However, in certain parts of the same application, I'm using my own non-OpenSSL random number generator to generate salts for hashing passwords for the app user accounts(I'm not using RAND_bytes).
> >
> > Does anyone know if using my custom random number generator in this way violates the app's fips compliance?
> 
> That’s almost certainly a violation.  There might be a few edge cases where it is not, but they’re very unlikely.  To determine if you’re even close to such cases, ask: Does the RNG I’m using come from another FIPS 140 validated cryptographic module?  Am I using that module in approved mode?  Am I using that module according to its security policy?  Do I have explicit permission from the customers’ auditors to mix two modules in my product?
> 
> If the answer to all of those questions is yes, you _might_ be OK, for now.  A few auditors (in the past, anyway) considered it OK to mix modules, while other auditors say no.  My own reading of FIPS 140-2 is that you may not mix modules.  But I’m not an auditor or a lawyer. :)
> 
> The other question to ask is: can I clearly explain that the use of the non-approved RNG is for non-cryptographic purposes, and easily justify that explanation?  Given what you said about why you’re using it, I’m pretty sure the answer to that one is “no”. :)  And even if you could, that’s still a very weak argument to be making to your customers’ auditors, who may decide it’s still not allowed even if they agree it’s for non-cryptographic purposes.
> 
> > Am I really supposed to be using
> > RAND_bytes for compliance reasons?
> 
> Yes.
> 
> > Thanks in advance!
> > Pratyush.
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users