If we are standardizing on always assuming a memory allocator, then we can consider making KeyMaterial carry a Vec<u8> instead of a [u8; KEY_LEN], which would reduce a number of friction points across the library.
pub struct KeyMaterial<const KEY_LEN: usize> {
buf: Secret<[u8; KEY_LEN]>,
key_len: Secret<usize>,
key_type: KeyType,
security_strength: SecurityStrength,
allow_hazardous_operations: bool,
}The core change would be pretty simple: keep the <const KEY_LEN: usize>, but change it to <const INITIAL_CAP: usize> so that the type aliases for KeyMaterial128, KeyMaterial256, KeyMaterial512 are still there, and efficient about not needing to up-allocate for the common cases.
Then change buf: Secret<[u8; KEY_LEN]> to buf: Secret<Vec<u8>> or possibly buf: Vec<Secret<u8>>.
This will require some thought about Secret since currently it can only handle statically-sized types due to how the zeroizer is implemented. Possibly buf: Vec<Secret<u8>> is the right answer and does not require any changes to Secret.
If we are standardizing on always assuming a memory allocator, then we can consider making KeyMaterial carry a
Vec<u8>instead of a[u8; KEY_LEN], which would reduce a number of friction points across the library.The core change would be pretty simple: keep the
<const KEY_LEN: usize>, but change it to<const INITIAL_CAP: usize>so that the type aliases for KeyMaterial128, KeyMaterial256, KeyMaterial512 are still there, and efficient about not needing to up-allocate for the common cases.Then change
buf: Secret<[u8; KEY_LEN]>tobuf: Secret<Vec<u8>>or possiblybuf: Vec<Secret<u8>>.This will require some thought about Secret since currently it can only handle statically-sized types due to how the zeroizer is implemented. Possibly
buf: Vec<Secret<u8>>is the right answer and does not require any changes to Secret.