MemGuard: Secure sensitive information in memory in Go
github.com
github.com
My main issues:
1) The underlying primitives weren't really meant for this use case. They don't guarantee that a copy is flushed to disk, just that the canonical copy remains in RAM.
2) By creating pointers that are ostensibly supposed to be used, that aren't known to the GC, you're opening yourself up to a whole lot of use after free vulnerabilities, and just generally breaking the memory safety of the runtime. The other main area where you deal with raw non-GCed pointers like this is CGo, where you generally marshal into the GCed world as fast as you can for the reasons above.
3) What's the actual threat model here? Is stopping people from reading a core dump worth breaking the memory safety of the runtime?
well yeah. that’s the point. if you don’t want to write an entire application in C to prevent this. if for your application it’s not worth it, you live with it.
https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-...
Blog post about the project: https://spacetime.dev/memory-security-go
For encrypted data there is virtually no memory overhead but a guarded allocated has to be created to hold the decrypted data when it is needed.
The root encryption key is stored within a special container [0, 1] that has some small but constant CPU overhead as it is continuously mutating the memory associated with the structure in the background. This overhead can be tweaked (or even virtually eliminated) by changing the interval between successive cycles.