Re: A secure string library?

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-07-10 10:06:12

>
> Such a library would be quite useful, but when I was working at Ripple our investigation concluded that it would be difficult to impossible to implement it portably in a way that could make security guarantees. I would suggest that you do not bother, as you will face many incredibly annoying obstacles at every step of the way which conspire to make your implementation fail in common cases.
>
> P1315 is still making its way through WG21 I believe. Note that this proposal was adopted for C:
>
> https://open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1315r3.html

Looks like most implementations are far from trivial. According to
cppreference, C adopted it as part of C23 under the name
memset_explicit, but stdlibs don't implement it yet. Nothing in the
C++ side yet.
https://en.cppreference.com/w/c/string/byte/memset

>
> In my opinion a secure erase function which works most of the time but not all of the time is worse than not having it at all, as it may imply false claims about security. That said, I have asked an expert again for more details, which you can follow here:
>
> https://x.com/FalcoVinnie/status/1810654344607633515

Thanks for taking the time.

>
> Of course, I could be wrong and it is possible that newer operating systems offer robust facilities for ensuring that secrets are not leaked. This would require platform-specific implementation. If there is sufficient support for the popular platforms, it is worth exploring making into a Boost library.

There is OPENSSL_Cleanse, which does a similar job. I found it
surprisingly simple - I wonder if this is just enough or there are any
corner cases where this doesn't work:
https://github.com/openssl/openssl/blob/b544047c99c4a7413f793afe82ab1c165f85b5b6/crypto/mem_clr.c#L22

Other than that, there is
- explicit_bzero, available on Linux and FreeBSD
- ZeroSecureMemory on Windows
- I can't find anything about OSX - seems they don't expose such a function

So it really depends on whether we consider the volatile pointer
approach enough. If that's the case, it's doable. Otherwise, it's not
and we should rather wait.

>
> Thanks
>