Table of Contents
- Overview
- Let’s get Started
- Basics of Schnorr Signatures
- Schnorr Signatures
- MuSig
- References
- Contributors
Overview
Private-public key pairs are the cornerstone of much of the cryptographic security underlying everything from secure web browsing to banking to cryptocurrencies. Private-public key pairs are asymmetric. This means that given one of the numbers (the private key), it’s possible to derive the other one (the public key). However, doing the reverse is not feasible. It’s this asymmetry that allows one to share the public key, uh, publicly and be confident that no one can figure out our private key (which we keep very secret and secure).
Asymmetric key pairs are employed in two main applications:
- in authentication, where you prove that you have knowledge of the private key; and
- in encryption, where messages can be encoded and only the person possessing the private key can decrypt and read the message.
In this introduction to digital signatures, we’ll be talking about a particular class of keys: those derived from elliptic curves. There are other asymmetric schemes, not least of which are those based on products of prime numbers, including RSA keys [1].
We’re going to assume you know the basics of elliptic curve cryptography (ECC). If not, don’t stress, there’s a gentle introduction in a previous chapter.
Let’s get Started
This is an interactive introduction to digital signatures. It uses Rust code to demonstrate some of the ideas presented here, so you can see them at work. The code for this introduction uses the tari_crypto library.
Tari makes use of the Ristretto elliptic curve in its cryptography ([Why Risretto?]).
This particular implementation has some nice features. We’ve overridden the +
(addition) and *
(multiplication)
operators so that the Rust code looks a lot more like mathematical formulae. This makes it much easier
to play with the ideas we’ll be exploring.
Basics of Schnorr Signatures
Public and Private Keys
The first thing we’ll do is create a public and private key from an elliptic curve.
On Ristretto, a private key is simply a scalar integer value between 0 and ~2256. That’s roughly how many atoms there are in the universe, so we have a big sandbox to play in.
We have a special point on the Ristretto curve called G, which acts as the “origin”. A public key is calculated by
adding G on the curve to itself,
Let’s take an example from this post, where
it is known that the public key for 1
, when written in uncompressed format, is 6a493210f74...73a3b919
.
The following code snippet demonstrates this:
Creating a Signature
Approach Taken
Reversing ECC math multiplication (i.e. division) is pretty much infeasible when using properly chosen random values for your scalars ([5],[6]). This property is called the Discrete Log Problem, and is used as the principle behind many cryptography and digital signatures. A valid digital signature is evidence that the person providing the signature knows the private key corresponding to the public key with which the message is associated, or that they have solved the Discrete Log Problem.
The approach to creating signatures always follows this recipe:
- Generate a secret once-off number (called a nonce),
. - Calculate the public version of the nonce,
from (where ). - Send the following to Bob, your recipient - your message (
), , and your public key ( ).
The actual signature is created by hashing the combination of all the public information above to create a challenge,
The hashing function is chosen so that e has the same range as your private keys. In our case, we want something that returns a 256-bit number, so SHA256 is a good choice.
Now the signature is constructed using your private information:
Bob can now also calculate
Note: When you construct the signature like this, it’s known as a Schnorr signature, which is discussed in
a following section. There are other ways of constructing
But see this:
Multiply out the right-hand side:
Substitute
So Bob must just calculate the public key corresponding to the signature
Why do we Need the Nonce?
Why do we need a nonce in the standard signature?
Let’s say we naïvely sign a message
and then the signature would be
Now as before, we can check that the signature is valid:
So far so good. But anyone can read your private key now because
We can show that leaving off the nonce is indeed highly insecure:
ECDH
How do parties that want to communicate securely generate a shared secret for encrypting messages? One way is called the Elliptic Curve Diffie-Hellman exchange (ECDH), which is a simple method for doing just this.
ECDH is used in many places, including the Lightning Network during channel negotiation [3].
Here’s how it works. Alice and Bob want to communicate securely. A simple way to do this is to use each other’s public keys and calculate
For security reasons, the private keys are usually chosen at random for each session (you’ll see the term ephemeral keys being used), but then we have the problem of not being sure the other party is who they say they are (perhaps due to a man-in-the-middle attack [4]).
Various additional authentication steps can be employed to resolve this problem, which we won’t get into here.
Schnorr Signatures
If you follow the crypto news, you’ll know that that the new hotness (at the time of writing, in 2018) in Bitcoin is Schnorr Signatures.
But in fact, they’re old news! The Schnorr signature is considered the simplest digital signature scheme to be provably secure in a random oracle model. It is efficient and generates short signatures. It was covered by U.S. Patent 4,995,082, which expired in February 2008 [7].
So why all the Fuss?
What makes Schnorr signatures so interesting and potentially dangerous, is their simplicity. Schnorr signatures are linear, so you have some nice properties.
Elliptic curves have the multiplicative property. So if you have two scalars
Schnorr signatures are of the form
You saw this property in a previous section, when we were verifying the signature. Schnorr signatures’ linearity makes it very attractive for, among others:
- signature aggregation;
- atomic swaps;
- “scriptless” scripts.
Naïve Signature Aggregation
Let’s see how the linearity property of Schnorr signatures can be used to construct a two-of-two multi-signature.
Alice and Bob want to cosign something (a Tari transaction, say) without having to trust each other; i.e. they need to be able to prove ownership of their respective keys, and the aggregate signature is only valid if both Alice and Bob provide their part of the signature.
Assuming private keys are denoted
So it looks like Alice and Bob can supply their own
But this scheme is not secure!
Key Cancellation Attack
Let’s take the previous scenario again, but this time, Bob knows Alice’s public key and nonce ahead of time, by waiting until she reveals them.
Now Bob lies and says that his public key is
Note that Bob doesn’t know the private keys for these faked values, but that doesn’t matter.
Everyone assumes that
But Bob can create this signature himself:
Better Approaches to Aggregation
In the Key Cancellation Attack, Bob didn’t know the private keys for his published
This works, but it requires another round of messaging between parties, which is not conducive to a great user experience.
A better approach would be one that incorporates one or more of the following features:
- It must be provably secure in the plain public-key model, without having to prove knowledge of secret keys, as we might have asked Bob to do in the naïve approach.
- It should satisfy the normal Schnorr equation, i.e. the resulting signature can be verified with an expression of the form
. - It allows for Interactive Aggregate Signatures (IAS), where the signers are required to cooperate.
- It allows for Non-interactive Aggregate Signatures (NAS), where the aggregation can be done by anyone.
- It allows each signer to sign the same message,
. - It allows each signer to sign their own message,
.
MuSig
MuSig is a recently proposed ([8],[9]) simple signature aggregation scheme that satisfies all of the properties in the preceding section.
MuSig Demonstration
We’ll demonstrate the interactive MuSig scheme here, where each signatory signs the same message. The scheme works as follows:
- Each signer has a public-private key pair, as before.
- Each signer shares a commitment to their public nonce (we’ll skip this step in this demonstration). This step is necessary to prevent certain kinds of rogue key attacks [10].
- Each signer publishes the public key of their nonce,
. - Everyone calculates the same “shared public key”,
as follows:
Note that in the preceding ordering of public keys, some deterministic convention should be used, such as the lexicographical order of the serialized keys.
- Everyone also calculates the shared nonce,
. - The challenge,
is . - Each signer provides their contribution to the signature as:
Notice that the only departure here from a standard Schnorr signature is the inclusion of the factor
The aggregate signature is the usual summation,
Verification is done by confirming that as usual:
Proof:
Let’s demonstrate this using a three-of-three multisig:
Security Demonstration
As a final demonstration, let’s show how MuSig defeats the cancellation attack from the naïve signature scheme. Using the same idea as in the Key Cancellation Attack section, Bob has provided fake values for his nonce and public keys:
This leads to both Alice and Bob calculating the following “shared” values:
Bob then tries to construct a unilateral signature following MuSig:
Let’s assume for now that
In the previous attack, Bob had all the information he needed on the right-hand side of the analogous calculation. In MuSig, Bob must somehow know Alice’s private key and the faked private key (the terms don’t cancel anymore) in order to create a unilateral signature, and so his cancellation attack is defeated.
Replay Attacks!
It’s critical that a new nonce be chosen for every signing ceremony. The best way to do this is to make use of a cryptographically secure (pseudo-)random number generator (CSPRNG).
But even if this is the case, let’s say an attacker can trick us into signing a new message by “rewinding” the signing
ceremony to the point where partial signatures are generated. At this point, the attacker provides a different message,
Everything on the right-hand side of the final equation is known by the attacker and thus he can trivially extract everybody’s private key. It’s difficult to protect against this kind of attack. One way to is make it difficult (or impossible) to stop and restart signing ceremonies. If a multi-sig ceremony gets interrupted, then you need to start from step one again. This is fairly unergonomic, but until a more robust solution comes along, it may be the best we have!
References
[1] Wikipedia: “RSA (Cryptosystem)” [online]. Available: https://en.wikipedia.org/wiki/RSA_(cryptosystem). Date accessed: 2018‑10‑11.
[2] Wikipedia: “Elliptic Curve Digital Signature Algorithm” [online]. Available: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm. Date accessed: 2018‑10‑11.
[3] Github: “BOLT #8: Encrypted and Authenticated Transport, Lightning RFC” [online]. Available: https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md. Date accessed: 2018‑10‑11.
[4] Wikipedia: “Man in the Middle Attack” [online]. Available: https://en.wikipedia.org/wiki/Man-in-the-middle_attack. Date accessed: 2018‑10‑11.
[5] StackOverflow: “How does a Cryptographically Secure Random Number Generator Work?” [online]. Available: https://stackoverflow.com/questions/2449594/how-does-a-cryptographically-secure-random-number-generator-work. Date accessed: 2018‑10‑11.
[6] Wikipedia: “Cryptographically Secure Pseudorandom Number Generator” [online]. Available: https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator. Date accessed: 2018‑10‑11.
[7] Wikipedia: “Schnorr Signature” [online]. Available: https://en.wikipedia.org/wiki/Schnorr_signature. Date accessed: 2018‑09‑19.
[8] Blockstream: “Key Aggregation for Schnorr Signatures” [online]. Available: https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html. Date accessed: 2018‑09‑19.
[9] G. Maxwell, A. Poelstra, Y. Seurin and P. Wuille, “Simple Schnorr Multi-signatures with Applications to Bitcoin” [online]. Available: https://eprint.iacr.org/2018/068.pdf. Date accessed: 2018‑09‑19.
[10] M. Drijvers, K. Edalatnejad, B. Ford, E. Kiltz, J. Loss, G. Neven and I. Stepanovs, “On the Security of Two-round Multi-signatures”, Cryptology ePrint Archive, Report 2018/417 [online]. Available: https://eprint.iacr.org/2018/417.pdf. Date accessed: 2019‑02‑21.