Skip to content
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

[ecdsa-sca] Enable ECDSA-256 secret shares for capture #109

Merged
merged 1 commit into from
Jan 19, 2023

Conversation

bilgiday
Copy link
Contributor

@bilgiday bilgiday commented Dec 20, 2022

Enable sending of all secret shares (k0, k1, d0, d1) from the Python code (capture.py).

Signed-off-by: Bilgiday Yuce bilgiday@opentitan.org

@bilgiday
Copy link
Contributor Author

bilgiday commented Dec 20, 2022

./capture.py --cfg-file capture_ecdsa_cw310.yaml capture ecdsa-simple --num-traces 2 --plot-traces 1 can be used to run the experiments locally.

The C counterpart is here: opentitan-pr16899.

cw/capture.py Show resolved Hide resolved
cw/capture.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@vogelpi vogelpi left a comment

Choose a reason for hiding this comment

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

Thanks @bilgiday for working on this. I've left a few comments and also have some questions.

Please move all the binaries related to ECDSA captures (bitstreams + target binaries) to Git LFS. We should have done this right from the beginning but it seems I wasn't fast enough in reviewing your last/initial ECDSA PR. For this, you'll have to add entries for these binaries in .gitattributes in the top directory of the repo.

cw/capture_ecdsa_cw310.yaml Outdated Show resolved Hide resolved
cw/capture_ecdsa_cw310.yaml Show resolved Hide resolved
cw/capture.py Outdated Show resolved Hide resolved
cw/capture.py Outdated Show resolved Hide resolved
cw/capture.py Outdated Show resolved Hide resolved
cw/capture.py Outdated Show resolved Hide resolved
cw/capture.py Show resolved Hide resolved
@m-temp
Copy link
Collaborator

m-temp commented Dec 23, 2022

Please move all the binaries related to ECDSA captures (bitstreams + target binaries) to Git LFS. We should have done this right from the beginning but it seems I wasn't fast enough in reviewing your last/initial ECDSA PR. For this, you'll have to add entries for these binaries in .gitattributes in the top directory of the repo.

@vogelpi should we add wildcards to the .gitattributes? Is there any reason why we might not want to have a .bin or .bit file in the lfs but rather in the normal git? I'm asking because I also messed this up a couple of times in the past....

Comment on lines +9 to +10
cw/objs/ecc_serial_fpga_cw310.bin filter=lfs diff=lfs merge=lfs -text
cw/objs/ecc384_serial_fpga_cw310.bin filter=lfs diff=lfs merge=lfs -text
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think just declaring these files in the .gitattributes here is enough. As you can see further below in the diff, Git still thinks you've pushed new binary files. You probably have to first delete the files using git rm, then add them to Git LFS and last but not least squash the commits into one. For reference this is how the diff should look like: https://github.com/lowRISC/ot-sca/pull/4/files

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the detailed steps. I updated the files by following these instructions.

# https://github.com/lowRISC/ot-sca/issues/106#issuecomment-1359530023
# https://rtfm.newae.com/Capture/ChipWhisperer-Husky/#streaming-mode
# A diagram showing the clocking structure for optentitan CW310:
# http://drawings/1oVABuYbeXq5lwneQMZ49D5MBFfBJoSxz6V1A17j4XDo
Copy link
Collaborator

Choose a reason for hiding this comment

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

This link doesn't work. What you can do is include it in this PR as .png and then link to that. On the other hand, you don't really refer to this in the file or explain what is meant. So I think it's fine to skip this link in the source file. But it would be worth to add it to the PR for discussion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed the link from the source code. Added it to PR (doc/img) for discussion and future reference.

# Target operating frequency
pll_frequency: 22000000
# Target operating frequency:
# for ecdsa-simple: 25-50MHz (alignment issues above 66MHZ)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: 66MHZ -> 66MHz

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed.

cw/capture_ecdsa_cw310.yaml Outdated Show resolved Hide resolved
Copy link
Collaborator

@vogelpi vogelpi left a comment

Choose a reason for hiding this comment

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

Thanks for implementing the suggested changes, this looks mostly good now.

What I would like to happen before we merge this:

  • @vrozic was planning to also try out the PR on the FPGA
  • There still seems to be an issue with Git LFS, I left a more detailed comment.
  • It would be good if also @m-temp could have a look at the PR because he will also build on top of this work.

I am not hitting "request changes" because I don't want to block progress (OoO tomorrow) but please make sure to the points above are addressed before merging this.

cw/capture_ecdsa_cw310.yaml Show resolved Hide resolved
@vogelpi
Copy link
Collaborator

vogelpi commented Jan 17, 2023

Please move all the binaries related to ECDSA captures (bitstreams + target binaries) to Git LFS. We should have done this right from the beginning but it seems I wasn't fast enough in reviewing your last/initial ECDSA PR. For this, you'll have to add entries for these binaries in .gitattributes in the top directory of the repo.

@vogelpi should we add wildcards to the .gitattributes? Is there any reason why we might not want to have a .bin or .bit file in the lfs but rather in the normal git? I'm asking because I also messed this up a couple of times in the past....

Good point @m-temp , I don't see a reason for not putting such files into LFS. I just wasn't aware this was possible. Would you mind giving this a try as a follow-up for this PR?

@vogelpi vogelpi requested review from m-temp and vrozic January 17, 2023 17:37
@vogelpi
Copy link
Collaborator

vogelpi commented Jan 17, 2023

Ah, and you'll need to rebase this PR on top of master for CI to pass. There was a Python-related issue I had to fix.

@bilgiday
Copy link
Contributor Author

Thanks for implementing the suggested changes, this looks mostly good now.

What I would like to happen before we merge this:

  • @vrozic was planning to also try out the PR on the FPGA
  • There still seems to be an issue with Git LFS, I left a more detailed comment.
  • It would be good if also @m-temp could have a look at the PR because he will also build on top of this work.

I am not hitting "request changes" because I don't want to block progress (OoO tomorrow) but please make sure to the points above are addressed before merging this.

Thanks for the comments @vogelpi. I will fix the Git LFS issue :)

@bilgiday
Copy link
Contributor Author

Ah, and you'll need to rebase this PR on top of master for CI to pass. There was a Python-related issue I had to fix.

Thanks for fixing it. I will rebase before pushing the next version.

@bilgiday bilgiday force-pushed the update-ecdsa-256 branch 2 times, most recently from 2a9a026 to 8fec21a Compare January 17, 2023 19:53
@m-temp
Copy link
Collaborator

m-temp commented Jan 18, 2023

Good point @m-temp , I don't see a reason for not putting such files into LFS. I just wasn't aware this was possible. Would you mind giving this a try as a follow-up for this PR?

Will do so in #111

Copy link
Collaborator

@m-temp m-temp left a comment

Choose a reason for hiding this comment

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

LGTM. I've added a few comments that could improve understanding the code in the future. Would be nice to have to address these.

cw/capture.py Outdated
Comment on lines 1263 to 1271
# Currently, we need to reprogram the firmware before every sign operation
# TODO: Investigate the C code (ecc384_serial) to check if we can run multiple
# signing operations without reloading the firmware.
reset_firmware = True
reset_firmware = False
Copy link
Collaborator

Choose a reason for hiding this comment

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

The comment says we need to reprogram, but reset_firmware = False. Could you explain what's the actual TODO? Is this only a TODO for 384 and set to false for 256?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks Michael! It seems that I forgot to update these comments.

At the beginning of the project, there was an issue in the C code, and we needed to reflash the firmware for each signing operation. Now, that problem has been solved and we don't need to reflash the firmware again and again.

I just wanted to keep this reflashing option there in case we need it in the future. I updated the comments accordingly to reflect the current state.

cw/capture.py Outdated
# Combine the two shares of d and k
priv_key_d = priv_key_d0 + priv_key_d1
secret_k = secret_k0 + secret_k1

# Create an arrey to keep the traces
waves = np.array([])
# Currently, we have to reload the firmware to be able to send a
Copy link
Collaborator

@m-temp m-temp Jan 18, 2023

Choose a reason for hiding this comment

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

Although this is not port of the current PR could you add a comment, when this branch/condition needs to be taken? See also comment above, where reset_firmware is set

edit: Hmm there's something wrong with the associated lines. This part belongs tho the reset_firmeware part.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you, I updated the reset_firmware related comments.

cw/capture.py Show resolved Hide resolved
Copy link
Contributor

@vrozic vrozic left a comment

Choose a reason for hiding this comment

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

This works well on my setup for 256b version.
Capture rates: ~2.5s per trace (simple mode) and 1.5s per trace (stream mode). I assume these are the expected values.

Thanks for the great work @bilgiday

- Enables sending of all secret shares (k0, k1, d0, d1) from the Python
code (capture.py).

- Enables the trace collection without needing to reflash the firmware
  at every iteration.

Signed-off-by: Bilgiday Yuce <bilgiday@opentitan.org>
@bilgiday
Copy link
Contributor Author

This works well on my setup for 256b version. Capture rates: ~2.5s per trace (simple mode) and 1.5s per trace (stream mode). I assume these are the expected values.

Thanks for the great work @bilgiday

This works well on my setup for 256b version. Capture rates: ~2.5s per trace (simple mode) and 1.5s per trace (stream mode). I assume these are the expected values.

Thanks for the great work @bilgiday

Thanks for testing it @vrozic, the capture rates seems right to me.

@bilgiday bilgiday requested a review from m-temp January 18, 2023 14:28
Copy link
Collaborator

@m-temp m-temp left a comment

Choose a reason for hiding this comment

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

Thanks @bilgiday for your work and addressing/clarifying the issues!
LGTM

@bilgiday
Copy link
Contributor Author

It seems everyone is happy with the current status of the PR. I am merging this PR not to block the others.

On the opentitan side, lowRISC/opentitan#16899, I am still waiting for one last nod to go.

@bilgiday bilgiday merged commit ef01775 into lowRISC:master Jan 19, 2023
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

4 participants