On 5 March 2015 at 09:34, Alexandru Badicioiu <[email protected]> wrote: > 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. Yes I just think the wording is poor. By specifying ODP_CIPHER_ALG_NULL, we specifically ask for the null cipher. We don't ask for "no cipher" which in my mind could mean something else. "no" and "null" are necessarily not the same thing in my programmer world.
> 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. AES_CBC is also a MUST in this RFC. AES_CTR is a SHOULD. These were in the original proposal as Leonard's email shows. I think counter mode is important is this allows for parallelism in encryption and decryption which should be useful when targeting high bandwidth flows (packets can be processed in parallel). We need to make sure we don't screw up the crypto API so that this is not possible. > > 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
