<div dir="ltr">Hi,<div><br></div><div>I'm afraid it's not possible to get away by modifying the C code only, but you can minimise the Erlang code changes easily.</div><div><br></div><div>This commit implements the basics of FIPS support and it's mostly about C code: <a href="https://github.com/esl/otp/commit/00b3a04d17a653b4abddeebd6dd8a2c38df532d0#diff-1315c36aca592e79ef0073fcf3019e5f">https://github.com/esl/otp/commit/00b3a04d17a653b4abddeebd6dd8a2c38df532d0#diff-1315c36aca592e79ef0073fcf3019e5f</a> The crypto.erl modifications are mostly for two reason: properly reporting the list of supported ciphers and tweaking a bit with error handling. The first is not too important to have (as I said, other parts of OTP do not respect this list), the second is mostly a cosmetic change: you can always cause a badarg exception in your NIFs which may be not very informative, but would crash the Erlang process calling the forbidden algorithm nevertheless. The only algorithm I had to ban in the Erlang code was SRP, as some parts of it were implemented in Erlang. But I think banning the C parts would be enough.</div><div><br></div><div>You will need to modify the Erlang code at the following places however:</div><div><ul><li>Replacing the hash in the PKIX DB (see parts of <a href="https://github.com/esl/otp/commit/675ee6860d2c273bcc6c6a0536634a107e2a3d9f#diff-98fe4d9262b05740af899ce038ac0c0d">https://github.com/esl/otp/commit/675ee6860d2c273bcc6c6a0536634a107e2a3d9f#diff-98fe4d9262b05740af899ce038ac0c0d</a> dealing with ssl_internal.h, ssl_manager.erl and ssl_pkix_db.erl)</li><li>Removing forbiden algorithms from the list of ciphers offered by SSL. You can do it without tweaking with the ssl application too, by changing the options passed to ssl from your client code when setting up a server socket/client connection.</li></ul><div>By the way, for quite some time now Erlang/OTP only uses libcrypto from OpenSSL. The ssl protocol is implemented in Erlang using the crypto primitives from libcrypto.</div></div><div><br></div><div>Hope it helps,</div><div>Daniel</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-01 15:03 GMT+02:00 jonetsu <span dir="ltr"><<a href="mailto:jonetsu@teksavvy.com" target="_blank">jonetsu@teksavvy.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">
<br><div></div>-----Original Message-----<br>From: "Dániel Szoboszlay" <<a href="mailto:dszoboszlay@gmail.com" target="_blank">dszoboszlay@gmail.com</a>><br>Date: 05/01/15 04:01<br><br>Hi,<br><br>Thanks for your comments, much appreciated !<br><br>> - Blocked non-compliant calls in FIPS mode before they would reach<br>>  OpenSSL (so you get an Erlang error instead of killing your<br>>  VM). This is a must have for any FIPS fork, but it was quite<br>>  trivial to implement.<br><br>That would be the CHECK_NO_FIPS_MODE in crypto.c.  Is there any at the<br>Erlang level ?<br><br>I'm asking beacause what I am considering at the moment is to only<br>modify the crypto.c code.  No modification to Erlang code. For two<br>reasons.  One is that I do not know Erlang, although by browsing the<br>code lately I find it quite interesting :) But nowhere near being able<br>to modify an application that is used in the field.  Let alone<br>establishing test harnesses in the first place. Second is, the OTP<br>that is used is already modified by tail-f AG as part of the ConfD<br>product.  For instance, if I'm not mistaken, the SSL component is<br>different, with crypto being the only part used from OpenSSL. I have<br>the impression that the OTP base used in the product dates from some<br>time.  It is possible to compile locally crypto.c, but when it comes<br>to altering the company's Erlang code then all support is lost.<br><br>This approach also means to keep the C <-> Erlang interface intact.<br><br>Do you think it is at all possible to have a working FIPS mode without<br>any modification to Erlang code ?<br><br>Regards.<br><br>
</div></div>

</blockquote></div><br></div>