CFR: AES-GCM and OpenCrypto work review
Vsevolod Stakhov
vsevolod at highsecure.ru
Sat Nov 8 18:55:31 UTC 2014
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
More information about the freebsd-security
mailing list