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.

Sign up for GitHub

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

Jump to bottom

xperm.* variations. #44

Closed
ben-marshall opened this issue Sep 3, 2020 · 3 comments
Closed

xperm.* variations. #44

ben-marshall opened this issue Sep 3, 2020 · 3 comments
Labels
question Further information is requested

Comments

@ben-marshall
Copy link
Member

Context:

  • Originally, the scalar crypto spec included a lut4 instruction, which did nibble-wise lookups on values in registers and is very useful for small SBoxes or permutations.
  • This instruction was deemed more generally useful than Crypto, so the Bitmanip TG took ownership of it.
    • They changed the name to xperm, and added byte and halfword variants as well.
  • When I updated the crypto spec to point at the Bitmanip spec, I accidentally included the extra byte and halfword variants without thinking.

Action:

  • I've removed the extra variants from the spec on the dev/next-release branch for now.
  • If we decide to keep them, I'll add them back to the spec. Otherwise they can be left out. This leaves the spec as it should have been when the Bitmanip TG first took ownership of the instruction.
@ben-marshall ben-marshall added the question Further information is requested label Sep 3, 2020
ben-marshall added a commit that referenced this issue Sep 3, 2020
@ben-marshall
spec: Fix xperm.* inclusion mistake.
ab53122 
- Originally, the crypto spec only contained the nibble-wise versions
  of xperm - when it was called LUT4, before bitmanip TG took ownership.

- When it moved to Bitmanip, I included the byte and halfword versions of
  the instruction in the crypto TG spec, and they shouldn't have been
  without some more work to determine if they are useful.

- *if* they are useful, they can be added back in.

- See #44

 On branch dev/next-release
 Your branch is up-to-date with 'origin/dev/next-release'.

 Changes to be committed:
	modified:   doc/tex/sec-scalar-bitmanip.tex

 Changes not staged for commit:
	modified:   extern/riscv-gnu-toolchain (modified content)
	modified:   extern/riscv-isa-sim (modified content)
@grnewell
Copy link

grnewell commented Sep 4, 2020

If I understand correctly, the byte variant would be helpful in computing a LUT8. I can see this being useful for crypto., esp. when computing masked 8-bit S-boxes for the purpose of DPA hardening.

@ben-marshall
Copy link
Member Author

ben-marshall commented Sep 4, 2020 •
edited
Loading

Interestingly, Claire put together an example where you only need the 4-bit (xperm.n) variant to do an arbitrary 8-bit SBox operation, which makes me think that the wider variants might not be needed.

See here.

Looking at that again though, I realise that we might have a glaring omission: the gorc instruction is really useful in that example, and is not currently included in our spec.

I'll probably raise this in the next meeting or put an email out in the meanwhile. Happily, gorc can be implemented very cheaply alongside grev which we already have.

Edit:

  • My mistake, the example I linked to does use xperm.b. I just read it wrong.

@ben-marshall
Copy link
Member Author

Decided at meeting on 10'th Sept 2020 - xperm.b and xperm.n will be included in the scalar crypto spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ben-marshall @grnewell