search

riscv / riscv-crypto

RISC-V cryptography extensions standardisation work.
https://wiki.riscv.org/x/MVcF
Creative Commons Attribution 4.0 International
363 stars 84 forks source link

The belonging of 'Zks' #85

Closed Xinlong-Wu closed 3 years ago

Xinlong-Wu commented 3 years ago

Hi, Ben According to the following figure. image

I draw this relationship graph of each Functional Set. image

but it confused me a bit. in this graph, set 'Zks' is not be included in 'k', Is it an oversight? Or did you do it on purpose? because in my opinion, there should be a set which includes all functional sets as their subset. just like a tree structure(following picture is only an example). image

cuz in this way, users can use all Instructions of Scalar Cryptography Extension by only include one functional set.

Cheers, VincentWu

ben-marshall commented 3 years ago

Hi Vincent

Good question. So, it isn't a typo, though I can understand that it might look like one given there is no explanation for this choice. I think the original rationale for this was the expectation that many more companies would implement ZKnZKr=K, because the algorithms those feature sets refer to are much more popular world wide in terms of being part of standards than those in ZKs.

I will double check this rationale at the next meeting, and add a note in the next release of the specification to explain it (or fix it, if need be!). Thanks for picking up on it, it's good to know where things don't make obvious sense.

We can leave the issue open until it's clarified.

Cheers, Ben

grnewell commented 3 years ago

Ben nailed the answer. K is the more internationally used NIST suite and entropy-related extension and required bit-manipulation instructions without the Shang-Mi suite, which is almost exclusively used only in China. Most processors developed without the Chinese market in mind would prefer not to be burdened with the Shang-Mi Suite commands. It is easier to “add” than “subtract,” so we defined K as the more common NIST subset. Zks is easy to add on to K.

Rich

G. Richard Newell Assoc. Technical Fellow, FPGA Business Unit, Microchip Technology (408) 643-6146 (office), (408) 882-4785 (mobile), +1 (925) 478-7258 (Skype) PGP: (2009 DSA-1024, ELG-4096) B751 FC13 8B4E 49DA 2270 35A2 20E4 E66A D0D0 2E34 (2016 SSA-4096, RSA-4096) 65F5 CCD6 23B3 BD3D CEDE AB58 171F F4DE E7D0 3ECA

From: Ben Marshall @.> Sent: Wednesday, March 17, 2021 7:33 AM To: riscv/riscv-crypto @.> Cc: Subscribed @.***> Subject: Re: [riscv/riscv-crypto] The belonging of 'Zks' (#85)

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi Vincent

Good question. So, it isn't a typo, though I can understand that it might look like one given there is no explanation for this choice. I think the original rationale for this was the expectation that many more companies would implement ZKnZKr=K, because the algorithms those feature sets refer to are much more popular world wide in terms of being part of standards than those in ZKs.

I will double check this rationale at the next meeting, and add a note in the next release of the specification to explain it (or fix it, if need be!). Thanks for picking up on it, it's good to know where things don't make obvious sense.

We can leave the issue open until it's clarified.

Cheers, Ben

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/riscv/riscv-crypto/issues/85#issuecomment-801133054, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKTRL7OV7ZDWQEKFPYO4EGLTEC4RRANCNFSM4ZKFHCAA.