Residual key/nonce material on stack after ChaCha20 encrypt/decrypt

[rajsin31415]

Hi,

Following up on the secure-zero fixes in 2.3.3 (issue #230) — those addressed the heap-side wiping, but during a local source review I noticed that the ChaCha20 page-level encrypt/decrypt paths still leave derived material on the stack after return:

• otk (one-time key, 64 bytes) in CodecEncrypt and CodecDecrypt in cipher_chacha20.c
  *tag (Poly1305 tag, 16 bytes) in both paths
  *nonce locals in the encrypt/decrypt functions

These are stack-local arrays that are not scrubbed before the function returns. After return, the stack frames remain in memory until overwritten by subsequent calls — meaning the derived per-page key material is recoverable from a crash dump or memory forensics tool.

This is not a practical break of ChaCha20-Poly1305 and the severity is low — it requires an attacker who already has a process memory dump. But since the 2.3.3 release specifically targeted memory-wiping completeness, I wanted to flag this as a remaining gap in the same category.

The fix would be adding sqlite3mcSecureZeroMemory() calls for otk, tag, and nonce before each return in the encrypt/decrypt paths, consistent with the approach taken for the heap-side fixes in commit a8a8ea1.

(Related: I also filed a packaging provenance request on the NuGet wrapper repo)

Thank you so much!

[utelle]

Following up on the secure-zero fixes in 2.3.3 (issue #230) — those addressed the heap-side wiping, but during a local source review I noticed that the ChaCha20 page-level encrypt/decrypt paths still leave derived material on the stack after return:

• otk (one-time key, 64 bytes) in CodecEncrypt and CodecDecrypt in cipher_chacha20.c
• tag (Poly1305 tag, 16 bytes) in both paths
• nonce locals in the encrypt/decrypt functions

Yes, that is true. And it is no big deal to securely wipe memory in those places as well. However, if an attacker gains access to main memory of the system, they have entirely different ways of extracting information, because for example database contents is held unencrypted in main memory by SQLite itself. And what happens to the memory used for the primary passphrase after initialization, for example, is completely beyond the library’s control.

No excuse, not to try the best to protect the cipher related information, but let's be realistic: a perfect protection for a SQLite database in use does not exist.

These are stack-local arrays that are not scrubbed before the function returns. After return, the stack frames remain in memory until overwritten by subsequent calls — meaning the derived per-page key material is recoverable from a crash dump or memory forensics tool.

The same is true for cached unencrypted database pages.

This is not a practical break of ChaCha20-Poly1305 and the severity is low — it requires an attacker who already has a process memory dump. But since the 2.3.3 release specifically targeted memory-wiping completeness, I wanted to flag this as a remaining gap in the same category.

Thanks. I will look into the issue. I will add calls to sqlite3mcSecureZeroMemory() where appropriate.

The main goal for the encryption extension is to protect SQLite database files at rest. And I think that goal is achieved.

Protecting a running SQLite connection against attackers with access to the system's main memory would require much more effort than just wiping no longer used memory.

For example, the original SQLCipher library contains code to lock memory, so that it will not be written to a page file. However, that only provides a false sense of security, because at least on Windows the locking/unlocking mechanism simply doesn't work properly.