zec
/
halo2
mirror of https://github.com/zcash/halo2.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[Book] Explain the decision to exclude zero points and scalars for KA.Orchard. fixes #62 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-04-21 18:37:56 +01:00
parent b88e77dd56
commit 18bc70afa2
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
book/src/design/keys.md
View File

@ -34,6 +34,16 @@ We make several structural changes, building on the lessons learned from Sapling
being specified to be infallible. This removes significant complexity from the use cases being specified to be infallible. This removes significant complexity from the use cases
for diversified addresses. for diversified addresses.
- The fact that Pallas is a prime-order curve simplifies the protocol and removes the need
for cofactor multiplication in key agreement. Unlike Sapling, we define public (including
ephemeral) and private keys used for note encryption to exclude the zero point and the
zero scalar. Without this change, the implementation of the Orchard Action circuit would
need special cases for the zero point, since Pallas is a short Weierstrass rather than
an Edwards curve. This also has the advantage of ensuring that the key agreement has
"contributory behaviour" — that is, if *either* party contributes a random scalar, then
the shared secret will be random to an observer who does not know that scalar and cannot
break Diffie–Hellman.
Other than the above, Orchard retains the same design rationale for its keys and addresses Other than the above, Orchard retains the same design rationale for its keys and addresses
as Sapling. For example, diversifiers remain at 11 bytes, so that a raw Orchard address is as Sapling. For example, diversifiers remain at 11 bytes, so that a raw Orchard address is
the same length as a raw Sapling address. the same length as a raw Sapling address.