Hi Shally,
I'm implementing a crypto asymmetric PMD and have some concerns about the API
which I
will work through over the next few months. Starting with modexp and modinv I
have
the following questions / suggestions:
rte_crypto_asym.h:233
rte_crypto_param modulus;
/**< modulus
* Prime modulus of the modexp transform operation
in octet-string
* network byte order format.
*/
[AK] - Why prime? RSA for example use semi-prime
or "RSA multi-prime".
It should be just any positive integer.
[AK] - If session API layer should check if it is
non-zero and set flag accordingly.
rte_crypto_asym.h:253
rte_crypto_param modulus;
/**<
* Pointer to the prime modulus data for modular
* inverse operation in octet-string network byte
* order format.
*/
[AK] - Same situation as for mod exp. Just any
number.
For example when using with RSA Carmichael and
Euler Totient function will even
have composite factors.
rte_crypto_asym.h:323
struct rte_crypto_mod_op_param {
[AK] - There should be a result field. It size
should be equal to the size
of modulus. Same apply to mod mult inverse. It
should be driver responsability to check if result
will not overflow
[AK] - Any particular reason modulus and exponent
is in session? Not saying
it is wrong but is it for DH, RSA use cases only?
rte_crypto.h:39
enum rte_crypto_op_status {
[AK] - There will be many more status options in
asymmetric,
could we probably create new one for asymmetric
crypto? Even if asymmetric and symmetric
overlap?
For mod exp, mod inv potentially it will be:
DIVIDING_BY_ZERO_ERROR, INVERSE_NOT_EXISTS_ERROR...
rte_crypto_asym.h:33
size_t length;
/**< length of data in bytes */
[AK] - Is it guaranteed to be length of actual
data, not allocated memory (i mean no leading 0ed bytes), so the most
significant bit will be in data[0]?
[AK] - could it be uint16/32_t instead as size_t
can have different sizes in different implementations, uint16_t should be enough
for all algorithms big integer sizes
rte_crypto_asym.h:74, 250, 257, 351
/**< Modular Inverse
[AK] - Modular Multiplicative Inverse
Thanks,
Arek
