Re: CFR: AES-GCM and OpenCrypto work review

On 08/11/14 04:23, John-Mark Gurney wrote:
> Hello,
> 
> Over the last few months, I've been working on a project to add support
> for AES-GCM and AES-CTR modes to our OpenCrypto framework.  The work is
> sponsored by The FreeBSD Foundation and Netgate.
> 
> I plan on committing these patches early next week.  If you need more
> time for review, please email me privately and I will make delay.
> 
> The code has already been reviewed by Watson Ladd (the software crypto
> implementations) and Trevor Perrin (the aesni module part) and I have
> integrated these changes into the patch.
> 
> There are two patches, one is the changes for OpenCrypto and the test
> framework.  The other is the data files used by the test framework.
> The data is from NIST's CAVP program, and is about 20MB worth of test
> vectors.  (I just realized, should we look at compressing these on
> disk?)
> 
> Main patch (192KB):
> https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch
> 
> Data files (~20MB):
> https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch
> 
> A list of notable changes in the patch:
> - Replacing crypto(4) w/ NetBSD's version + updates
> - Lots of man page updates, including CIOCFINDDEV and crypto(7) which
>   adds specifics about restrictions on the modes.
> - Allow sane useage of both _HARDWARE and _SOFTWARE flags.
> - Add a timing safe bcmp for MAC comparision.
> - Add a software implementation of GCM that uses a four bit lookup
>   table with parallelization.  This algorithm is possibly vulnerable to
>   timing attacks, but best known mitigation methods are used.  Using
>   a timing safe version is many times slower.
> - Added a CRYPTDEB macro that defaults to off.
> - Bring in some of OpenBSD's improvements to the OpenCrypto framework.
> - If an mbuf passed to the aesni module is only one segment, don't do
>   a copy.  This needs to be improved to support segmented buffers.
> - Remove the CRYPTO_F_REL flag.  It was meaningless.  It was used but
>   did not change any behavior.
> - Add function crypto_mbuftoiov to convert an mbuf to an iov.  This
>   also converts the software crypto to only use iov's even for a simple
>   linear buffer, and so simplifies the processing.
> - Add a dtrace probe for errors from the ioctl.
> - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing)
>   of AES-GCM and future AEAD modes.
> 
> Future improvements:
> - Support IV's longer than 12 bytes for GCM.
> - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented
>   inputs don't have to be copied.

I have the question regarding to the algorithm of GF field calculations
used in the proposed implementation: why not use the recent researches
in GCM calculations, e.g. described in [1], for further speed optimizations?

[1] - https://eprint.iacr.org/2013/157.pdf

-- 
Vsevolod Stakhov