6 ms·
MemGuard: Secure sensitive information in memory in Go
- azhenley 7y agoHow much does it impact performance?
- libeclipse 7y agoThere is a memory overhead associated with guarded heap allocations. The time overhead is only applicable when creating or destroying them. 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. [0] https://spacetime.dev/encrypting-secrets-in-memory https://spacetime.dev/encrypting-secrets-in-memory [1] https://spacetime.dev/memory-retention-attacks https://spacetime.dev/memory-retention-attacks
- mehrdadn 7y agoProbably not a big deal, but they're reinventing the wheel a bit... Windows has RtlEncryptMemory/CryptProtectMemory for this. https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectmemory https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-...
- christoph-heiss 7y agoNot really a cross-platform API, is it?
- mehrdadn 7y agoNo, but I'm suggesting it's not a bad idea to use it on Windows. That way if there's ever an improvement made to it (imagine better hardware support or something coming along someday), you'd get it automatically.
- pjmlp 7y agoNo, but it could take advantage of native API in each platform and fall back into Go ones when such kind of APIs aren't available.
- innocentoldguy 7y agoSorry, but I’m super tired of “blah_blah_blah, written in Go” articles/titles (two so far today). If Go has some amazing feature, great! Let’s talk about it. If a program has some amazing feature, great! Let’s talk about that. All these “blah_blah_blah, written in Go” articles make it sound like Go is retarded in some way and that the ability to actually write programs in Go is somehow amazing. Is that really the case? I don’t recall being inundated with “blah_blah_blah, written in C, C++, Swift, Rust, Erlang, C#, Java, Python, Ruby, Elixir, etc.” articles. Why do we have to constantly remind everyone that you can actually write programs in Go?
- pgeorgi 7y ago> blah_blah_blah, written in [...] Rust Those are too popular as well, e.g.: https://news.ycombinator.com/item?id=18895655 https://news.ycombinator.com/item?id=18895655, https://news.ycombinator.com/item?id=19583384 https://news.ycombinator.com/item?id=19583384, https://news.ycombinator.com/item?id=19686972 https://news.ycombinator.com/item?id=19686972, https://news.ycombinator.com/item?id=19064069 https://news.ycombinator.com/item?id=19064069, https://news.ycombinator.com/item?id=19540845 https://news.ycombinator.com/item?id=19540845, https://news.ycombinator.com/item?id=18903235 https://news.ycombinator.com/item?id=18903235, https://news.ycombinator.com/item?id=19541741 https://news.ycombinator.com/item?id=19541741, https://news.ycombinator.com/item?id=19883626 https://news.ycombinator.com/item?id=19883626, https://news.ycombinator.com/item?id=19471471 https://news.ycombinator.com/item?id=19471471, https://news.ycombinator.com/item?id=18696291 https://news.ycombinator.com/item?id=18696291, ...
- nirui 7y agoYeah I kind know what you mean, but this kind of expression (Very similar to Whataboutism) is how flame war started.
- w56rjrtyu6ru 7y ago> Why do we have to constantly remind everyone that you can actually write programs in Go? Love this!
- 7y ago
- nsajko 7y agoPrevious discussion: https://news.ycombinator.com/item?id=14173716 https://news.ycombinator.com/item?id=14173716 Blog post about the project: https://spacetime.dev/memory-security-go https://spacetime.dev/memory-security-go
- libeclipse 7y agoMore recent post about the project: https://spacetime.dev/encrypting-secrets-in-memory https://spacetime.dev/encrypting-secrets-in-memory
- java-man 7y agoI think we need something like this in java runtime.
- bbmario 7y agoDoes anyone know anything similar for C/C++?
- johnisgood 7y agohttps://github.com/jedisct1/libsodium-doc/blob/master/helpers/memory_management.md https://github.com/jedisct1/libsodium-doc/blob/master/helper...
- bbmario 7y agoHad no idea libsodium provided that. Thank you!
- monocasa 7y agoSo, we just finished extricating this from our codebase. 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?
- techslave 7y ago> 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.
- monocasa 7y agoI can't quite follow all of the indefinite pronouns. Can you restate?