Skip to content

[aes/doc] Document Galois/Counter Mode (GCM) implementation + hardening #31

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

Merged
merged 1 commit into from
Mar 6, 2025

Conversation

vogelpi
Copy link
Owner

@vogelpi vogelpi commented Mar 6, 2025

No description provided.

@vogelpi vogelpi requested a review from nasahlpa March 6, 2025 14:54
@vogelpi
Copy link
Owner Author

vogelpi commented Mar 6, 2025

@nasahlpa would you mind taking a look at this please? I need this to link the SCA hardening evaluation against.

You can generate the full documentation using ./util/site/build-docs.sh serve.

Internally, this configures the AES block in ECB mode.
After configuring the encryption key, software writes the 96-bit IV to the IV registers [`IV_0`](registers.md#iv) - [`IV_2`](registers.md#iv) and `0` to IV register [`IV_3`](registers.md#iv).
The hardware will then perform two operations:
1. It encrypts the all-zero vector and stores the result in the hash subkey `H` registers internal to the GHASH module and increment the counter value (content of the IV Registers) using the inc32 function.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
1. It encrypts the all-zero vector and stores the result in the hash subkey `H` registers internal to the GHASH module and increment the counter value (content of the IV Registers) using the inc32 function.
1. It encrypts the all-zero vector and stores the result in the hash subkey `H` registers internal to the GHASH module and increments the counter value (content of the IV Registers) using the inc32 function.

To see if the AES unit is ready to accept the next block, software can query the [`STATUS.INPUT_READY`](registers.md#status) bit.

For the last block and in case the block is not full, software first waits for the AES unit to become idle by querying the [`STATUS.IDLE`](registers.md#status) bit, and then sets the [`CTRL_GCM_SHADOWED.NUM_VALID_BYTES`](registers.md#ctrl_gcm_shadowed) field to the number of valid bytes.
For all other blocks, software sets this field to the value `16`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last sentence is a bit confusing to me. For all other blocks between the first and last software does not do anything? Do you mean: All blocks just must be 16 bytes? Then we can maybe say. The block size of blocks between the first and last block must be 16 bytes.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that's resolved now.


1. Software needs to wait for the AES unit to become idle (see [`STATUS.IDLE`](registers.md#status)).

1. Software configures the [`CTRL_GCM_SHADOWED.PHASE`](registers.md#ctrl_gcm_shadowed) to `GCM_TAG` and the `NUM_VALID_BYTES` field to `16`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure that this should be GCM_TAG and not GCM_SAVE?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!


There are two parallel paths, each featuring their own Galois Field GF(2^128) multiplier to separate the processing of the two shares H<sub>0</sub> and H<sub>1</sub> of the hash subkey H to prevent SPA on the multiplication.
Using two separate multipliers allows to prevent unmasking H at any point during the execution, incl. e.g., due to accidental leakage occurring due to multiplexing H<sub>0</sub> and H<sub>1</sub>.
The multipliers are implemented in a serial-parallel fashion to trade of area vs. performance.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The multipliers are implemented in a serial-parallel fashion to trade of area vs. performance.
The multipliers are implemented in a serial-parallel fashion to trade off area vs. performance.

@vogelpi vogelpi force-pushed the aes-gcm-spec branch 2 times, most recently from 3dbf79a to 601fbd1 Compare March 6, 2025 16:51
Signed-off-by: Pirmin Vogel <[email protected]>
@vogelpi vogelpi merged commit 82b4600 into aes-gcm-review Mar 6, 2025
12 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants