Change Details

This differential: 1. Refactors our native AES crypto API so that it can work both with `std::vector<std::uint8_t>&` and `rust::Slice<std::uint8_t>`. 2. Uses AES crypto API to encrypt log files. 3. Introduces additional encryption key to encrypt log files. This key lifecycle is tightly coupled with encryption key lifecycle used to encrypt latest compaction.

This differential: 1. Refactors our native AES crypto API so that it can work both with `std::vector<std::uint8_t>&` and `rust::Slice<std::uint8_t>`. 2. Uses AES crypto API to encrypt log files. 3. Introduces additional encryption key to encrypt log files. This key lifecycle is tightly coupled with encryption key lifecycle used to encrypt latest compaction. Why new encryption key? Cutting SQLCipher encryption key in half to make it 32 bytes is incorrect - keys should be created from each other using KDF. In order to correctly use KDF to create 32 byte key for logs from 64 byte SQLCipher key we would have to: 1. Implement creation of `master key` that is not used to encrypt anything. 2. Dig into native crypto API to expose to common C++ some KDF (SHA256 could be fine). 3. Refactor SQLCipher encryption key to be derived from master key. 4. Derive logs encryption key from master key. For now it is too much work we don't have cycles for so we are just creating brand new 32 key and make sure its lifecycle is strictly coupled with SQLCipher encryption key. It was discussed with Yiannis.

This differential: 1. Refactors our native AES crypto API so that it can work both with `std::vector<std::uint8_t>&` and `rust::Slice<std::uint8_t>`. 2. Uses AES crypto API to encrypt log files. 3. Introduces additional encryption key to encrypt log files. This key lifecycle is tightly coupled with encryption key lifecycle used to encrypt latest compaction. Why new encryption key? Cutting SQLCipher encryption key in half to make it 32 bytes is incorrect - keys should be created from each other using KDF. In order to correctly use KDF to create 32 byte key for logs from 64 byte SQLCipher key we would have to: 1. Implement creation of `master key` that is not used to encrypt anything. 2. Dig into native crypto API to expose to common C++ some KDF (SHA256 could be fine). 3. Refactor SQLCipher encryption key to be derived from master key. 4. Derive logs encryption key from master key. For now it is too much work we don't have cycles for so we are just creating brand new 32 key and make sure its lifecycle is strictly coupled with SQLCipher encryption key. It was discussed with Yiannis.