- bytes are generated in a given order and endianness needs to be given
to the buffer for the generated number to make sense
- Seed(pub u128) exposes that endianness so it needs to be consistent to
outside users
This adds a new kind of seed to the csprng
When created which such seed, the AES-CTR random generator
initialization changes:
- The AES-KEY used is initialized differently
- The AES-CTR starts with a CTR that may not be 0
The changes make it so that the counter still goes from 0..MAX,
but now the AES-CTR will encrypt the counter + some offset allowing
to keep the regular behavior and the new one
This commit fixes an endian (little) for the counter
representation of the counter used in the AES-CTR counter.
This is so that, the random bytes generated are the same not matter
the endian of the system.
A test case with known answers is added, as well as make command
to run the test in an emulated big-endian arch using the `cross`
utility.
This also include a small refactor where now the block cipher
do not encrypt `AesIndex`. This is done as it makes more sense
(AES encrypts bytes, not numbers), so this allows to move and centralize
the concept of endian as well a centralize where batch created.
BREAKING_CHANGE:
- The x86_64, x86_64-unix, aarch64, aarch64-unix have been removed, the target
architecture and os family are now automatically detected. A `software_prng`
feature has been added to force the use of a software implementation on older
CPUs
