Рейтинг:1

xChaCha20 Block Keys for Poly1305

флаг cn

So xChaCha20 has a nonce size large enough to safely use a random nonce with the same key. Poly1305 generally uses the first block of the cipher's output to generate its nonce. For xChaCha20 it would be the block zero for poly1305 key/nonce and the rest of the data would be encrypted with block 1 and up. So if one were to send a message you would get something along these lines (order may be different depending on the protocol):

$$\text{Msg} = \{ \text{Poly1305 Tag}\} \mathbin\| \{\text{24 Bytes Nonce} \} \mathbin\| \{ \text{Associated Data} \}\mathbin\| \{\text{Cipher Text} \}$$

Now with this layout, it seems a bit wasteful sending and generating new nonce with every message i.g. 24 bytes packet/message overhead, and CPU time generating random nonces. Especially since xChaCha20 can send $2^{64}$ blocks with one key and nonce pair. One could just send the nonce once and then start sending their stream of data and on the last message send the poly1305 tag. However, if it was a lot of data having to wait for all of it to be sent before verifying the poly1305 tag has its own host of problems. It seems more practical to generate Poly1305 tags as you go.

However, pretty much all constructions I see only use block 0 for the Poly1305 key/nonce it seems perfectly reasonable to me to use other block counters for the Poly1305 key. For instance, let's say someone wants to send a long stream of data. For illustrative purposes lets consider some rough construction that sends 7 xChaCha20 blocks at a time:

Example construction

Now, my question is why have I not seen a construction along these lines? Is there something I am overlooking, or is xChaCha20 just too new or this is a rather niche concern, or was I not looking hard enough? Since some construction along these lines allows one to verify data as they receive it and also avoids generating many new nonces and having to repeatedly send them adding message overhead.

Edit: Probably should have been more clear here poly1305_tag(block_x) is supposed to include both ciphertext and associated data. The image above was kinda already getting kinda wide for something like

$$poly1305_{tag}(block_x, \text{associated data} \mathbin\| ciphertext).$$

Similar as mentioned in the note below that xChaCha20_x() includes the key and nonce. Mainly this is question is about using other block counters other than zero to be a key for poly1305 to generate multiple tags for a longer data stream.

kelalaka avatar
флаг in
Связанные данные должны быть аутентифицированы. У вас есть проблема [похожая на эту] (https://crypto.stackexchange.com/q/86080/18298).
флаг cn
Возможно, я недостаточно ясно выразился, связанные данные проходят через poly1305, по крайней мере, это было моим намерением при описании этого. В противном случае, конечно, можно было бы манипулировать. Я говорил выше, что работает poly1305 с номером блока x в качестве ключа poly1305.
флаг cn
Также нет, это больше об использовании различных блоков для ключевого тега аутентификации poly1305 по пути. Когда я смотрю на реализации, они просто используют блок 0 chacha20. Я не вижу причин, по которым использование других блоков, выводимых из chacha20/xchacha20, может вызвать проблему, поскольку poly1305 будет продолжать получать уникальные входные данные. Это затем вы можете использовать для создания тега для аутентификации зашифрованного текста и любых связанных данных. В основном такая же конструкция, как и то, что вы обычно делаете для block_0, а затем шифруете block_1 до block_n, но вместо этого вы используете несколько блоков из xchacha20 для нескольких тегов poly1305.
kelalaka avatar
флаг in
Вы можете отредактировать свой вопрос, уточнив, в частности, свою цель. Дьявол кроется в деталях.
флаг cn
Добавлено редактирование, обобщающее то, что я сказал здесь.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.