<div><div dir="auto">Sure, that’s why I said it makes an effort. Most languages with threads (or even certain uses of signals) can have similar edge cases. Having the edge cases documented such that they can be avoided is likely the best you’re going to find anywhere.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 26, 2019 at 17:34 Amit K <<a href="mailto:klg.amit@gmail.com">klg.amit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you Bob,<div>Note though that the "gotcha" in the documentation that says: "...<font color="#000000" face="sans-serif">there can be strange situations in multi-threaded application where the memory is not wiped out..." is why I think ideally something like that should be built into the language and not provided as an external package, which at best will work only as long the run-time obeys certain rules which are bound to change over time, and at worst will work "most of the time" :) (as this is not acceptable in real security applications that need to go through security certifications). </font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2019 at 2:16 AM Bob Ippolito <<a href="mailto:bob@redivi.com" target="_blank">bob@redivi.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">With regard to other FP languages, Haskell has a crypto library called raaz that makes an effort to ensure that sensitive memory gets cleared eagerly. Other Haskell libraries might have similar functionality, it's a bit easier to do with GHC than with the Erlang VM for various reasons.</div><div dir="ltr"><br></div><div dir="ltr"><a href="http://hackage.haskell.org/package/raaz-0.2.1/docs/Raaz-Core-Types.html#v:allocaSecureAligned" target="_blank">http://hackage.haskell.org/package/raaz-0.2.1/docs/Raaz-Core-Types.html#v:allocaSecureAligned</a><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 26, 2019 at 4:02 PM Amit K <<a href="mailto:klg.amit@gmail.com" target="_blank">klg.amit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Daniel,<div><br></div><div>Good to know about that workaround, thank you. However as you already pointed out, I really do want to be able to handle such "sensitive" variables in Erlang code and use the standard "crypto" library of the OTP. </div><div><br></div><div>With regards to GC - that's a great direction I think, and perhaps a more finer grained approach would be to add a new "sensitive" flag for typed variables that the GC can recognize. Then only those variables get zeroized when the GC runs. </div><div>Would probably be better for performance than always zeroizing everything that we free...</div><div><br></div><div>BTW - so far I didn't find any FP language that can do something like that, and please correct me if I'm wrong. It would be cool if Erlang would be the first to the gold here (again!) :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2019 at 1:42 AM Dániel Szoboszlay <<a href="mailto:dszoboszlay@gmail.com" target="_blank">dszoboszlay@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Amit,<div><br></div><div>A NIF could use a resource object to implement a zeroable memory location. The Erlang program will only see a handle to the resource, which is immutable. But the contents of the object can be changed by the NIF (it's better explained in the <a href="http://erlang.org/doc/man/erl_nif.html" target="_blank">docs</a>). So you could create an API that looks like this for the Erlang program:</div><div><br></div><div><font face="monospace">Handle = create_secret(Some, Input, Values),</font></div><div><font face="monospace">ok = use_secret(Handle),</font></div><div><font face="monospace">ok = destroy_secret(Handle), % The NIF zeroes out the memory in the resource object</font></div><div><font face="monospace">{error, destroyed} = use_secret(Handle). % The secret is no more at this point</font></div><div><br></div><div>The big problem is that your secret shall never leave the native library. E.g. you cannot hide a cryptographic key behind a zeroable resource object and then pass it to the crypto library. As soon as you convert it into an Erlang term, it is copied onto the non-zeroed stack or heap or a process. Considering this, you may just as well use a port program to hold and work with the secret outside of the Erlang VM.</div><div><br></div><div>Probably the only real solution within the VM would be to patch the GC to zero any reclaimed memory. Or maybe not even the GC, but the memory allocators, in case a secret is copied to some non-GC-d memory area, such as an ETS table.</div><div><br></div><div>Cheers,</div><div>Daniel</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 26 Oct 2019 at 22:39, Amit K <<a href="mailto:klg.amit@gmail.com" target="_blank">klg.amit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Concerning the security practice of Zeroizing sensitive data from memory after you're finished with it, such as Cryptographic keys, passwords, etc, I wanted to ask if any of you ever had to implement such a thing in Erlang, and if so, how? :) </p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Also note that often this is a requirement that you must fulfill if you want your product to pass a security standard evaluation such as the "Common Criteria" one (As an example requirement see 

FCS_CKM_EXT.4 here: <a href="https://www.commoncriteriaportal.org/files/ppfiles/pp_nd_v1.0.pdf" style="font-family:Arial,Helvetica,sans-serif;font-size:small" target="_blank">https://www.commoncriteriaportal.org/files/ppfiles/pp_nd_v1.0.pdf</a>).</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">The problem of course is that in Erlang (and I suppose - FP in general) once a variable gets assigned, you are not allowed to change its value, and in particular of course overwrite it with zero bytes. </p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">One option I thought about is doing it with a NIF, but from my understanding a NIF isn't supposed to change its input values, it should treat them as constants, which understandable as well (basic FP language property). </p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Any feedback can be helpful :)</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Regards,</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)">Amit</p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)"><br></p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)"><br></p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Arial,"Helvetica Neue",Helvetica,sans-serif;font-size:15px;vertical-align:baseline;box-sizing:inherit;clear:both;color:rgb(36,39,41)"><br></p><div><br></div><div><br></div></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>