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 , for further speed optimizations?  - https://eprint.iacr.org/2013/157.pdf -- Vsevolod Stakhov _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"