feat(sha3): multi-block SHA3-256 absorb for H(ek); KeyGen golden vectors
Stage 0+1 of mlkem_top KeyGen integration: - sha3_top: add multi-block SHA3-256 absorb FSM (mb_en/mb_block_i/mb_valid_i/ mb_last_i/mb_ready_o). Caller pre-pads final block; module does pure absorb loop (state^=block; Keccak-p). Single-block G/H/J paths bit-identical when mb_en=0. Sticky digest register holds output until consumer acks. - tb_sha3_mb_xsim: self-checking TB streams 800B ek (6 blocks) -> H(ek), verified == hashlib.sha3_256. Proper valid/ready handshake (no force). - Existing G/H/J TBs (xsim + Verilator) tie off mb_* ports; both frameworks regress clean (Verilator 25/25, XSIM G/H/J + keccak + 7-vec + multiblock). - test_framework/modules/mlkem_keygen/golden: full 256-coeff per-stage intermediates (rho/sigma, A_hat, s/e, s_hat/e_hat, t_hat, ek, dk_pke) for KAT count=0..4, dumped by ml-kem-r and self-verified against NIST KAT.
This commit is contained in:
1
test_framework/modules/mlkem_keygen/golden/c004_ek.hex
Normal file
1
test_framework/modules/mlkem_keygen/golden/c004_ek.hex
Normal file
@@ -0,0 +1 @@
|
||||
a1dc74332994bc2899c85b59a4d43d2ef08f5c1aa67a4872c4c355d3664f08699a8ae85f17d74450b628c5f31bde384721d73acb51abcfb361d850184d925e013a0a83529535c9b262c7c48f81b95e693e242878d0168902c41c14a8a3d560cd31044b7e4659c1c9cb4c18593197609155594a088b9a827bc4732846aac353fa8cffa486a0d84d368314e65917f7398c6bd12f223700b17b883bebbdf12c1a42e89c958553d0686cf7683caf71243727afe2249b00972587335f6b0052cd2177800a4fa1225725e08b9551cda1e45ba6e3cdbb71730cb72a1f1c6cf1bc58520c9e52203c68951c2798523c2038ba6801fb3c321cf5ca218c680c320b3446ab153a3c4cd7cbca356b58d254b6a24a672258d1a8bd36a81be97b515eb42122f32a7d397b2fcb039946c38e41b5b4c5764c6c50c290a405aa746c527c51358bc09c5b52da33a0946c9d8a2f0da3ba7a24913d83b4d909913e2c55bfb5020f6c87688271e01788889c97b12ab88905b49a6c02d3400b7a6172fbb106c016c85cc7073fa788a8e37ff2a2a77d664aa1a6a0cbc9342e684954957651462cb2db7402c65a2ec98d58441e57166c664a8a753a69987b1930959097e988c7da31942462c83628a81bcef6d42880f6039808c727bccc6d20443956b2a2d48f58a8797297cfe8e32901d468f8054af658c7b3b7ced292c3866407c1a77959681c25b46c345571637919448036335723c17b5226074159219f479b2553864c6653a0bc74b0a152160bf88b50565a47b54a97094755a0c17c8566cd922ad49b54ad75c5bd50016a509d7eca819b36110c93ae0ea47ae46acbc4627115600cb12365d1e6a9424131834c4c4c72442d1a7c8eb7351b277be60b70ec170111a38a3ce0944e242cea26c4cb80c433653045a7bf4d9a6f0906306c0059f42b512895c2ef744db5a7720ad0353a667d43c4419e6148441880f788a78bd94719f010d14224dfc068a1c6c6b4608e8b840d7a6268bff383b7001be6e66fbfe774da4b9c9a01c5c62c55308196a6b72204b50ae39225c31a8aacc59be09ba033f43d35813582b28eaa839c70619814949f768e114b01b84b8787794582f8cd7f6fb07381770ebba5031cc5
|
||||
Reference in New Issue
Block a user