Simplify ChaCha20 interface #2990
Conversation
The nonce can just be opaque bytes. The block counter is tricky, as noted in the issue. The "obvious" choice is little-endian, as that is consistent with the philosophy of the designer (as I understand it), but that is not anything more than a guess. Absent strong evidence that big-endian is a better choice, I'm going to err on the side of not making a substantive change here. But I think that we need a consensus call to support that viewpoint. Closes #2171.
martinthomson
added
editorial
draft-ietf-quic-tls.md
Outdated
| used as the nonce. | ||
| in little-endian order and are used as the block count; a ChaCha20 | ||
| implementation might instead take the 4 bytes as an opaque sequence of bytes. | ||
| The remaining 12 bytes are used as the nonce. |
There was a problem hiding this comment.
While I like the idea of providing practical advice, I am a bit concerned of dropping the text that state the format of input in terms of specification language (in this case RFC 7539).
RFC 7539 assumes that the nonce to be three uint32 values. Is it possible to provide a formal definition without describing the interaction with that design? In practice, I think that the new text does not read good when the user is using a Chacha20 implementation (used on a big endian machine) that in fact takes uint32 values as inputs (rather than octets).
To reiterate, I think that it might be better preserve the existing text, at the same time "adding" implementation advice when using a Chacha20 function that takes octets as input.
The nonce can just be opaque bytes.
The block counter is tricky, as noted in the issue. The "obvious"
choice is little-endian, as that is consistent with the philosophy of
the designer (as I understand it), but that is not anything more than a
guess.
Absent strong evidence that big-endian is a better choice, I'm going to
err on the side of not making a substantive change here. But I think
that we need a consensus call to support that viewpoint.
Closes #2171.