Scanmaster elm too big to fit into memory how to#
Scanmaster elm too big to fit into memory code#

Scanmaster elm too big to fit into memory how to#

As you say, we can also just state 'you must know exactly how the libraries you call are implemented to know how to safely wield them with KeepSecret.' My attempt to blunt that edge slightly was to say that that, for those well-known libraries, if you KeepSecret only the specific API calls that receive secret data, that's sufficient to preserve the secrecy of the data, and the crypto packages promise to not do things like what I described above. That's an extension of the 'don't copy(insecure, secure)' rule, but because the copy would be hidden behind an API surface, it's not as obvious as writing the copy() yourself. Otherwise, you could have a New() function that allocates some buffer memory, and a later Encrypt(secretThing) that copies secretThing into the preallocated buffer - which itself is not covered by KeepSecret. That does lead to a mild subtlety: the entire use of an API must be shrouded in KeepSecret, not just individual calls that receive secret values. That way crypto and x/crypto and whatever else (say, a base64 encoder) do not need to be modified. Namely, crypto and x/crypto can do whatever they want, and if you want to call them using secrets, then you make sure to call them from a KeepSecret block. While most of your summary seemed right on, this seemed to stray from the general idea. But you can force objects to be allocated off the stack by, for example, putting a finalizer on Revise the existing crypto and x/crypto implementations such that, if they are handed slices of secure memory, they will internally preserve that secureness by entering/exiting secure mode appropriately. We don't currently zero the old copy of those objects. *Go does have copying for stack-allocated objects. I think in general key management is going to require separate allocations for secrets anyway (specially mapped, on secure physical memory, etc.), so adding a mechanism for Go objects is only solving part of the key management problem. It could write them to a swap file, for example. In particular, Go exerts no control over what the OS does with heap-backed pages. I think this issue is asking for something more. (Kinda hacky overloading of semantics, but might work.) Maybe we recommend using the finalizer above, and only zero the original copy of things that have finalizers. If/when Go has a copying GC*, then we would need to think about whether to zero the original copy of an object when it is moved. Runtime.SetFinalizer(s, func(s *Secret) ) alternatively, unsafe can be used to instantiate the chacha20poly1305 object, but then you'd need a Init() method.if necessary, add a NewWithAllocator(makeSlice func(size int) byte) function so that key material is placed in manually allocated memory exempt from GC and swapping (for example via memguard).make an implementation with a Wipe() method guaranteed not to make copies of the key.add a Wipe() method to the implementation (say chacha20poly1305) the method might exist or not based on the platform since implementations can differ, the application can decide to warn or bail out if Wipe() is unavailable by doing an interface-upgrade from AEAD, or not to compile at all by calling it directly on the concrete type.In particular there is no way to retroactively enforce that an interface implementation does not copy key material on the heap (at least outside of the stdlib, and we don't want a security guarantee that breaks when you use external implementations). This is going to be extremely hard to obtain as a generic guarantee, for all the reasons mentioned here, at #21374 and at awnumar/memguard#3. In one sense, you'd have to replace make itself to using manually managed memory, like how memguard does it, but that of course is fundamental change to Golang itself, and would make the niceties of GC pointless

Scanmaster elm too big to fit into memory code#

Effectively, you'd have to create custom implementations of all the existing crypto code in the standard lib, supplementary x/crypto libs, even indirect packages like math/big would end up getting into scope. If I'm not mistaken, you could currently call aes.NewCipher(key) where key points to a memguard buffer, immediately wipe key, then continue to use the instantiated cipher 'object' for calls to Encrypt and Decrypt calls, since now only the internally expanded key is required. The key expansion is a deterministic process so once c.enc and c.dec are set, if the system was compromised such that memory could be scanned, even on a system where memguard is used, an attacker could get the contents of c.enc or c.dec, reverse the key expansion process, and now they have the original key. Just as another example of what was mentioned at the end, even creating an AES block primitive causes an allocation right before key expansion, which shows wiping the key is inadequate, including how memguard does it.