[dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

Matan Azrad matan at nvidia.com
Mon Feb 8 19:23:13 CET 2021


Hi Kusztal

First, thank you for this review and the suggestions.

From: Kusztal, ArkadiuszX
> > > > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher
> > > > block sizes
> > > >
> > > > In cryptography, a block cipher is a deterministic algorithm
> > > > operating on fixed- length groups of bits, called blocks.
> > > >
> > > > A block cipher consists of two paired algorithms, one for
> > > > encryption and the other for decryption. Both algorithms accept two
> inputs:
> > > > an input block of size n bits and a key of size k bits; and both
> > > > yield an n-bit output block. The decryption algorithm is defined
> > > > to be the inverse function of the encryption.
> > > >
> > > > Some cipher algorithms support multiple block sizes, e.g. AES-XTS
> > > > supports any block size in range [16B, 2^24B], in this case, A
> > > > plain-text data, divided into N amount of n-bits blocks, which is
> > > > encrypted to the same data size, cipher-text, must be decrypted in
> > > > the same division of N amount of n-bits blocks in order to get the
> > > > same plain-text
> > > data.
> > > [Arek] - Except that the last data block does not need to be n-bit
> > > long, beside that and lack of chaining it makes XTS no different to
> > > any other block cipher mode of operation.

The question is what is block:
The 16B of AES or the AES-XTS standard data-unit definition.

My intention here is like AES-XTS data-unit, and you understand it as AES 16B block(at least for this comment 😊).

Please try to understand it as data-unit (replace any "block" word in "data-unit")
Now, can you understand the commit log better without exceptions?

The important point for the API that I want, with you and the community help, to add is the "size" which the application and the drivers\devices must know in order to know how to decrypt an encrypted data.   

For AES-XTS this "size" is not always 16B.

So, if someone get a cipher-text which was encrypted by AES-XTS with initial tweak T and 2 keys K0,K1 it is not enough information in order to do decryption.
The 16B block of AES is not helping here.
Here, the user must know the data-unit size.
The formula D(E(b)) = b that I wrote below must use b as data-unit.
Are you agree?

> > > Block size itself for XTS-AES is always 16 bytes in the first place
> > > which is AES constraint.
> > > 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is
> > > data unit length that contains "data unit in bytes/ 16" AES blocks
> > > where last one can be incomplete.
> > > >
> > > > The current cryptodev API doesn't allow the user to select a
> > > > specific block size supported by the devices In addition, there is
> > > > no definition how the IV is detected per block when single
> > > > operation includes
> > > more than one block.
> > >
> > > [Arek] - Do you mean tweak increment per data unit? Like one op as a
> > > data stream (multiple data units) and tweak incremented by pmd?
> >
> > It can be defined differently per algorithm.
> [Arek] - what do you mean?

Maybe in other algorithms standards the IV can be changed differently than AES-XTS, I'm not familiar with all the algorithms 😊.

> > I know from AES-XTS standard that the tweak should be incremented by 1
> > per data-unit.
> > So, yes, here, the driver\device should take care for the incrementation.
> [Arek] - then it should be stated in rte_crypto_sym_op iv comments.

I stated it in the cipher transformation structure where the tweak is defined as IV for AES-XTS.

Do you think we need to add comment in the op too?

> >
> >
> > >
> > > >
> > > > That causes applications to use single operation per block even
> > > > though all the data is continuous in memory what reduces datapath
> > performance.
> > > >
> > > > Add a new feature flag to support multiple block sizes, called
> > > > RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS.
> > > > Add a new field in cipher capability, called bsf - block size
> > > > flags, where the devices can report the range of the supported block sizes.
> > > > Add a new cipher transformation field, called block_size, where
> > > > the user can select one block size from the supported range.
> > > >
> > > > All the new fields do not change the size of their structures.
> > > >
> > > > Using flags to report the supported block sizes capability allows
> > > > the devices to report a range simply as same as the user to read it simply.
> > > > Also, thus sizes are usually common and probably will be shared
> > > > between the devices.
> > > >
> > > > Signed-off-by: Matan Azrad <matan at nvidia.com>
> > > > ---
> > > >  lib/librte_cryptodev/rte_crypto_sym.h | 12 ++++++++++++
> > > > lib/librte_cryptodev/rte_cryptodev.h  | 23 ++++++++++++++++++++++-
> > > >  2 files changed, 34 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > > > b/lib/librte_cryptodev/rte_crypto_sym.h
> > > > index 9d572ec..9a1215d 100644
> > > > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > > > @@ -265,6 +265,18 @@ struct rte_crypto_cipher_xform {
> > > >                * which can be in the range 7 to 13 inclusive.
> > > >                */
> > > >       } iv;   /**< Initialisation vector parameters */
> > > > +
> > > > +     uint32_t block_size;
> [Arek] - looking from your answers below, this one could just be
> aes_xts_dataunit_len.

Are you sure there is no any other cipher algorithm that have something similar to data-unit of AES-XTS?
 
> > > > +     /**< When RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS is
> > > > reported, this is
> > > > +      * the block size of the algorithm, otherwise or when the value is 0,
> > > > +      * use the default block size provided in the capability.
> > > > +      * The value should be in the range defined by the bsf field in the
> > > > +      * cipher capability.
> > >
> > > [Arek] - nowadays algorithms rather don't have different block
> > > sizes, though I see people set this field even for stream ciphers.
> > > If such algorithm would happen it probably could just get a suffix
> > > in crypto_cipher_enum. Otherwise some fixed size array could be added.
> >
> > First, if no different block size per algorithm, why do we need this
> > parameter at all?
> [Arek] - I am not sure but looks like informative, especially that it is only one
> 16bit long field.

Yes, it is 16 bits, but it is not needed, I don't think applications use this capability if it is defined by definition per algorithm.
Looks like candidate for deprecation if so.

> >
> > Second,
> > Cipher block defined to be like this D(E(b)) = b
> > D: decryption function
> > E: encryption function
> > b: plain-text block data.
> >
> > In case of AES-XTS the cipher block size is the data-unit size.
> > There is a big range of optional data, see in standard.
> [Arek] - Currently in DPDK we have 3 block cipher algorithms:
> TDEA(3DES) - 8 byte block, AES - 16 byte block, KASUMI -8byte (but deprecated
> since 3G), Additionally IPsec ietf defines NULL as block cipher with 1 byte len,
> but ETSI doesn't do that with EEA,EIA,NIA-0.

OK

> >
> >
> > > > +      *
> > > > +      * - For AES-XTS it is the size of data-unit, from IEEE Std 1619-2007.
> > > > +      * For-each data-unit in the operation, the tweak(IV) value is
> > > > +      * assigned consecutively starting from the operation assigned tweak.
> > > > +      */
> > > [Arek] - if data unit would be session value (key scope in xts
> > > naming) where the number of units would be taken from, sym_op->len ?
> >
> > Yes, it is already defined there that it must be multiple of block
> > size(data-unit in AES-XTS case).
> [Arek]  - this comment was meant for cipher block modes that needs input
> aligned to block cipher len, like CBC padding.

So, Do you think the current comment is wrong?

> In case of XTS it should be something like : multiple of xform xts_data_unit len
> or one of two:
> - data unit len itself in case device does not support multiple data units.
> - 0 and data unit len would be taken from session/xform in case device does not
> support multiple data units.

Yes, the first one doesn't break API, so it is better.

> >
> > > (For standard storage example: data unit size -> logical block size,
> > > sym_op->len
> > > -> range of consecutive logical blocks.) If so it probably could be
> > > -> session-less op
> > > as this cipher key would be unusable after it.
> > >
> >
> > Can be session and session-less modes.
> >
> > If the user want to operate on different groups of blocks in the same
> > stream he can use the same session(key) with different ops.
> [Arek] - yes, it should be possible to do that if user keep track of tweak value.
> 
> >
> > Am I missing here?
> >
> > > >  };
> > > >
> > > >  /** Symmetric Authentication / Hash Algorithms diff --git
> > > > a/lib/librte_cryptodev/rte_cryptodev.h
> > > > b/lib/librte_cryptodev/rte_cryptodev.h
> > > > index ae34f33..60ba839 100644
> > > > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > > > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > > > @@ -96,6 +96,19 @@ struct rte_crypto_param_range {  };
> > > >
> > > >  /**
> > > > + * Crypto device supported block size flags for cipher algorithms
> > > > + * Each flag represents single or range of supported block sizes
> > > > +*/ #define RTE_CRYPTO_CIPHER_BSF_ALL 0x1
> > > > +/* All the sizes from the algorithm standard */ #define
> > > > +RTE_CRYPTO_CIPHER_BSF_512_BYTES 0x2 #define
> > > > +RTE_CRYPTO_CIPHER_BSF_520_BYTES 0x4 #define
> > > > +RTE_CRYPTO_CIPHER_BSF_4048_BYTES 0x8 #define
> > > > +RTE_CRYPTO_CIPHER_BSF_4096_BYTES 0x10 #define
> > > > +RTE_CRYPTO_CIPHER_BSF_4160_BYTES 0x20 #define
> > > > +RTE_CRYPTO_CIPHER_BSF_1M_BYTES 0x40
> > > [Arek] - when adding constants source should be attached as well.
> > > > +
> > > > +/**
> > > >   * Symmetric Crypto Capability
> > > >   */
> > > >  struct rte_cryptodev_symmetric_capability { @@ -122,11 +135,19 @@
> > > > struct rte_cryptodev_symmetric_capability {
> > > >                       enum rte_crypto_cipher_algorithm algo;
> > > >                       /**< cipher algorithm */
> > > >                       uint16_t block_size;
> > > > -                     /**< algorithm block size */
> > > > +                     /**<
> > > > +                      * algorithm block size
> > > > +                      * For algorithms support more than single block size,
> > > > +                      * this is the default block size supported by the
> > > > +                      * driver, all the supported sizes are reflected in the
> > > > +                      * bsf field.
> > > > +                      */
> > > >                       struct rte_crypto_param_range key_size;
> > > >                       /**< cipher key size range */
> > > >                       struct rte_crypto_param_range iv_size;
> > > >                       /**< Initialisation vector data size range
> > > > */
> > > > +                     uint32_t bsf;
> > > > +                     /**< Block size flags */
> > > >               } cipher;
> > > >               /**< Symmetric Cipher transform capabilities */
> > > >               struct {
> > > > --
> > > > 1.8.3.1



More information about the dev mailing list