Randomizable Signatures
Penumbra’s signatures are provided by decaf377rdsa
, a variant of the Zcash
RedDSA construction instantiated using the decaf377
group.
These are Schnorr signatures, with two additional properties relevant to
Penumbra:

They support randomization of signing and verification keys. Spending a note requires use of the signing key that controls its spend authorization, but if the same spend verification key were included in multiple transactions, they would be linkable. Instead, both the signing and verification keys are kept secret^{1}, and each spend description includes a randomization of the verification key, together with a proof that the randomized verification key was derived from the correct spend verification key.

They support addition and subtraction of signing and verification keys. This property is used for binding signatures, which bind zeroknowledge proofs to the transaction they were intended for and enforce conservation of value.
decaf377rdsa
Let $G$ be the decaf377
group of prime order $r$. Keys and signatures
are parameterized by a domain $D$. Each domain has an associated generator
$B_{D}$. Currently, there are two defined domains: $D=SpendAuth$ and
$D=Binding$. The hash function $H_{⋆}:{0,1}_{∗}→F_{r}$ is instantiated by using blake2b
with the personalization string
decaf377rdsa
, treating the 64byte output as the littleendian encoding of
an integer, and reducing that integer modulo $r$.
A signing key is a scalar $a∈F_{r}$. The corresponding verification key is the group element $A=[a]B_{D}$.
Sign
On input message m
with signing key $a$, verification key $A$, and domain $D$:
 Generate 80 random bytes.
 Compute the nonce as $r←H_{⋆}(random_bytes∣∣A_bytes∣∣m)$.
 Commit to the nonce as $R←[r]B_{D}$.
 Compute the challenge as $c←H_{⋆}(R_bytes∣∣A_bytes∣∣m)$.
 Compute the response as $s←r+ac$.
 Output the signature
R_bytes  s_bytes
.
Verify
On input message m
, verification key A_bytes
, and signature sig_bytes
:
 Parse $A$ from
A_bytes
, or fail ifA_bytes
is not a valid (hence canonical)decaf377
encoding.  Parse
sig_bytes
asR_bytes  s_bytes
and the components as $R$ and $s$, or fail if they are not valid (hence canonical) encodings.  Recompute the challenge as $c←H_{⋆}(R_bytes∣∣A_bytes∣∣m)$.
 Check the verification equation $R=[s]B−[c]A$, rejecting the signature if it is not satisfied.
SpendAuth
signatures
The first signature domain used in Penumbra is for spend authorization signatures. The basepoint $B_{SpendAuth}$ is the conventional decaf377
basepoint 0x0800000...
.
Spend authorization signatures support randomization:
Randomize.SigningKey
Given a randomizer $r$ F_{r}$, the randomized signing key is $ra$.
Randomize.VerificationKey
Given a randomizer $r$ F_{r}$, the randomized verification key is $[r]A$.
Randomizing a signing key and then deriving the verification key associated to the randomized signing key gives the same result as randomizing the original verification key (with the same randomizer).
Binding
signatures
The second signature domain used in Penumbra is for binding signatures. The
basepoint $B_{Binding}$ is the result of converting
blake2b(b"decaf377rdsabinding")
to an $F_{r}$ element and applying
decaf377
’s CDH maptogroup method.
Since the verification key corresponding to the signing key $a∈F_{r}$ is $A=[a]B_{D}$, adding and subtracting signing and verification keys commutes with derivation of the verification key, as desired.
WARNING: the decaf377
CDH map is unstable, so it may change in the future and change binding signatures with it.
This situation is a good example of why it’s better to avoid the terms “public key” and “private key”, and prefer more precise terminology that names keys according to the cryptographic capability they represent, rather than an attribute of how they’re commonly used. In this example, the verification key should not be public, since it could link different transactions.