Hi Ola, NULL encryption is defined here : https://www.ietf.org/rfc/rfc2410.txt. Accordingly, NULL does not alter the plaintext in anyway so it's equivalent with no cipher. Also the combination algorithm-mode was specified in the original proposal as one value and the list of algorithm/modes were selected from the ones specified in some RFCs (https://tools.ietf.org/html/rfc4835 for example). While many combinations are possible I think it's better to stick to the ones defined by networking standards as I think it's likely that crypto engines support these and not all possible combinations of alg/mode.
Thanks, Alex On 4 March 2015 at 18:38, Ola Liljedahl <[email protected]> wrote: > * @enum odp_cipher_alg:ODP_CIPHER_ALG_NULL > * No cipher algorithm specified > > Is this comment correct? > Don't we actually mean "Null cipher algorithm"? > The null algorithm is a valid cipher algorithm, it just doesn't > provide much security.... > > Should we define ciphers like AES well? Didn't the original crypto > proposal specify a more complete of cipher algorithms? > > Does the crypto implementation have to know about the mode (e.g. CBC, > CTR)? Cipher 3DES is defined with CBC mode. For counter mode each > block has its own counter value and it could be specified by the user > if each block is passed for encryption/decryption separately. How > large is a block supposed to be? A packet? > > Can crypto.h be extended to asymmetric (public/private key) > encryption/decryption as well? Do we need new calls and data > structures or just some new enums? > > -- Ola > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
