Botan::secure_vector<uint8_t> Vs. std::vector<uint8_t>

[nata11]

Hello, I am new the to Botan and have been browsing the source code and examples for an app I am working on. My question is, in the example code, I see various ways of creating keys and iv/nonce which include a combination of either Botan::secure_vector<uint8_t> OR std::vector<uint8_t> . Primarily the keys are constructed using std::vector and IV is constructed using secure_vector. I would assume the keys also need to be constructed with secure_vector given what the documentation says about using secure_vector in place of std::vector. Essentially I am asking what are the use cases of using either one of them in our own application code.
Thanks

[reneme]

Hi Nadeem,

as you found in the documentation, Botan::secure_vector uses a custom allocator that does two things:

1. zeroize the memory on destruction
2. try to lock the memory, so that the OS isn't swapping the underlying pages to disk

Both are defense-in-depth measures to avoid information disclosure on (e.g.) multi-tenant systems.

Primarily the keys are constructed using std::vector and IV is constructed using secure_vector.

This is indeed misleading and should be the other way round. In typical applications IVs don't have to remain secret, while keys should definitely be protected. Thanks for pointing this out, we'll work on our examples.

Essentially I am asking what are the use cases of using either one of them in our own application code.

In your application, you're free to use the secure_vector for anything that should be protected by the measures pointed out above. Most notably, that are cryptographic keys (e.g. symmetric keys and also private keys). But also, plaintext payload (that was or will be encrypted by the library) could be a good candidate for storage within secure_vector.

[nata11]

Thanks for the pointers. I have my set of minimal example code that I am creating based on the src examples and will definitely switch over to using secure_vector for the reasons you have pointed to.