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.
pubstructKeyMaterial<constKEY_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.