cipher_chacha20.c: Can reserved == 0 still occur in the ChaCha20 page cipher callbacks?

[matbech]

In cipher_chacha20.c, both EncryptPageChaCha20Cipher() and DecryptPageChaCha20Cipher() contain:

int nReserved = (reserved == 0 && legacy == 0)
    ? 0
    : GetReservedChaCha20Cipher(cipher);

When nReserved == 0, they use the encryption-only branch, deriving the nonce through sqlite3mcGenerateInitialVector() rather than storing a random nonce and Poly1305 tag.

What supported configuration or API sequence can cause these callbacks to receive reserved == 0?

From tracing the current implementation:

• GetReservedChaCha20Cipher() always returns 32.
• Normal cipher initialization configures those 32 reserved bytes.
• When encrypting an existing plaintext database, the original database may have zero reserved bytes, but its read cipher is disabled.
• When removing encryption, the destination has zero reserved bytes, but its write cipher is disabled.

Instrumenting a ChaCha20-only WASM build, I have not observed calls to sqlite3mcGenerateInitialVector() during encryption, rekeying, decryption, updates, VACUUM, or VACUUM INTO.

Is the zero-reserve branch still required for a supported scenario, or is it leftover code that could be removed?

[utelle]

Is the zero-reserve branch still required for a supported scenario, or is it leftover code that could be removed?

Good question. This is code that was added long before the project SQLite3MultipleCiphers was created, when it still was an integrated part of the wxSQLite3 project and SQLite had its own encryption API. AFAICR it had to do with the SQLite backup interface, which didn't allow to change the number of reserved bytes. That is, when doing a backup of a plain database file to an encrypted database file, this was only possible by not generating MACs.

I have no idea whether anybody actually used that (mis)feature, but I kept it for backward compatibility. Nowadays there is VACUUM INTO to make backups in a more flexible way.