On Tue, Feb 25, 2014 at 08:21:22AM +0100, Ard Biesheuvel wrote:
For the authenticate-only data, this is manageable as you are only
dealing with input, but when dealing with both in- and output, as in
the core of CCM, it becomes very tedious.
So instead, I have opted for an inner blkcipher
On 25 February 2014 10:08, Herbert Xu herb...@gondor.apana.org.au wrote:
On Tue, Feb 25, 2014 at 08:21:22AM +0100, Ard Biesheuvel wrote:
For the authenticate-only data, this is manageable as you are only
dealing with input, but when dealing with both in- and output, as in
the core of CCM, it
On Tue, Feb 11, 2014 at 09:21:45AM +0100, Ard Biesheuvel wrote:
This adds support for a synchronous implementation of AES in CCM mode
using ARMv8 Crypto Extensions, using NEON registers q0 - q5.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
Hi all,
I am posting this for
On 25 February 2014 08:02, Herbert Xu herb...@gondor.apana.org.au wrote:
On Tue, Feb 11, 2014 at 09:21:45AM +0100, Ard Biesheuvel wrote:
This adds support for a synchronous implementation of AES in CCM mode
using ARMv8 Crypto Extensions, using NEON registers q0 - q5.
Signed-off-by: Ard
On Tue, Feb 25, 2014 at 08:12:36AM +0100, Ard Biesheuvel wrote:
Do you have any comments specifically about using an inner blkcipher
instance to implement the aead?
Indeed, the inner block cipher looks superfluous since it's only
used once by ccm and there is no nesting similar to aesni-intel.
On 25 February 2014 08:16, Herbert Xu herb...@gondor.apana.org.au wrote:
On Tue, Feb 25, 2014 at 08:12:36AM +0100, Ard Biesheuvel wrote:
Do you have any comments specifically about using an inner blkcipher
instance to implement the aead?
Indeed, the inner block cipher looks superfluous since
This adds support for a synchronous implementation of AES in CCM mode
using ARMv8 Crypto Extensions, using NEON registers q0 - q5.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
Hi all,
I am posting this for review/RFC. The main topic for feedback is the way
I have used an inner
