Network support for threshold signing mechanism #64

New Issue

dboreham · 2022-11-23T18:52:05Z

dboreham commented

2022-11-23 18:52:05 +00:00

Provide hooks in laconicd to facilitate the threshold signing code's communication with peer nodes.

@vibs29

Provide hooks in laconicd to facilitate the threshold signing code's communication with peer nodes. @vibs29

fare commented

2022-11-23 18:57:30 +00:00

(Migrated from github.com)

As I understand it, we will need an API / design pattern for the Go code to pass around separately

a decoded "packet" that is a Go datastructure (or subdatastructure of a bigger datastructure)
the identify of the verified sender (whether he signed the overall packet, or sent it over a TLS connection for which we verified the handshake)

As I understand it, we will need an API / design pattern for the Go code to pass around separately - a decoded "packet" that is a Go datastructure (or subdatastructure of a bigger datastructure) - the identify of the verified sender (whether he signed the overall packet, or sent it over a TLS connection for which we verified the handshake)

dboreham commented

2022-11-23 20:10:43 +00:00

the identify of the verified sender

Wanted to clarify this: does this mean that the signature protocol itself doesn't have a way to verify the originator (hence absent this transport layer verification, an attacker could inject a fake message that the protocol will process as legitimate)? Or is it more about wanting to reject noise from attackers before it is considered by the signing protocol code?

> the identify of the verified sender Wanted to clarify this: does this mean that the signature protocol itself doesn't have a way to verify the originator (hence absent this transport layer verification, an attacker could inject a fake message that the protocol will process as legitimate)? Or is it more about wanting to reject noise from attackers before it is considered by the signing protocol code?

fare commented

2022-11-24 04:00:47 +00:00

(Migrated from github.com)

There is an obvious security bootstrap issue. Before each participant's partial Schnorr keys have been generated, we don't even have any Schnorr key data to identify the participants with, so the participants obviously need an initial identity that pre-dates the Schnorr key generation protocol.
Even though I believe the partial key data could be used as a full Schnorr key of its own that conceivably be generated in advance and used during the bootstrap, the existing code base we are reusing does not make that particularly easy. I'm sure this can be solved without too much trouble if we care to, thus allowing us to have a participant's initial identity be a Schnorr private key, if needs be. But do we want that?
Inasmuch as the Layer 1 action happens using Ethereum identities, the "bootstrap" addresses are naturally Ethereum addresses (truncated keccak hashes of secp256k1 public keys). We could add an indirection for these keys to themselves sign a Schnorr or other identity before the distributed key generation, but I'm not sure what that buys us.
Inasmuch as participants already communicate with each other using TLS or some other encrypted and authenticated transport layer, it is much cheaper to leverage the authentication done at the beginning of such a connection than to do a signature verification at each packet. Indeed, the asymmetric cryptography involved in making and verifying signatures is much more expensive than the symmetric cryptography used as part of a connection, wherein the asymmetric cryptography is used once and only once, at the beginning (or, rarely, upon reconnection or renegotiation of symmetric keys to avoid key overuse).
Inasmuch as asymmetric cryptography is expensive, we want to sign one master message and have as many useful "packets" as possible batched in a single signature, whether the signature applies to a connection or to a large message batch. For instance, even within this Schnorr signature protocol, we may want to batch the negotiation of many of the random numbers being generated; batching and pipelining this protocol step in advance can tremendously reduce the latency of the distributed signature.

1. There is an obvious security bootstrap issue. Before each participant's partial Schnorr keys have been generated, we don't even have any Schnorr key data to identify the participants with, so the participants obviously need an initial identity that pre-dates the Schnorr key generation protocol. 2. Even though I *believe* the partial key data *could* be used as a full Schnorr key of its own that conceivably be generated in advance and used during the bootstrap, the existing code base we are reusing does not make that particularly easy. I'm sure this can be solved without too much trouble if we care to, thus allowing us to have a participant's initial identity be a Schnorr private key, if needs be. But do we want that? 3. Inasmuch as the Layer 1 action happens using Ethereum identities, the "bootstrap" addresses are naturally Ethereum addresses (truncated keccak hashes of secp256k1 public keys). We *could* add an indirection for these keys to themselves sign a Schnorr or other identity before the distributed key generation, but I'm not sure what that buys us. 4. Inasmuch as participants already communicate with each other using TLS or some other encrypted and authenticated transport layer, it is *much* cheaper to leverage the authentication done at the beginning of such a connection than to do a signature verification at each packet. Indeed, the asymmetric cryptography involved in making and verifying signatures is *much* more expensive than the symmetric cryptography used as part of a connection, wherein the asymmetric cryptography is used once and only once, at the beginning (or, rarely, upon reconnection or renegotiation of symmetric keys to avoid key overuse). 5. Inasmuch as asymmetric cryptography is expensive, we want to sign one master message and have as many useful "packets" as possible batched in a single signature, whether the signature applies to a connection or to a large message batch. For instance, even within this Schnorr signature protocol, we may want to batch the negotiation of many of the random numbers being generated; batching and pipelining this protocol step in advance can tremendously reduce the latency of the distributed signature.

fare commented

2022-11-24 04:18:54 +00:00

(Migrated from github.com)

NB: if I get my orders of magnitude right, it takes ~50-200 μs to verify a signature over 32 bytes of data using asymmetric cryptography, vs 20-900 ns to decrypt the same 32 bytes using symmetric cryptography (faster number if you use Intel hardware acceleration for AES). That's 2 to 3 orders of magnitude of difference. See e.g. this (slightly dated) page from one particular performance-caring implementation https://www.bearssl.org/speed.html

In other words, if we care about performance, we want to minimize the number of operations using asymmetric cryptography.

NB: if I get my orders of magnitude right, it takes ~50-200 μs to verify a signature over 32 bytes of data using asymmetric cryptography, vs 20-900 ns to decrypt the same 32 bytes using symmetric cryptography (faster number if you use Intel hardware acceleration for AES). That's 2 to 3 orders of magnitude of difference. See e.g. this (slightly dated) page from one particular performance-caring implementation https://www.bearssl.org/speed.html In other words, if we care about performance, we want to minimize the number of operations using asymmetric cryptography.

dboreham commented

2022-12-01 15:18:12 +00:00

Signing code information:

git clone git@github.com:MuKnSys/signing-tool.git
git clone git@github.com:MuKnSys/kyber.git
mv kyber signing-tool/
If you don't have permission, please ask Alex Smart at MuKn for it.
And instead of waiting, you can download a combination of the above from:
http://www.wispym.com/download/signing-tool.tar.gz
These files form the lowest networking layer, which is what I expect will be replaced,
signing-tool/siggy/src/net/net_*.go
----
I don't believe anybody besides me has tried to edit, build, run the code.
You needn't try this recipe. If you do, you'll be the first.
It's probably better for us to speak on the phone than for you to be the guinea pig.
Do,
cat signing-tool/start.txt
Getting through the first section of signing-tool/siggy/doc/usage.txt is easier than the last two sections, which are to do with specifying a different/production configuration, and which I haven't done in ages. If the end of the first section of usage.txt produces a protocol run output something like this, that's success:
vibhu@workstation:~/work/siggy/run$ echo 0 _ AA |
> ./signode config.out test_keys/public/ test_keys/p1_secret/ 2 _ \
> test_keys/p1_secret/longterms_t2
127.0.0.1:14001
guest/run/certified/qual:  2 sig01669266487100 true 3
guest/run/certified/qual:  0 sig01669266487100 true 3
guest/run/certified/qual:  1 sig01669266487100 true 3
DSS completed run ID sig01669266487100
&{[187 50 129 101 24 159 164 232 97 117 171 206 152 204 214 179 217 175 232 88] 20757298488152241305419440155869207415700958900079436943618264922275424392334}
&{[187 50 129 101 24 159 164 232 97 117 171 206 152 204 214 179 217 175 232 88] 20757298488152241305419440155869207415700958900079436943618264922275424392334}
&{[187 50 129 101 24 159 164 232 97 117 171 206 152 204 214 179 217 175 232 88] 20757298488152241305419440155869207415700958900079436943618264922275424392334}
This is my computer,
$ go version
go version go1.18.4 linux/amd64
$ uname -a
Linux workstation 4.9.0-19-amd64 #1 SMP Debian 4.9.320-2 (2022-06-30) x86_64 GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Signing code information: ``` git clone git@github.com:MuKnSys/signing-tool.git git clone git@github.com:MuKnSys/kyber.git mv kyber signing-tool/ If you don't have permission, please ask Alex Smart at MuKn for it. And instead of waiting, you can download a combination of the above from: http://www.wispym.com/download/signing-tool.tar.gz These files form the lowest networking layer, which is what I expect will be replaced, signing-tool/siggy/src/net/net_*.go ---- I don't believe anybody besides me has tried to edit, build, run the code. You needn't try this recipe. If you do, you'll be the first. It's probably better for us to speak on the phone than for you to be the guinea pig. Do, cat signing-tool/start.txt Getting through the first section of signing-tool/siggy/doc/usage.txt is easier than the last two sections, which are to do with specifying a different/production configuration, and which I haven't done in ages. If the end of the first section of usage.txt produces a protocol run output something like this, that's success: vibhu@workstation:~/work/siggy/run$ echo 0 _ AA | > ./signode config.out test_keys/public/ test_keys/p1_secret/ 2 _ \ > test_keys/p1_secret/longterms_t2 127.0.0.1:14001 guest/run/certified/qual: 2 sig01669266487100 true 3 guest/run/certified/qual: 0 sig01669266487100 true 3 guest/run/certified/qual: 1 sig01669266487100 true 3 DSS completed run ID sig01669266487100 &{[187 50 129 101 24 159 164 232 97 117 171 206 152 204 214 179 217 175 232 88] 20757298488152241305419440155869207415700958900079436943618264922275424392334} &{[187 50 129 101 24 159 164 232 97 117 171 206 152 204 214 179 217 175 232 88] 20757298488152241305419440155869207415700958900079436943618264922275424392334} &{[187 50 129 101 24 159 164 232 97 117 171 206 152 204 214 179 217 175 232 88] 20757298488152241305419440155869207415700958900079436943618264922275424392334} This is my computer, $ go version go version go1.18.4 linux/amd64 $ uname -a Linux workstation 4.9.0-19-amd64 #1 SMP Debian 4.9.320-2 (2022-06-30) x86_64 GNU/Linux $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" VERSION_CODENAME=stretch ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ```

Sign in to join this conversation.