> On Apr 27, 2015, at 6:25 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote:
>
>
> 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”?
Yeah, perhaps I didn’t phrase it the best way. If you’re using AES and you have
a 19-byte plaintext and you’re using ECB (or CBC) you can encrypt the first
16-byte block of the plaintext, but for the second block you only have 3 bytes,
whereas AES requires 16. So you need to pad. With CTR, CCM, GCM you encrypt a
counter, which is always 16 bytes, Since you’re not applying AES to the
plaintext (but to a counter) you don’t need to pad the plaintext - you just
throw away the extra bytes of XOR mask that you created.
ChaCha20 is the same: you generate a 64-byte block from a key, a nonce and a
counter, and you XOR as much of it as you need with the plaintext - so no pad
is needed.
>> 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.
It’s not that different from AES-GCM. With AES-GCM (or just CTR) you have a
128-bit counter (actually it’s just a 32-bit counter as 96-bits are the
per-packet nonce). You encrypt the counter and get a 16-byte block that you XOR
with the plaintext.
With ChaCha20-Poly1305 you also have a 128-bit counter with 96 fixed bits. You
run the ChaCha20 block function to generate a 64-byte block that you XOR with
the plaintext.
The only difference is that the size of the counter is not the same as the size
of the output block.
This is different from a real stream cipher where a single key with no nonce
can generate an arbitrary length byte stream. ChaCha20 can only produce 64
bytes from a single value of the nonce.
> 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.”
That’s kind of a weird thing to write. We don’t allocate an ICMPv6 type number
either. It’s kind of sad because while Poly1305 is not a good PRF, ChaCha20 is.
But unfortunately it’s not a good PRF for IKEv2 as it requires a constant-size
key, and RFC 7296 requires that all PRFs support any size key. Of course we
could add the blake2 hash function to convert any non-256-bit key to a 256-bit
key, and blake2 is based on the ChaCha20 block function. But we chose not to
do this. At least not yet.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
