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 know there are more fixes and future improvements, but can't think of them now. Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) support for our IPsec. Once these patches have been committed, I'll work with him to integrate his patch. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
John-Mark Gurney <jmg at funkthat.com> writes:> 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.Please remember to bump __FreeBSD_version. DES -- Dag-Erling Sm?rgrav - des at des.no
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
Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +0000:> 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.pdfThe paper you linked to does not describe a new way of calculating GHASH, but evalutation of a bug in their implementation using the PCLMULQDQ instruction... If you mean, why don't I use OpenSSL's code? The reason is that their code is a perl script that generates assmebly... We don't have perl in base.. and I didn't want more assembly in our tree (see below).. Instead, I decided to use code from Intel's whitepaper: Intel?? Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode I didn't use their assembly version because I wanted to have maintainable code, and also the same code can be used on both i386 and amd64 arches.. This turns out to also be a good thing, as when I add segmented buffer support, it'll be much easier to add to the C version, and I only have to do the work once for two arches... Also, the software GF library that I wrote is using state of the art algorithms... An OpenBSD developer has tested my code and has seen a significant performance improvement over their old code, and are evaluating if they want to/can include it in their tree... Hope this answers your question. If not, please be more specific so I can answer it. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
On 08.11.2014 07: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 know there are more fixes and future improvements, but can't think of > them now.I tried your patch with my IPv4 forwarding test. When aesni module is loaded and aes-cbc is used I see growing of `invalid outbound packets` counter in `netstat -sp ipsec` output. And no packets are forwarded. Also while testing I got a panic in aesni_encrypt_cbc(). atal trap 9: general protection fault while in kernel mode cpuid = 4; apic id = 04 instruction pointer = 0x20:0xffffffff80d05c43 stack pointer = 0x28:0xfffffe00003f7e70 frame pointer = 0x28:0xfffffe00003f7eb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq286: ix0:que 4) The backtrace: #0 doadump (textdump=276160512) at pcpu.h:219 #1 0xffffffff80355525 in db_fncall (dummy1=<value optimized out>, dummy2=<value optimized out>, dummy3=<value optimized out>, dummy4=<value optimized out>) at /usr/src/sys/ddb/db_command.c:568 #2 0xffffffff8035520d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff80354f84 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80357980 in db_trap (type=<value optimized out>, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff8095c641 in kdb_trap (type=9, code=0, tf=<value optimized out>) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80d1edcc in trap_fatal (frame=0xfffffe00003f7dc0, eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0xffffffff80d1ea6e in trap (frame=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:201 #8 0xffffffff80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0xffffffff80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 #10 0xffffffff80d1e7ae in trap (frame=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:432 #11 0xffffffff80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0xffffffff8202f96e in aesni_encrypt_cbc (rounds=10, key_schedule=0xfffff8005603d400, len=3, from=0xfffff8013b0de65a "E", to=0xfffff8013b0de65a "E", iv=0xfffff8005603d6d0 "?#??8?:n?\r??\f???\v") at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 #13 0xffffffff820318d0 in aesni_process (dev=<value optimized out>, crp=0xfffff80109f7bc08, hint=<value optimized out>) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni.c:535 #14 0xffffffff80b170e9 in crypto_dispatch (crp=0xfffff80109f7bc08) at /usr/src/sys/opencrypto/crypto.c:807 #15 0xffffffff80b076d6 in esp_output (m=<value optimized out>, isr=<value optimized out>, mp=0x3, skip=<value optimized out>, protoff=<value optimized out>) at /usr/src/sys/netipsec/xform_esp.c:905 #16 0xffffffff80af7457 in ipsec4_process_packet (m=0xfffff8013b0de600, isr=<value optimized out>, flags=<value optimized out>, tunalready=<value optimized out>) at /usr/src/sys/netipsec/ipsec_output.c:594 #17 0xffffffff80a4a0db in ip_ipsec_output (m=<value optimized out>, inp=<value optimized out>, flags=0xfffffe00003f8494, error=0xfffffe00003f8490) at /usr/src/sys/netinet/ip_ipsec.c:332 #18 0xffffffff80a4b6b9 in ip_output (m=0xfffff8013b0de600, opt=<value optimized out>, flags=1, imo=<value optimized out>, inp=0x0) at /usr/src/sys/netinet/ip_output.c:476 #19 0xffffffff80a485eb in ip_forward (m=0xfffff8013b0de600, srcrt=<value optimized out>) at /usr/src/sys/netinet/ip_input.c:1571 #20 0xffffffff80a4825e in ip_input (m=0xfffff8013b0de600) at /usr/src/sys/netinet/ip_input.c:754 #21 0xffffffff809e7be1 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #22 0xffffffff809dfb53 in ether_demux (ifp=<value optimized out>, m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766 #23 0xffffffff809e0758 in ether_nh_input (m=<value optimized out>) at /usr/src/sys/net/if_ethersubr.c:573 #24 0xffffffff809e7be1 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #25 0xffffffff809dfdb6 in ether_input (ifp=<value optimized out>, m=0x0) at /usr/src/sys/net/if_ethersubr.c:674 #26 0xffffffff809e55e5 in vlan_input (ifp=0xfffff8000ef3e800, m=<value optimized out>) at /usr/src/sys/net/if_vlan.c:1239 #27 0xffffffff809dfac4 in ether_demux (ifp=0xfffff8000ef3e800, m=0xfffff8013b0de600) at /usr/src/sys/net/if_ethersubr.c:717 #28 0xffffffff809e0758 in ether_nh_input (m=<value optimized out>) at /usr/src/sys/net/if_ethersubr.c:573 #29 0xffffffff809e7be1 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0xfffff8013b0de65a) at /usr/src/sys/net/netisr.c:968 #30 0xffffffff809dfdb6 in ether_input (ifp=<value optimized out>, m=0x0) at /usr/src/sys/net/if_ethersubr.c:674 #31 0xffffffff8059f303 in ixgbe_rxeof (que=0xfffff8000ef5c1a0) at /usr/src/sys/dev/ixgbe/ixgbe.c:4530> Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) > support for our IPsec. Once these patches have been committed, I'll > work with him to integrate his patch.-- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20141114/32ab82e1/attachment.sig>