Details on Generating Viewing Key and Payment Address

The protocol states

A key tuple (ask, skenc, addrpk) is generated by users who wish to receive payments under this scheme. The viewing key skenc and the payment address addrpk = (apk , pkenc ) are derived from the spending key ask .\

I cannot find a clear explanation of how the viewing key is generated from the spending key and how the transmission key is then generated from the viewing key. Any pointers?

1 Like

See section 4.2 Key Components. I’ll include a link to that from 3.1 Payment Addresses and Keys to save time for others.

(In general, section 3 defines concepts but not any of the crypto implementing them.)

Thanks Daria,

If I understand this correctly, from a lay-person’s point of view;

ask is a large random number generated in a way similar to how one would generate a private key in bitcoin
apk is ask pushed though a hash function - ie not a public key in the bitcoin elliptic curve sense
skenc is apk transformed into a private key format - ie a large number deterministically liked to the hash of ask
pkenc is the public key of skenc - ie the elliptic curve point related to skenc by point multiplication of the generator

Am I on the right track? Can I ask what the (0) and (1) qualifiers are on PRFask for the apk and skenc respectively.

Thanks Daria,

Daira, and you’re welcome.

If I understand this correctly, from a lay-person’s point of view;

ask is a large random number generated in a way similar to how one would generate a private key in bitcoin

Yes.

apk is ask pushed though a hash function - ie not a public key in the bitcoin elliptic curve sense

Yes.

skenc is apk transformed into a private key format - ie a large number deterministically liked to the hash of ask

No, apk is a public part of the address, so skenc cannot be derived from it. It is derived as a (different) hash of ask.

(ask is the spending key, which allows you to spend from an address. skenc is the viewing key, which allows you to see payments sent to an address. You should be able to derive the viewing key from the spending key but not vice versa.)

pkenc is the public key of skenc - ie the elliptic curve point related to skenc by point multiplication of the generator

Yes.

Am I on the right track? Can I ask what the (0) and (1) qualifiers are on PRFask for the apk and skenc respectively.

Since we use the same function PRFaddr to derive both from ask, we need distinct inputs to make sure that apk is unrelated to skenc.