I read draft-ietf-ipsecme-chacha20-poly1305 on Friday last, and then found that I needed to further review draft-nir-cfrg-chacha20-poly1305-06 to better understand the questions in para 2 of the security considerations, the question about the uniqueness the nonce, so my initial reading, being mostly ignorant about ChaCha and Poly1305 was very confusing.
(In preparing this email, I was also using the -05 document, which I see is
new. I think that I read -03 on Friday. -04 seems to have been skipped?)
I had not yet read any of the discussion on the list (intentionally) so as
to judge whether I understood the document on it's own.
{in preparing this email, I read the thread afterwards, and I now see that
some discussion was previously about IV being derived from replay counter, a
notion which I think has been removed from the ID. I don't think that I have
any new questions; I think that after having read the document well, that
I can implement from the documents as they are}
I don't understand:
> As the ChaCha20 block function is not applied directly to the
> plaintext, no padding should be necessary. However, in keeping with
could this be a typo ChaCha20 vs Poly1305?
If the encryption algorithm is now applied directly, then what is?
Or is meant that the block function for ChaCha20 used only to generate
bits for a stream cipher, and the XOR is what is "applied directly"?
> 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 that if I have a block encryption function, that I need to encrypt
something to get an output. I don't know what that is here....
Later I understood from reading cfrg-chacha20 that the ChaCha20 block
function acts as a prng, and that's why this is a stream ciper, not a block
cipher. The use of the term "block function" here was confusing to me.
At first, I understand the nonce, was going to be the IV. Was there some
discussion/options in a previous version of the draft?
I initially understood that the the 32-bit block counter would be taken from
the replay counter, but now I see that this is incorrect, that it's unrelated
to the replay counter, and that I misunderstood at first.
So the Salt is really part of the key material. We have a 36-byte key. It
matters to people debugging things with a tool like TCPDUMP, that they know they
should expect 36-bytes.
Is this diagram correct:
keymat: iv: ctr:
+-----------------------+----+ +--------+ +----+
|01234567890123456789012|0123| |abcdefgh| |0001|
+-----------------------+----+ +--------+ +----+
| | | |
| | | |
| | | |
key: V nonce: V block V
+-----------------------+ +------------+ ctr:+----+
|01234567890123456789012| |0123abcdefgh| |00xx|
+-----------------------+ +------------+ +----+
words: 4-11 words: 13-15 word 12
\-----\ /------------\ /-----------------------------/
\/ \ /
| ctr=0 \/ 64-byte chunks prng
| ||
| |^^xor^ --< plaintext+padding+NH
| replay# ||
| spi# +----------+
| | | cipher |
| | /--<--| text |
| | | +----------+
| | | |
| | | |
V V V |
/----------\ |
| Poly1305 | |
| algo | |
\----------/ |
V V
+----+
|MIC |
+----+
I am very very very happy that cfrg-chacha20 has so many examples in it.
That's really awesome.
It wasn't until I read all of cfrg-chacha20 that I understood that the
Poly1305 needs to seeded for *each* packet. I also think that the Poly1305
is not used in an HMAC construction.
I think that the IANA considerations of ipsecme-chacha20-poly1305 should say
something like,
"According to cfrg-chacha20, Poly-1305 is not suitable for
use as a PRF for IKEv2, and this specification explicitely
does not allocate a code point for that."
=====
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
