Looking at this more closely, this takes arbitrary buffers of data and uses syscalls such as mlock to prevent paging memory to disk, as well as cleans up at the end by zero'ing out the buffers for you.
Has this been audited in any way? Is there a garuntee that the Go runtime won't, say, keep a duplicate of the buffer you copy() from in memory somewhere that can be paged?
Additionally, a technical description of how this works in the README would be nice for those that aren't familiar with how the memory gets locked.
The linked approach does not work for exactly the reasons you specify. Go can and will move and copy memory around as it sees fit, which defeats the purpose of this library. You must manage the memory yourself to have any chance of doing this reliably.
go.secrets uses the libsodium sodium_memzero to clear the bytes, whereas memguard sets each byte to 0.
I feel more comfortable with the first, but can't exactly explain why. memguard seems better organised in the repo like a ready to go package; I think go.secrets would be a better solution if it was organised as well as memguard.
Hey there! Thanks for this advice, I'll definitely consider this in the next release. Like I said in other parts of this thread, the project is in very early stages right now and, as I understand from reading a lot of the replies, I seem to have missed a lot.
This is fun in theory, but doesn't really give you a lot in practice. A few random points:
* On many server systems swap is already disabled today (for availability reasons), so you don't really win anything. (Although what you're doing also won't hurt, so it's fine.)
* On many desktop systems on the other hand, swap is not the only reason for memory to end up on disk, mainly due to hibernation modes. This doesn't just include OS-implemented hibernation modes, but also firmware-provided ones (e.g. Intel's RST.)
* If you're running in a VM (in the cloud?), the hypervisor pretty much doesn't care what you lock in memory.
* If your process crashes you may end up with a crash dump, depending on the system's configuration. (On Linux you can avoid that using prctl's PR_SET_DUMPABLE option.)
Even if none of that is a problem for you, you still need to fill and use the values you protected. Where do you get the keys from? Is that path protected as well? This might be fine if you can generate them in place, but even then it's pretty hard. The same is true for key usage: How do you make sure that the key doesn't end up in another portion of your memory? It's almost certain that it ends up either on the stack or somewhere else sooner or later...
[+] [-] e79|9 years ago|reply
Has this been audited in any way? Is there a garuntee that the Go runtime won't, say, keep a duplicate of the buffer you copy() from in memory somewhere that can be paged?
Additionally, a technical description of how this works in the README would be nice for those that aren't familiar with how the memory gets locked.
Neat project. Curious to see how this develops.
[+] [-] stouset|9 years ago|reply
https://news.ycombinator.com/item?id=14174500
[+] [-] amenghra|9 years ago|reply
[+] [-] encryptThrow32|9 years ago|reply
I feel more comfortable with the first, but can't exactly explain why. memguard seems better organised in the repo like a ready to go package; I think go.secrets would be a better solution if it was organised as well as memguard.
[+] [-] nemo1618|9 years ago|reply
[+] [-] libeclipse|9 years ago|reply
All of this stuff will be fixed soon.
[+] [-] __michaelg|9 years ago|reply
* On many server systems swap is already disabled today (for availability reasons), so you don't really win anything. (Although what you're doing also won't hurt, so it's fine.)
* On many desktop systems on the other hand, swap is not the only reason for memory to end up on disk, mainly due to hibernation modes. This doesn't just include OS-implemented hibernation modes, but also firmware-provided ones (e.g. Intel's RST.)
* If you're running in a VM (in the cloud?), the hypervisor pretty much doesn't care what you lock in memory.
* If your process crashes you may end up with a crash dump, depending on the system's configuration. (On Linux you can avoid that using prctl's PR_SET_DUMPABLE option.)
Even if none of that is a problem for you, you still need to fill and use the values you protected. Where do you get the keys from? Is that path protected as well? This might be fine if you can generate them in place, but even then it's pretty hard. The same is true for key usage: How do you make sure that the key doesn't end up in another portion of your memory? It's almost certain that it ends up either on the stack or somewhere else sooner or later...
[+] [-] zimbatm|9 years ago|reply
They also set the ipc_lock capability before starting the process in docker: https://github.com/hashicorp/docker-vault/blob/e8edfef53deb6...
[+] [-] ziikutv|9 years ago|reply
I think the only feedback would be to show sample usages and adding a bit more technical information*
[*] That would be understandable to people with basic encryption knowledge.
[+] [-] libeclipse|9 years ago|reply