-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SHA3 and SHAKE - New API Design #2098
Changes from all commits
c6ed451
a05d255
50cf7fa
4b0b92e
eb992ea
d40fbec
adb910d
02b8085
e61be0d
3008821
2a1622f
c5d0afd
b6a5590
7ccaeba
7edb6c7
7386c1b
e424771
6597af1
7766425
ff3cbd8
680dd43
872d368
5780ee5
3f43dde
07bac7c
2973e4a
86fa4b0
36ab448
b2228b6
14da500
97b02c6
95c7e26
077ef78
b4ce7b2
5b18483
d3bba6b
f48fb78
6ce3a3b
72373f3
820394a
26544da
0239af3
2ddcd83
94bc599
6933d45
9462df8
9d433cb
705f36c
a03e160
507ff49
863387d
5a4dc9c
ebfb590
b80f99e
3001ac9
8d6b7f5
64f25eb
80260d9
2d90347
55742fa
c91bd6a
a66a1a5
7fb93e8
95a9e8a
0b9ef21
df51857
9d3b72b
3b18668
3cdcaa3
cb6f877
96f8169
7848023
1fdb30e
9c559df
0973fc2
2616442
85a0d6f
873f017
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -71,6 +71,16 @@ extern "C" { | |
// SHAKE128 has the maximum block size among the SHA3/SHAKE algorithms. | ||
#define SHA3_MAX_BLOCKSIZE SHAKE128_BLOCKSIZE | ||
|
||
// Define state flag values for Keccak-based functions | ||
#define KECCAK1600_STATE_ABSORB 0 | ||
// KECCAK1600_STATE_SQUEEZE is set when |SHAKE_Squeeze| is called. | ||
// It remains set while |SHAKE_Squeeze| is called repeatedly to output | ||
// chunks of the XOF output. | ||
#define KECCAK1600_STATE_SQUEEZE 1 | ||
// KECCAK1600_STATE_FINAL is set once |SHAKE_Final| is called | ||
// so that |SHAKE_Squeeze| cannot be called anymore. | ||
#define KECCAK1600_STATE_FINAL 2 | ||
|
||
typedef struct keccak_st KECCAK1600_CTX; | ||
|
||
// The data buffer should have at least the maximum number of | ||
|
@@ -82,7 +92,7 @@ struct keccak_st { | |
size_t buf_load; // used bytes in below buffer | ||
uint8_t buf[SHA3_MAX_BLOCKSIZE]; // should have at least the max data block size bytes | ||
uint8_t pad; // padding character | ||
uint8_t padded; // denotes if padding has been performed | ||
uint8_t state; // denotes the keccak phase (absorb, squeeze, final) | ||
}; | ||
|
||
// Define SHA{n}[_{variant}]_ASM if sha{n}_block_data_order[_{variant}] is | ||
|
@@ -396,32 +406,43 @@ OPENSSL_EXPORT uint8_t *SHAKE128(const uint8_t *data, const size_t in_len, | |
OPENSSL_EXPORT uint8_t *SHAKE256(const uint8_t *data, const size_t in_len, | ||
uint8_t *out, size_t out_len); | ||
|
||
// SHAKE_Init initializes |ctx| with specified |block_size|, returns 1 on | ||
// success and 0 on failure. Calls SHA3_Init under the hood. | ||
int SHAKE_Init(KECCAK1600_CTX *ctx, size_t block_size); | ||
|
||
// SHAKE_Final writes |len| bytes of finalized digest to |md|, returns 1 on | ||
// success and 0 on failure. Calls SHA3_Final under the hood. | ||
int SHAKE_Final(uint8_t *md, KECCAK1600_CTX *ctx, size_t len); | ||
|
||
// SHA3_Reset zeros the bitstate and the amount of processed input. | ||
void SHA3_Reset(KECCAK1600_CTX *ctx); | ||
|
||
// SHA3_Init initialises |ctx| fields and returns 1 on success and 0 on failure. | ||
// SHA3_Init initialises |ctx| fields through |FIPS202_Init| and | ||
// returns 1 on success and 0 on failure. | ||
OPENSSL_EXPORT int SHA3_Init(KECCAK1600_CTX *ctx, size_t bitlen); | ||
|
||
// SHA3_Update processes all data blocks that don't need pad through | ||
// |Keccak1600_Absorb| and returns 1 and 0 on failure. | ||
// SHA3_Update check |ctx| pointer and |len| value, calls |FIPS202_Update| | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it not do what it used to do: "processes all full blocks of the input data" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. SHA3_Update technically does the same: "processes all data blocks that don't need pad through". However, now it is performed via call to FIPS202_Update, which internally "processes all data blocks that don't need pad through". |
||
// and returns 1 on success and 0 on failure. | ||
int SHA3_Update(KECCAK1600_CTX *ctx, const void *data, size_t len); | ||
|
||
// SHA3_Final pads the last data block and processes it through |Keccak1600_Absorb|. | ||
// It processes the data through |Keccak1600_Squeeze| and returns 1 and 0 on failure. | ||
// SHA3_Final pads the last data block and absorbs it through |FIPS202_Finalize|. | ||
// It then calls |Keccak1600_Squeeze| and returns 1 on success | ||
// and 0 on failure. | ||
int SHA3_Final(uint8_t *md, KECCAK1600_CTX *ctx); | ||
|
||
// Keccak1600_Absorb processes the largest multiple of |r| out of |len| bytes and | ||
// returns the remaining number of bytes. | ||
// SHAKE_Init initialises |ctx| fields through |FIPS202_Init| and | ||
// returns 1 on success and 0 on failure. | ||
int SHAKE_Init(KECCAK1600_CTX *ctx, size_t block_size); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a historical reason why we chose to input bitlength to SHA3_Init and block_size to SHAKE_Init? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a good observation! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's fine to leave the bitlength in SHA3_Init because there isn't an equivalent function for SHA2 that we need to align with (e.g. using byte length). If we used bitlength with SHAKE_Init, it would identify 128 or 256. It's minor anyway and if it makes more sense to you this way, that's good. |
||
|
||
// SHAKE_Absorb checks |ctx| pointer and |len| values. It updates and absorbs | ||
// input blocks via |FIPS202_Update|. | ||
int SHAKE_Absorb(KECCAK1600_CTX *ctx, const void *data, | ||
size_t len); | ||
|
||
// SHAKE_Squeeze pads the last data block and absorbs it through | ||
// |FIPS202_Finalize| on first call. It writes |len| bytes of incremental | ||
// XOF output to |md| and returns 1 on success and 0 on failure. It can be | ||
// called multiple times. | ||
int SHAKE_Squeeze(uint8_t *md, KECCAK1600_CTX *ctx, size_t len); | ||
|
||
// SHAKE_Final writes |len| bytes of finalized extendible output to |md|, returns 1 on | ||
// success and 0 on failure. It should be called once to finalize absorb and | ||
// squeeze phases. Incremental XOF output should be generated via |SHAKE_Squeeze|. | ||
int SHAKE_Final(uint8_t *md, KECCAK1600_CTX *ctx, size_t len); | ||
|
||
// Keccak1600_Absorb processes the largest multiple of |r| (block size) out of | ||
// |len| bytes and returns the remaining number of bytes. | ||
size_t Keccak1600_Absorb(uint64_t A[KECCAK1600_ROWS][KECCAK1600_ROWS], | ||
const uint8_t *data, size_t len, size_t r); | ||
const uint8_t *data, size_t len, size_t r); | ||
|
||
// Keccak1600_Squeeze generates |out| value of |len| bytes (per call). It can be called | ||
// multiple times when used as eXtendable Output Function. |padded| indicates | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you like to put a comment here like
'''
// KECCAK1600_STATE_SQUEEZE is set when |SHAKE_Squeeze| is called.
// It remains set while |SHAKE_Squeeze| is called repeatedly to output chunks of the XOF output.
'''
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Nevine. Added!