ZIP 316: Expand "Message Authentication Code", and a wording improvement.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-09-17 15:30:56 +01:00
parent 39998c226c
commit 96277a1a14
1 changed files with 7 additions and 7 deletions

View File

@ -714,15 +714,15 @@ require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state.
However, it is possible to reduce this by streaming the :math:`d` part of
the jumbled encoding three times from a less memory-constrained device. It
is essential that the streamed value of :math:`d` is the same on each pass,
which can be verified using a MAC (with key held only by the Consumer) or
collision-resistant hash function. After the first pass of :math:`d`, the
implementation is able to compute :math:`y;` after the second pass it is
able to compute :math:`a;` and the third allows it to compute and
incrementally parse :math:`b.` The maximum memory usage during this process
would be 128 bytes plus two BLAKE2b hash states.
which can be verified using a Message Authentication Code (with key held
only by the Consumer) or collision-resistant hash function. After the first
pass of :math:`d`, the implementation is able to compute :math:`y;` after
the second pass it is able to compute :math:`a;` and the third allows it to
compute and incrementally parse :math:`b.` The maximum memory usage during
this process would be 128 bytes plus two BLAKE2b hash states.
Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is
quite complicated, we do not require all Consumers to support it. If a
quite complicated, we do not require all Consumers to support streaming. If a
Consumer implementation cannot support UAs / UVKs up to the maximum length,
it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least
:math:`256` bytes. Note that this effectively defines two conformance levels