I have now read the latest draft-ietf-ipsecme-chacha20-poly1305-06 and
it seems to be ok. I have few nits that could be fixed, and and one
real mistake:
----------------------------------------------------------------------
In appendix B you say:
The ciphertext is also 16 octets long, so the construction
has no padding at all.
This is not true. The ciphertext was 13 bytes long (as can be seen
from the length), and there was 3 bytes of padding.
----------------------------------------------------------------------
Nits:
In section 2:
The same key and nonce, along with a block counter of zero are passed
to the ChaCha20 block function, and the top 256 bits of the result
are used as the Poly1305 key. The nonce passed to the block function
here is the same nonce that is used in ChaCha20, including the 32-bit
Salt, and the key passed is the same as the encryption key.
I think it is bit useless to first say that "The same key and nonce,
..." and then define that by the way the nonce is same and the key is
same ...
I would remove the second sentence, I think it is enough to say that
the same key and nonce are passed to block function.
--
In the draft you use "little-endian integer" and "network order
integer". I do not know what the order of the network is (most likely
it is messed up), but I assume you mean "integer in network byte
order" or something like that. You might want to talk about "byte
orders" in both cases.
Btw, I really hate to have system where we need to mix network byte
order and little-endia byte order stuff, but I think that is what cfrg
decided so better stick with that.
--
In section 2.1 you should expand ESN.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
