Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: better memory handling? #158

Open
ivanjaros opened this issue Mar 19, 2024 · 1 comment
Open

Question: better memory handling? #158

ivanjaros opened this issue Mar 19, 2024 · 1 comment
Labels

Comments

@ivanjaros
Copy link

I have AES encryption library that defines a "key" struct which can encrypt and decrypt data with AES. I use the enclave as struct field where I store the secret for the key. Whenever I need to encrypt or decrypt data, I open the enclave which gives me locked buffer, do the work and and destroy the returned locked buffer. The thing is, this seems to me quite wasteful because it always creates the locked buffer and destroys it afterwards. I would prefer to have an internal buffer, or buffer pool, into which the enclave can read the secret, I do the work, and then just wipe it out with clear() or some random xor, so the memory footprint is fixed and I am not constantly allocating and freeing memory for the secret. Is something like that possible - reading into existing []byte from enclave?

@ivanjaros
Copy link
Author

ivanjaros commented Apr 1, 2024

Something like:

func OpenInto(e *Enclave, b []byte) ([]byte, error) {
	k, err := getOrCreateKey().View()
	if err != nil {
		return nil, err
	}
	_, err = Decrypt(e.ciphertext, k.Data(), b) // <- must ensure b has correct size/capacity
	if err != nil {
		return nil, err
	}
	k.Destroy()
	return b, nil
}

Although that getOrCreateKey uses Coffer object which also has temporary buffers so the memory overhead is quite massive in general and it would require way more work to make efficient than just adding OpenInto().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant