Regarding [2], we should be counting the functionality for serialization and the increment of record number needed by the current nonce method.
Serialization would need two bswaps for little-endian platforms and an increment. (We need to bring the integer into host format first, thus the roundtrip with swaps.) These are the 3 instructions that I counted: two bswaps, one increment. That's all that my method needs. If we assume that the layers are mixed together, there may be some reuse. If we consider a stronger separation, where the encryption layer is as independent as possible, it will have to do what the current TLS 1.3 prescribes independently. I am not saying that performance savings due to this proposal are significant. However, some may do encryption in hardware, while the nonce will probably always be in software. My main point here is simplicity. It seems easier to me to increment 12 bytes (suppressing the carry) in-place. On 06/02/2017 04:20 PM, Adam Langley wrote: > On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov <cry...@brainhub.org > <mailto:cry...@brainhub.org>> wrote: > > The benefits are that the encryption layer doesn't need to deal with a > record number or its serialization, or the mask. The state is minimal. > The nonce update code is faster and smaller (e.g. 3 instructions on > x86_64). > > I would like to thank earlier reviewers. As part of these reviews > RFC7905 was brought up. I appreciate the desire not to update the > RFC7905, but this should not interfere with the WGLC, and it's a fairly > new stream cipher anyway. > > > If the encryption layer implements the standard interface[1] then it > doesn't care about any of this anyway. Also, I'm not sure that it is any > faster (the current scheme can be done in three x86-64 instructions > too[2]), but any difference would be immeasurably tiny compared to the > work of the AEAD itself. > > The overriding interest here is to avoid having yet another nonce > format. RFC 7905 diverged from TLS 1.2 with the intent that it would > align with TLS 1.3. There would have to be a significant reason to add > more complexity. > > [1] https://tools.ietf.org/html/rfc5116#section-2.1 > [2] context struct addr in rax, seq number in rcx: leaq > maskOffset(%rax), %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi) > > > Cheers > > AGL > > -- > Adam Langley a...@imperialviolet.org <mailto:a...@imperialviolet.org> > https://www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
