<div dir="ltr"><div><div>Hi Thomas,<br><br></div>Thanks for your response! It clears up matters a lot :)<br><br></div><div>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.<br></div><div>Does the mere usage of salt that was generated via a non-FIPS-recommended approach violate my compliance ?<br><br></div><div>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 :)<br></div><div><br></div><div>Thanks,<br></div><div>Pratyush.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. <span dir="ltr"><<a href="mailto:thomas.francis.jr@pobox.com" target="_blank">thomas.francis.jr@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 27, 2016, at 8:18 PM, pratyush parimal <<a href="mailto:pratyush.parimal@gmail.com">pratyush.parimal@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I work on a consumer application which is striving to be fips-140-2 compliant.<br>
><br>
> 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).<br>
><br>
> Does anyone know if using my custom random number generator in this way violates the app's fips compliance?<br>
<br>
</span>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?<br>
<br>
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. :)<br>
<br>
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.<br>
<span class=""><br>
> Am I really supposed to be using<br>
> RAND_bytes for compliance reasons?<br>
<br>
</span>Yes.<br>
<br>
> Thanks in advance!<br>
> Pratyush.<br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> openssl-users mailing list<br>
> To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</font></span></blockquote></div><br></div>