Suggestion: SHAKE128 and SHAKE256

[adon-at-work]

Will you consider supporting those XOF functions including SHAKE128 and SHAKE256?

As I observed, the quick hack is to use a special padding: [0x1F, 0x1F00, 0x1F0000, 0x1F000000], and the first b * 2 bits out of the states seems to be good enough. Making it fully compatible with the standard is a little bit harder though.

Thoughts? :)

Reference: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf See Section 6.2 in p.20

I'd like to also thank for publishing your library. :+1:

[adon-at-work]

FYI

I tried keccak([], 256, [0x1F, 0x1F00, 0x1F0000, 0x1F000000]); and dumped all the states as output (modifying n to become 50).

As on might expect, only the first 1088 bits (i.e., 1600 - 256 * 2) match those given test vectors. https://raw.githubusercontent.com/gvanas/KeccakCodePackage/master/TestVectors/ShortMsgKAT_SHAKE256.txt

[emn178]

Hi,

I added shake methods. You can use like this shake_128(..., 256) or shake_256(..., 512) Please try it.

[adon-at-work]

Kudos! @emn178. I checked your latest implementation. Thanks very much for the library. :+1:

I also love to share with you the particular PR, where we used your library at the yahoo/end-to-end project. I took largely the core part of your implementation, in which it has almost no change across your latest and last version. We plan to acknowledge your work in a copyright file when it finally gets adopted.

tl;dr

After a few iterations, the concerns/needs are a little bit different than what I initially proposed perhaps a week ago.

1. We finally settled with using Array<number> as the input/output format, as to align with other crypto libraries. We sort of worried about compatibility issues when we extend the tool to older browsers, and thus have avoided doing any ArrayBuffer() and UintXArray() operations at the core (the performance of using such are apparently insignificant).
2. We see the need of having an interface to do hash.update(inputA).update(inputB).digest(). This is similar to that of https://closure-library.googlecode.com/git-history/docs/class_goog_crypt_Sha512.html. Without such, there's a little more overhead to concat the data first before hashing it as in hash(inputA.concat(inputB)). This is not critical enough yet, but we may deal with it in the future.
3. We also added an assertion over the output length, as a temp mitigation to the mentioned problem. It was "fortunate" that we now didn't require any hashed output of length longer than 512 bits. I tried your sha3.shake_256('', 1088) and sha3.shake_256('', 1600). While the former is correct, the latter starts to mismatch with the authentic answer beginning from the 1088-th bits. FYI, the authentic hex dump of "shaking256" empty (copied from https://raw.githubusercontent.com/gvanas/KeccakCodePackage/master/TestVectors/ShortMsgKAT_SHAKE256.txt, particularly line 4): 46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762fd75dc4ddd8c0f200cb05019d67b592f6fc821c49479ab48640292eacb3b7c4be141e96616fb13957692cc7edd0b45ae3dc07223c8e92937bef84bc0eab862853349ec75546f58fb7c2775c38462c5010d846c185c15111e595522a6bcd16cf86f3d122109e3b1fdd 943B6AEC468A2D621A7C06C6A957C62B54DAFC3BE87567D677231395F6147293B68CEAB7A9E0C58D864E8EFDE4E1B9A46CBE854713672F5CAAAE314ED9083DAB4B099F8E300F01B8650F1F4B1D8FCF3F3CB53FB8E9EB2EA203BDC970F50AE55428A91F7F53AC266B28419C3778A15FD248D339EDE785FB7F5A1AAA96D313EACC890936C173CDCD0FAB882C45755FEB3AED96D477FF96390BF9A66D1368B208E21F7C10D04A3DBD4E360633E5DB4B602601C14CEA737DB3DCF722632CC77851CBDDE2AAF0A33A07B373445DF490CC8FC1E4160FF118378F11F0477DE055A81A9EDA57A4A2CFB0C83929D310912F729EC6CFA36C6AC6A75837143045D791CC85EFF5B21932F23861BCF23A52B5DA67EAF7BAAE0F5FB1369DB78F3AC45F8C4AC5671D85735CDDDB09D2B1E34A1FC066FF4A162CB263D6541274AE2FCC865F618ABE27C124CD8B074CCD516301B91875824D09958F341EF274BDAB0BAE316339894304E35877B0C28A9B1FD166C796B9CC258A064A8F57E27F2A

[emn178]

1. I will add int array output in next version.
2. I need time to think how to design this feature and keep simple usage and performance.
3. Can you tell me how to read the test vector file or provide test cases?

[adon-at-work]

1. Sure. Thanks. It involves just a few lines of code, and you may like to just clone our implementation.
2. Agree. Not urgent.
3. In the sample file, you may want to handle only those samples of length being a multiple of 8 bits. FYI, the test file is generated using genKAT.c, and that the residues (those of length % 8 !== 0) are handled in KeccakHash.c

[emn178]

thanks for help, shake problem should be fixed in v0.4.1

[adon-at-work]

gd. thanks.

2. For your reference: https://github.com/golang/crypto/blob/master/sha3/sha3.go

[emn178]

Hi, Added update feature in v0.5.0, please try it.

[adon-at-work]

FYI, it's being included in https://github.com/yahoo/end-to-end/commit/88e0514376a2c2d565df7a7f112410ccdb787728 The changes are merged into the master branch too. @emn178, really thanks for this great library.