A GC between ReadToEnd and Convert.Frombase64String might cause base64 to be copied, before becoming 'fixed'. Similar problem with key. But the HTTP request body contains this data anyway...

Also, StreamReader has a buffer from which you need to remove the key, somehow.

I might be completely wrong here, but can you know that a character in a c# string (utf-16) is the same size as a char? if so, the ZeroMemory method might not zero out all the base64 encoded string.

ServerStore shall definitely keep the key in memory at least until Commit() is called. If it has some sort of caching, it is going to live a long life in it.

If key.Length != 256 / 8 is false, an exception is thrown without wiping the key.

Full compilation of security risks:

1. As @Henning noted, when the exception is thrown for invalid key length, the key exists in both base64 and key, and has not been securely zero'd. Solution: Add a try/finally to ensure the memory is zero'd.

2. As @Alex noted, base64 and key are not fixed, so they could be moved between creation and zero'ing, at which point the key is still in memory in an unknown location. Solution: create base64 and key with known sizes and fix them in memory before loading them with data. A custom version of FromBase64String() may be required to do this properly.

3. If there is an exception in AllocateOperationContext(), OpenWriteTransaction(), or PutSecretKey(), then the key still exists in key, and has not been securely zero'd. Solution: Add a try/finally to ensure the memory is zero'd.

4. As @Mircea noted, StreamReader will buffer the data as it passes through. Solution: You cannot zero this memory, so avoid using StreamReader entirely.

5. Securely zeroing the rest does not eliminate all security risk: HttpContext.Request.InputStream uses (through several layers of indirection) HttpRawUploadedContent, which buffers the entire data portion of the HTTP request. Solution: None. This cannot be securely zero'd or avoided.

6. None of this matters if the request is made without HTTPS. I know Raven recommends and encourages the use of HTTPS, but if this request is done via HTTP, then the data will be exposed to the wire during transport. Solution: Reject this method call if it was not done via HTTPS. This requirement may be handled in the code or in configuration.

Basic compile error:

1. HttpContext.Request.Body does not exist, it should be HttpContext.Request.InputStream

PutSecretKey also needs to be inside a try/finally. And there is no need to call ZeroMemory inside the transactional statement.

I am more interested in Oren's last question ... "how much sense does it make to even attempt what it is doing?"