What is the type for the `ak` value in an Orchard full viewing key?

Community Collaborations
1

In ZIP 32: Shielded Hierarchical Deterministic Wallets’s Orchard Diversifier Derivation section, I see B = repr_P(ak), where repr_P is a function defined as … well actually I cannot find where it is defined.

In the ZIP-32 Conventions repr_J(P) describes P as a point on an elliptic curve. If I extrapolate back to repr_P then, I’m guessing ak must be a point on an elliptic curve.

But then we get to section 5.6.4.4 of the Zcash protocol spec where we pass the same ak to the I2LEOSP_256 function which clearly takes a big integer.

So in my in-progress implementation of Zcash, I have a type mismatch. Is ak a big integer or a point on an elliptic curve?

It’s interesting to compare this use of ak with Sapling, which in 5.6.3.3 of the Zcash protocol is explicitly passed through repr_J before being passed to LEBS2OSP_256, making it consistently appear to be a point on a curve. So if ak have the same type between sapling and orchard, maybe the spec is missing a repr function?

Can anyone shed any light on this?

1 Like
2

Screenshot_2023-06-08-13-03-42-04_40deb401b9ffe8e1df2f1cc5ba480b12
Screenshot_2023-06-08-13-03-42-04_40deb401b9ffe8e1df2f1cc5ba480b121080×289 71.6 KB

Repr_P(ak) is the representation of ak on the Pallas curve instead of Jubjub.

3

Thanks. Yes that confirms what I believed. But that suggests ak is a point on a curve. Yet I can’t pass a point on a curve directly to I2LEOSP_256 because that takes an integer. So… is a function missing in that expression to first convert the point to an integer?

4

In the context of that section, ak is a key.

Screenshot_2023-06-08-14-15-07-78_f541918c7893c52dbd1ee5d319333948
Screenshot_2023-06-08-14-15-07-78_f541918c7893c52dbd1ee5d3193339482400×175 77.3 KB

1 Like
5

Ah, so it’s a different ak altogether. Thank you. That’s what I was missing.

6

Same ak, serialized as a compressed point.

7

Well, I guess it’s just the X coordinate, given here ak is defined as Extract_P(ak_P).

aside: the worst part about reading this spec is so many layers of function definitions, across two large PDFs, and the browser’s Back button doesn’t usually work for jumping “back” to a prior position in the PDF. And given the function and variable names are often pictures due to their fancy characters, I can’t always search for them, or reuse the same name in my code to discover that I’ve already implemented a given function somewhere… It’s the hardest spec I’ve had to implement.

2 Likes