From 5e107a50440d04bc5f1e97ff121cd6fac5c5d525 Mon Sep 17 00:00:00 2001 From: Peter Date: Sat, 1 Apr 2023 02:04:13 -0600 Subject: [PATCH] PIT FALLIN --- docs/kek/README.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/docs/kek/README.md b/docs/kek/README.md index deb76f8..dcb14c3 100644 --- a/docs/kek/README.md +++ b/docs/kek/README.md @@ -137,14 +137,13 @@ algorithms is that they are all-or-nothing and are hard to decompose. Usually when your code doesn't work, you can do some trial and error to figure out which part of the code is wrong. Not so with hashing. -This requires a lot of context to explain, and it will make sense when you get -to the point in the document. This algorithm has state, which is a 1600-bit -bit array. And that state gets updated a lot. The updating procedure involves -a lot of `xor`ing this bit against that bit, and computing the parity of this -string of bits, etc. +This algorithm has state, which is a 1600-bit bit array called the "sponge". +And that state gets updated a lot. The updating procedure involves a lot of +`xor`ing this bit against that bit, and computing the parity of this string of +bits, etc. A lot of it involves crawling down the bit array one bit at a time, and xoring -the current bit against certain bits from *the original bit array*, and then +the current bit against certain bits from **the original bit array**, and then keeping a separate copy that has the modifications. The mistake I was making was as follows. Let's say that the update to bit 55 @@ -561,6 +560,10 @@ really_squeeze(WetSponge, OutputBitLength, BitRate, ResultAcc)-> This is the `f` function that you see in all the documentation. In inner keccak, the 1600-bit sponge is now thought of as a 5x5x64 3-dimensional array. +Go re-read the [Greek letter pitfall +section](#pitfall-greek-letter-steps-require-two-copies-of-the-sponge-to-compute) +before continuing. + ![NIST standard, page 11](./spongecoords.png) - The input is the 1600-bit sponge.