zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

ZIP 316: Clarify a security requirement for streamed calculation of F4Jumble^-1. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-09-17 13:44:03 +01:00
parent 6611f7a245
commit cf0219cd67
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
zip-0316.rst
View File

@ -636,12 +636,15 @@ at :math:`\ell_M = 4194368` bytes.
A naïve implementation of the :math:`F4Jumble^{-1}` function would 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 from a less memory-constrained device. 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 (for the cached :math:`c` or :math:`y`), plus two
BLAKE2b hash states.
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 (for the cached :math:`c` or :math:`y`), plus two BLAKE2b
hash states.
Since this streaming implementation of :math:`F4Jumble^{-1}` is quite
complicated, we do not require all Consumers to support it. If a Consumer