-
Notifications
You must be signed in to change notification settings - Fork 792
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
[kmac] Improve PRNG implementation #20828
Comments
Thanks for filing the issue @msfschaffner . I am currently working on this. The task can be broken down into the following steps:
|
Update: I've done the switch of the PRNG implementation and also the DV integration is mostly done. The FPGA evaluation is tricky and ongoing. |
I've now updated the total effort to also include the DV / full security verification effort. |
Update, I've also investigated the area and timing impact of the change using the Yosys + nangate45 synthesis flow. The situation is as follows:
The bottom line is that the critical path increases and is now inside the PRNG itself (because it's heavily unrolled - we generate 800 bits per clock cycle) but it's still very far away from the critical path of other IP cores and the whole chip. From an area perspective, Bivium would be 10 kGE smaller than Trivium. But since KMAC processes sensitive key material for keymgr we should probably go for Trivium to be on the safe side. From a SCA perspective, PROLEAD suggests that anything with the reworked core and the added buffer stage is slightly better than the baseline but there are no big differences. I am now working on the the FPGA experiments. |
This commit switches the LFSR-based PRNG with an unrolled, Trivium-based PRNG implementation to avoid brute-forcing attacks on the LFSR states. The overall PRNG state decreases from 800 bits to 288 bits but due to the heavy unrolling, the primitive can still generate 800 bits per cycle as required by the masked SHA3 core. This resolves lowRISC#20828. Signed-off-by: Pirmin Vogel <[email protected]>
The DV work is now done and I also got the FPGA results for SHA3. It looks fantastic from an SCA perspective. KMAC mode experiments are currently running and I'll feed back once I have those results. The PR to integrate Trivium is here: #21624 @johngt the work for this is now done. I'll guess it will take some time for people to read through the PR and digest it. I'll answer questions of course but my main focus is now on other pressing issues FYI. |
This commit switches the LFSR-based PRNG with an unrolled, Trivium-based PRNG implementation to avoid brute-forcing attacks on the LFSR states. The overall PRNG state decreases from 800 bits to 288 bits but due to the heavy unrolling, the primitive can still generate 800 bits per cycle as required by the masked SHA3 core. This resolves lowRISC#20828. Signed-off-by: Pirmin Vogel <[email protected]>
This commit switches the LFSR-based PRNG with an unrolled, Trivium-based PRNG implementation to avoid brute-forcing attacks on the LFSR states. The overall PRNG state decreases from 800 bits to 288 bits but due to the heavy unrolling, the primitive can still generate 800 bits per cycle as required by the masked SHA3 core. This resolves lowRISC#20828. Signed-off-by: Pirmin Vogel <[email protected]>
This commit switches the LFSR-based PRNG with an unrolled, Trivium-based PRNG implementation to avoid brute-forcing attacks on the LFSR states. The overall PRNG state decreases from 800 bits to 288 bits but due to the heavy unrolling, the primitive can still generate 800 bits per cycle as required by the masked SHA3 core. This resolves lowRISC#20828. Signed-off-by: Pirmin Vogel <[email protected]>
This commit switches the LFSR-based PRNG with an unrolled, Trivium-based PRNG implementation to avoid brute-forcing attacks on the LFSR states. The overall PRNG state decreases from 800 bits to 288 bits but due to the heavy unrolling, the primitive can still generate 800 bits per cycle as required by the masked SHA3 core. This resolves #20828. Signed-off-by: Pirmin Vogel <[email protected]>
Description
This is a sibling issue to #19091.
A similar PRNG improvement for KMAC should be evaluated.
The text was updated successfully, but these errors were encountered: