Footnotes and Annex for BTSS

References

 GG18 - Fast Multiparty Threshold ECDSA with Fast Trustless Setup: https://eprint.iacr.org/2019/114.pdf (revised version)
Go vulnerability database: https://pkg.go.dev/vuln/
govulcheck vulnerability scanner for Go: https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck#section-sourcefiles
io.finnet security disclosure for ECDSA and EdDSA threshold signature schemes (published on 28 Mars 2023): https://medium.com/@iofinnet/security-disclosure-for-ecdsa-and-eddsa-threshold-signature-schemes-4e969af7155b 
ING-bank’s tss lib: https://github.com/ing-bank/threshold-signatures
Binance’s tss lib: https://github.com/bnb-chain/tss-lib
Zengo-X tss lib: https://github.com/ZenGo-X/multi-party-ecdsa
Boneh, D., Gennaro, R., Goldfeder, S.: Using level-1 homomorphic encryption to improve threshold dsa signatures for bitcoin wallet security. In: Latincrypt (2017)
Gennaro, R., Goldfeder, S., Narayanan, A.: Threshold-optimal dsa/ecdsa signatures and an application to bitcoin wallet security. In: International Conference on Applied Cryptography and Network Security. pp. 156–174. Springer (2016)
Joltify TSS: https://github.com/joltify-finance/tss
 Thorchain TSS: https://github.com/torusresearch/thorchain-tss
 ioFinnet threslib: https://github.com/IoFinnet/threshlib
TSS-Lib audit report in 2019: https://github.com/bnb-chain/tss-lib/releases/download/v1.0.0/audit-binance-tss-lib-final-20191018.pdf
CVE-2020-12118:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12118
Alpha-Rays: Key Extraction Attacks on Threshold ECDSA Implementations: https://eprint.iacr.org/2021/1621.pdf
 GG20 - One Round Threshold ECDSA with Identifiable Abort: https://eprint.iacr.org/2020/540
TSS-Lib release 1.2.0: https://github.com/bnb-chain/tss-lib/releases/tag/v1.2.0
Multiple CVEs in threshold cryptography implementations: https://research.kudelskisecurity.com/2023/03/23/multiple-cves-in-threshold-cryptography-implementations/
UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts: https://eprint.iacr.org/2021/060.pdf
TSS-Lib GenerateXs function, line 273: https://github.com/bnb-chain/tss-lib/blob/master/crypto/paillier/paillier.go#L273
TSS-Lib patches the hash collision vulnerability: https://github.com/bnb-chain/tss-lib/pull/233/files
 big.int usage in TSS-Lib: https://github.com/bnb-chain/tss-lib/search?q=big.Int
Go 1.2.0 release removed math/big from the standard crypto module: https://tip.golang.org/doc/go1.20
Verichain report on the critical key extraction vulnerability on fastMPC client used on Multichain: https://blog.verichains.io/p/vsa-2022-120-multichain-key-extraction
fastMPC implementation: https://github.com/anyswap/FastMulThreshold-DSA/
Verichain claimed to discover new critical key extraction attack on popular TSS: ​https://blog.verichains.io/p/verichains-discovers-critical-key
 Flippo’s note on the release of Go 1.2.0: https://words.filippo.io/dispatches/go1-20/
Go crypto nistec module: https://pkg.go.dev/crypto/internal/nistec
Annex
govulncheck raw scan results

# Set the go version to 1.16 before to have 
go version
go version go1.16 darwin/amd64

govulncheck ./...
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.
Using go1.16 and govulncheck@v0.0.0 with
vulnerability data from https://vuln.go.dev (last modified 2023-04-11 17:40:07 +0000 UTC).
Scanning your code and 167 packages across 16 dependent modules for known vulnerabilities...
Your code is affected by 6 vulnerabilities from the Go standard library.

Vulnerability #1: GO-2023-1568
  A path traversal vulnerability exists in filepath.Clean on
  Windows. On Windows, the filepath.Clean function could transform
  an invalid path such as "a/../c:/b" into the valid path "c:\b".
  This transformation of a relative (if invalid) path into an
  absolute path could enable a directory traversal attack. After
  fix, the filepath.Clean function transforms this path into the
  relative (but still invalid) path ".\c:\b".
  More info: https://pkg.go.dev/vuln/GO-2023-1568
  Standard library
    Found in: path/filepath@go1.16
    Fixed in: path/filepath@go1.20.1
    Platforms: windows
    Call stacks in your code:
      ecdsa/keygen/test_utils.go:125:28: github.com/bnb-chain/tss-lib/ecdsa/keygen.makeTestFixtureFilePath calls path/filepath.Dir

Vulnerability #2: GO-2022-1039
  Programs which compile regular expressions from untrusted
  sources may be vulnerable to memory exhaustion or denial of
  service. The parsed regexp representation is linear in the size
  of the input, but in some cases the constant factor can be as
  high as 40,000, making relatively small regexps consume much
  larger amounts of memory. After fix, each regexp being parsed is
  limited to a 256 MB memory footprint. Regular expressions whose
  representation would use more space than that are rejected.
  Normal use of regular expressions is unaffected.
  More info: https://pkg.go.dev/vuln/GO-2022-1039
  Standard library
    Found in: regexp/syntax@go1.16
    Fixed in: regexp/syntax@go1.19.2
    Call stacks in your code:
      github.com/bnb-chain/tss-lib/crypto/paillier.init calls github.com/otiai10/primes.init, which eventually calls regexp/syntax.Parse

Vulnerability #3: GO-2022-0533
  On Windows, the filepath.Clean function can convert certain
  invalid paths to valid, absolute paths, potentially allowing a
  directory traversal attack. For example, Clean(`.\c:`) returns
  `c:`.
  More info: https://pkg.go.dev/vuln/GO-2022-0533
  Standard library
    Found in: path/filepath@go1.16
    Fixed in: path/filepath@go1.18.3
    Platforms: windows
    Call stacks in your code:
      ecdsa/keygen/test_utils.go:125:28: github.com/bnb-chain/tss-lib/ecdsa/keygen.makeTestFixtureFilePath calls path/filepath.Dir

Vulnerability #4: GO-2022-0524
  Calling Reader.Read on an archive containing a large number of
  concatenated 0-length compressed files can cause a panic due to
  stack exhaustion.
  More info: https://pkg.go.dev/vuln/GO-2022-0524
  Standard library
    Found in: compress/gzip@go1.16
    Fixed in: compress/gzip@go1.18.4
    Call stacks in your code:
      tss/message.go:114:33: github.com/bnb-chain/tss-lib/tss.MessageImpl.Type calls google.golang.org/protobuf/proto.MessageName, which eventually calls compress/gzip.Reader.Read

Vulnerability #5: GO-2022-0435
  A crafted scalar input longer than 32 bytes can cause
  P256().ScalarMult or P256().ScalarBaseMult to panic. Indirect
  uses through crypto/ecdsa and crypto/tls are unaffected. amd64,
  arm64, ppc64le, and s390x are unaffected.
  More info: https://pkg.go.dev/vuln/GO-2022-0435
  Standard library
    Found in: crypto/elliptic@go1.16
    Fixed in: crypto/elliptic@go1.18.1
    Call stacks in your code:
      ecdsa/signing/finalize.go:71:20: github.com/bnb-chain/tss-lib/ecdsa/signing.finalization.Start calls crypto/ecdsa.Verify, which eventually calls crypto/elliptic.CurveParams.ScalarBaseMult
      ecdsa/signing/finalize.go:71:20: github.com/bnb-chain/tss-lib/ecdsa/signing.finalization.Start calls crypto/ecdsa.Verify, which eventually calls crypto/elliptic.CurveParams.ScalarMult
      ecdsa/signing/finalize.go:71:20: github.com/bnb-chain/tss-lib/ecdsa/signing.finalization.Start calls crypto/ecdsa.Verify, which eventually calls crypto/elliptic.p256Curve.CombinedMult
      ecdsa/signing/finalize.go:71:20: github.com/bnb-chain/tss-lib/ecdsa/signing.finalization.Start calls crypto/ecdsa.Verify, which eventually calls crypto/elliptic.p256Curve.ScalarBaseMult
      ecdsa/signing/finalize.go:71:20: github.com/bnb-chain/tss-lib/ecdsa/signing.finalization.Start calls crypto/ecdsa.Verify, which eventually calls crypto/elliptic.p256Curve.ScalarMult

Vulnerability #6: GO-2021-0319
  Some big.Int values that are not valid field elements (negative
  or overflowing) might cause Curve.IsOnCurve to incorrectly
  return true. Operating on those values may cause a panic or an
  invalid curve operation. Note that Unmarshal will never return
  such values.
  More info: https://pkg.go.dev/vuln/GO-2021-0319
  Standard library
    Found in: crypto/elliptic@go1.16
    Fixed in: crypto/elliptic@go1.17.7
    Call stacks in your code:
      crypto/ckd/child_key_derivation.go:117:31: github.com/bnb-chain/tss-lib/crypto/ckd.NewExtendedKeyFromString calls crypto/elliptic.Unmarshal

=== Informational ===
Found 27 vulnerabilities in packages that you import, but there are no call
stacks leading to the use of these vulnerabilities. You may not need to
take any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.
Vulnerability #1: GO-2023-1705
  Multipart form parsing can consume large amounts of CPU and
  memory when processing form inputs containing very large numbers
  of parts. This stems from several causes: 1.
  mime/multipart.Reader.ReadForm limits the total memory a parsed
  multipart form can consume. ReadForm can undercount the amount
  of memory consumed, leading it to accept larger inputs than
  intended. 2. Limiting total memory does not account for
  increased pressure on the garbage collector from large numbers
  of small allocations in forms with many parts. 3. ReadForm can
  allocate a large number of short-lived buffers, further
  increasing pressure on the garbage collector. The combination of
  these factors can permit an attacker to cause an program that
  parses multipart forms to consume large amounts of CPU and
  memory, potentially resulting in a denial of service. This
  affects programs that use mime/multipart.Reader.ReadForm, as
  well as form parsing in the net/http package with the Request
  methods FormFile, FormValue, ParseMultipartForm, and
  PostFormValue. With fix, ReadForm now does a better job of
  estimating the memory consumption of parsed forms, and performs
  many fewer short-lived allocations. In addition, the fixed
  mime/multipart.Reader imposes the following limits on the size
  of parsed forms: 1. Forms parsed with ReadForm may contain no
  more than 1000 parts. This limit may be adjusted with the
  environment variable GODEBUG=multipartmaxparts=. 2. Form parts
  parsed with NextPart and NextRawPart may contain no more than
  10,000 header fields. In addition, forms parsed with ReadForm
  may contain no more than 10,000 header fields across all parts.
  This limit may be adjusted with the environment variable
  GODEBUG=multipartmaxheaders=.
  More info: https://pkg.go.dev/vuln/GO-2023-1705
  Found in: mime/multipart@go1.16
  Fixed in: mime/multipart@go1.20.3
Vulnerability #2: GO-2023-1704
  HTTP and MIME header parsing can allocate large amounts of
  memory, even when parsing small inputs, potentially leading to a
  denial of service. Certain unusual patterns of input data can
  cause the common function used to parse HTTP and MIME headers to
  allocate substantially more memory than required to hold the
  parsed headers. An attacker can exploit this behavior to cause
  an HTTP server to allocate large amounts of memory from a small
  request, potentially leading to memory exhaustion and a denial
  of service. With fix, header parsing now correctly allocates
  only the memory required to hold parsed headers.
  More info: https://pkg.go.dev/vuln/GO-2023-1704
  Found in: net/textproto@go1.16
  Fixed in: net/textproto@go1.20.3
Vulnerability #3: GO-2023-1571
  A maliciously crafted HTTP/2 stream could cause excessive CPU
  consumption in the HPACK decoder, sufficient to cause a denial
  of service from a small number of small requests.
  More info: https://pkg.go.dev/vuln/GO-2023-1571
  Found in: net/http@go1.16
  Fixed in: net/http@go1.20.1
Vulnerability #4: GO-2023-1570
  Large handshake records may cause panics in crypto/tls. Both
  clients and servers may send large TLS handshake records which
  cause servers and clients, respectively, to panic when
  attempting to construct responses. This affects all TLS 1.3
  clients, TLS 1.2 clients which explicitly enable session
  resumption (by setting Config.ClientSessionCache to a non-nil
  value), and TLS 1.3 servers which request client certificates
  (by setting Config.ClientAuth >= RequestClientCert).
  More info: https://pkg.go.dev/vuln/GO-2023-1570
  Found in: crypto/tls@go1.16
  Fixed in: crypto/tls@go1.20.1
Vulnerability #5: GO-2023-1569
  A denial of service is possible from excessive resource
  consumption in net/http and mime/multipart. Multipart form
  parsing with mime/multipart.Reader.ReadForm can consume largely
  unlimited amounts of memory and disk files. This also affects
  form parsing in the net/http package with the Request methods
  FormFile, FormValue, ParseMultipartForm, and PostFormValue.
  ReadForm takes a maxMemory parameter, and is documented as
  storing "up to maxMemory bytes +10MB (reserved for non-file
  parts) in memory". File parts which cannot be stored in memory
  are stored on disk in temporary files. The unconfigurable 10MB
  reserved for non-file parts is excessively large and can
  potentially open a denial of service vector on its own. However,
  ReadForm did not properly account for all memory consumed by a
  parsed form, such as map entry overhead, part names, and MIME
  headers, permitting a maliciously crafted form to consume well
  over 10MB. In addition, ReadForm contained no limit on the
  number of disk files created, permitting a relatively small
  request body to create a large number of disk temporary files.
  With fix, ReadForm now properly accounts for various forms of
  memory overhead, and should now stay within its documented limit
  of 10MB + maxMemory bytes of memory consumption. Users should
  still be aware that this limit is high and may still be
  hazardous. In addition, ReadForm now creates at most one on-disk
  temporary file, combining multiple form parts into a single
  temporary file. The mime/multipart.File interface type's
  documentation states, "If stored on disk, the File's underlying
  concrete type will be an *os.File.". This is no longer the case
  when a form contains more than one file part, due to this
  coalescing of parts into a single file. The previous behavior of
  using distinct files for each form part may be reenabled with
  the environment variable GODEBUG=multipartfiles=distinct. Users
  should be aware that multipart.ReadForm and the http.Request
  methods that call it do not limit the amount of disk consumed by
  temporary files. Callers can limit the size of form data with
  http.MaxBytesReader.
  More info: https://pkg.go.dev/vuln/GO-2023-1569
  Found in: mime/multipart@go1.16
  Fixed in: mime/multipart@go1.20.1
Vulnerability #6: GO-2022-1144
  An attacker can cause excessive memory growth in a Go server
  accepting HTTP/2 requests. HTTP/2 server connections contain a
  cache of HTTP header keys sent by the client. While the total
  number of entries in this cache is capped, an attacker sending
  very large keys can cause the server to allocate approximately
  64 MiB per open connection.
  More info: https://pkg.go.dev/vuln/GO-2022-1144
  Found in: net/http@go1.16
  Fixed in: net/http@go1.19.4
Vulnerability #7: GO-2022-1143
  On Windows, restricted files can be accessed via os.DirFS and
  http.Dir. The os.DirFS function and http.Dir type provide access
  to a tree of files rooted at a given directory. These functions
  permit access to Windows device files under that root. For
  example, os.DirFS("C:/tmp").Open("COM1") opens the COM1 device.
  Both os.DirFS and http.Dir only provide read-only filesystem
  access. In addition, on Windows, an os.DirFS for the directory
  (the root of the current drive) can permit a maliciously crafted
  path to escape from the drive and access any path on the system.
  With fix applied, the behavior of os.DirFS("") has changed.
  Previously, an empty root was treated equivalently to "/", so
  os.DirFS("").Open("tmp") would open the path "/tmp". This now
  returns an error.
  More info: https://pkg.go.dev/vuln/GO-2022-1143
  Found in: net/http@go1.16
  Fixed in: net/http@go1.19.4
  Platforms: windows
Vulnerability #8: GO-2022-1098
  Erroneous message decoding can cause denial of service. Improper
  checking of maximum witness size during node message decoding
  prevented nodes in Lightning Labs lnd (before 0.15.2-beta) to
  sync.
  More info: https://pkg.go.dev/vuln/GO-2022-1098
  Found in: github.com/btcsuite/btcd@v0.0.0-20190629003639-c26ffa870fd8
  Fixed in: github.com/btcsuite/btcd@v0.23.2
Vulnerability #9: GO-2022-1095
  Due to unsanitized NUL values, attackers may be able to
  maliciously set environment variables on Windows. In
  syscall.StartProcess and os/exec.Cmd, invalid environment
  variable values containing NUL values are not properly checked
  for. A malicious environment variable value can exploit this
  behavior to set a value for a different environment variable.
  For example, the environment variable string "A=B\x00C=D" sets
  the variables "A=B" and "C=D".
  More info: https://pkg.go.dev/vuln/GO-2022-1095
  Found in: syscall@go1.16
  Fixed in: syscall@go1.19.3
  Platforms: windows
Vulnerability #10: GO-2022-0969
  HTTP/2 server connections can hang forever waiting for a clean
  shutdown that was preempted by a fatal error. This condition can
  be exploited by a malicious client to cause a denial of service.
  More info: https://pkg.go.dev/vuln/GO-2022-0969
  Found in: net/http@go1.16
  Fixed in: net/http@go1.19.1
Vulnerability #11: GO-2022-0537
  Decoding big.Float and big.Rat types can panic if the encoded
  message is too short, potentially allowing a denial of service.
  More info: https://pkg.go.dev/vuln/GO-2022-0537
  Found in: math/big@go1.16
  Fixed in: math/big@go1.18.5
Vulnerability #12: GO-2022-0531
  An attacker can correlate a resumed TLS session with a previous
  connection. Session tickets generated by crypto/tls do not
  contain a randomly generated ticket_age_add, which allows an
  attacker that can observe TLS handshakes to correlate successive
  connections by comparing ticket ages during session resumption.
  More info: https://pkg.go.dev/vuln/GO-2022-0531
  Found in: crypto/tls@go1.16
  Fixed in: crypto/tls@go1.18.3
Vulnerability #13: GO-2022-0527
  Calling Glob on a path which contains a large number of path
  separators can cause a panic due to stack exhaustion.
  More info: https://pkg.go.dev/vuln/GO-2022-0527
  Found in: io/fs@go1.16
  Fixed in: io/fs@go1.18.4
Vulnerability #14: GO-2022-0525
  The HTTP/1 client accepted some invalid Transfer-Encoding
  headers as indicating a "chunked" encoding. This could
  potentially allow for request smuggling, but only if combined
  with an intermediate server that also improperly failed to
  reject the header as invalid.
  More info: https://pkg.go.dev/vuln/GO-2022-0525
  Found in: net/http@go1.16
  Fixed in: net/http@go1.18.4
Vulnerability #15: GO-2022-0522
  Calling Glob on a path which contains a large number of path
  separators can cause a panic due to stack exhaustion.
  More info: https://pkg.go.dev/vuln/GO-2022-0522
  Found in: path/filepath@go1.16
  Fixed in: path/filepath@go1.18.4
Vulnerability #16: GO-2022-0520
  Client IP adresses may be unintentionally exposed via
  X-Forwarded-For headers. When httputil.ReverseProxy.ServeHTTP is
  called with a Request.Header map containing a nil value for the
  X-Forwarded-For header, ReverseProxy sets the client IP as the
  value of the X-Forwarded-For header, contrary to its
  documentation. In the more usual case where a Director function
  sets the X-Forwarded-For header value to nil, ReverseProxy
  leaves the header unmodified as expected.
  More info: https://pkg.go.dev/vuln/GO-2022-0520
  Found in: net/http@go1.16
  Fixed in: net/http@go1.18.4
Vulnerability #17: GO-2022-0493
  When called with a non-zero flags parameter, the Faccessat
  function can incorrectly report that a file is accessible.
  More info: https://pkg.go.dev/vuln/GO-2022-0493
  Found in: syscall@go1.16
  Fixed in: syscall@go1.18.2
Vulnerability #18: GO-2022-0477
  On Windows, rand.Read will hang indefinitely if passed a buffer
  larger than 1 << 32 - 1 bytes.
  More info: https://pkg.go.dev/vuln/GO-2022-0477
  Found in: crypto/rand@go1.16
  Fixed in: crypto/rand@go1.18.3
  Platforms: windows
Vulnerability #19: GO-2022-0433
  encoding/pem in Go before 1.17.9 and 1.18.x before 1.18.1 has a
  Decode stack overflow via a large amount of PEM data.
  More info: https://pkg.go.dev/vuln/GO-2022-0433
  Found in: encoding/pem@go1.16
  Fixed in: encoding/pem@go1.18.1
Vulnerability #20: GO-2022-0289
  When a Go program running on a Unix system is out of file
  descriptors and calls syscall.ForkExec (including indirectly by
  using the os/exec package), syscall.ForkExec can close file
  descriptor 0 as it fails. If this happens (or can be provoked)
  repeatedly, it can result in misdirected I/O such as writing
  network traffic intended for one connection to a different
  connection, or content intended for one file to a different one.
  For users who cannot immediately update to the new release, the
  bug can be mitigated by raising the per-process file descriptor
  limit.
  More info: https://pkg.go.dev/vuln/GO-2022-0289
  Found in: syscall@go1.16
  Fixed in: syscall@go1.17.5
Vulnerability #21: GO-2022-0288
  An attacker can cause unbounded memory growth in servers
  accepting HTTP/2 requests.
  More info: https://pkg.go.dev/vuln/GO-2022-0288
  Found in: net/http@go1.16
  Fixed in: net/http@go1.17.5
Vulnerability #22: GO-2022-0236
  A malicious HTTP server or client can cause the net/http client
  or server to panic. ReadRequest and ReadResponse can hit an
  unrecoverable panic when reading a very large header (over 7MB
  on 64-bit architectures, or over 4MB on 32-bit ones). Transport
  and Client are vulnerable and the program can be made to crash
  by a malicious server. Server is not vulnerable by default, but
  can be if the default max header of 1MB is overridden by setting
  Server.MaxHeaderBytes to a higher value, in which case the
  program can be made to crash by a malicious client. This also
  affects golang.org/x/net/http2/h2c and HeaderValuesContainsToken
  in golang.org/x/net/http/httpguts.
  More info: https://pkg.go.dev/vuln/GO-2022-0236
  Found in: net/http@go1.16
  Fixed in: net/http@go1.16.4
Vulnerability #23: GO-2021-0347
  On 64-bit platforms, an extremely deeply nested expression can
  cause regexp.Compile to cause goroutine stack exhaustion,
  forcing the program to exit. Note this applies to very large
  expressions, on the order of 2MB.
  More info: https://pkg.go.dev/vuln/GO-2021-0347
  Found in: regexp@go1.16
  Fixed in: regexp@go1.17.8
Vulnerability #24: GO-2021-0317
  Rat.SetString had an overflow issue that can lead to
  uncontrolled memory consumption.
  More info: https://pkg.go.dev/vuln/GO-2021-0317
  Found in: math/big@go1.16
  Fixed in: math/big@go1.17.7
Vulnerability #25: GO-2021-0243
  crypto/tls clients can panic when provided a certificate of the
  wrong type for the negotiated parameters. net/http clients
  performing HTTPS requests are also affected.
  More info: https://pkg.go.dev/vuln/GO-2021-0243
  Found in: crypto/tls@go1.16
  Fixed in: crypto/tls@go1.16.6
Vulnerability #26: GO-2021-0242
  Rat.SetString and Rat.UnmarshalText may cause a panic or an
  unrecoverable fatal error if passed inputs with very large
  exponents.
  More info: https://pkg.go.dev/vuln/GO-2021-0242
  Found in: math/big@go1.16
  Fixed in: math/big@go1.16.5
Vulnerability #27: GO-2021-0239
  The LookupCNAME, LookupSRV, LookupMX, LookupNS, and LookupAddr
  functions and their respective methods on the Resolver type may
  return arbitrary values retrieved from DNS which do not follow
  the established RFC 1035 rules for domain names. If these names
  are used without further sanitization, for instance unsafely
  included in HTML, they may allow for injection of unexpected
  content. Note that LookupTXT may still return arbitrary values
  that could require sanitization before further use.
  More info: https://pkg.go.dev/vuln/GO-2021-0239
  Found in: net@go1.16
  Fixed in: net@go1.16.5