Dmitry Eremin-Solenikov wrote:
> On 11.07.2017 15:31, Petri Savolainen wrote:
> > Added a parameter for passing salt for AES GCM. Currently,
> > only option for length is 4 bytes, but later on other algorithms
> > may need more/less salt data.
> >
> > Signed-off-by: Petri Savolainen <petri.savolai...@linaro.org>
> > ---
> > include/odp/api/spec/ipsec.h | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> > index e602e4b8..15dbb164 100644
> > --- a/include/odp/api/spec/ipsec.h
> > +++ b/include/odp/api/spec/ipsec.h
> > @@ -384,6 +384,16 @@ typedef struct odp_ipsec_crypto_param_t {
> > /** Authentication key */
> > odp_crypto_key_t auth_key;
> >
> > + /** Salt for SA's that use AES_GCM algorithm. Other algorithms ignore
> > + * these fields. */
>
> I'd suggest more generic wording:
> - Additional static IV data used as salt or nonce for block IV
> computation if algorithm/block mode requires it. For example, GCM
> requires 4 bytes salt, CCM requires 3 bytes salt, CTR mode requires 4
> bytes nonce.
I do not think that would be very good either since this is not for
computing ESP IV but GCM/CCM IV which is called nonce in the context
of ESP. IOW, I think the description should not refer to IV.
Maybe it should just be called 'additional keying material' and maybe the
structure name should also be changed from salt to something more generic.
An alternative would be to require that much more bytes in the key field(s)
but that would sort of change the meaning of odp_crypto_key_t when used in
the context of IPsec (the same algorithm would require different key lengths
depending on whether it is used through the IPsec API or the crypto API).
Janne
>
> > + struct {
> > + /** Pointer to salt data. */
> > + const uint8_t *ptr;
> > +
> > + /** Salt length. Valid value for AES_GCM is 4. */
> > + uint32_t len;
> > + } salt;
> > +
> > } odp_ipsec_crypto_param_t;
> >
> > /**
> >
>
>
> --
> With best wishes
> Dmitry
