It's worth noting that we considered a variant of this design initially and then decided on the XOR design instead.
-Ekr On Fri, Jun 2, 2017 at 4:20 PM, Adam Langley <a...@imperialviolet.org> wrote: > On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov <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 https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
