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
