TSS Library: Define and create a Test Plan

[mxtartaglia-sl]

This task aims to define the testing plan for assuring the quality of the project's cryptographic components.

Goals:

Since cryptographic code is often difficult to test, we should design our test cases based on the cryptographic properties that these implementations should satisfy.

• Identify other properties to test
• Define how to test.
• Define Test structure: Different project, same project?

Proposed tests

Pairings Keys

• Generation of Private and Public Key Pairs: This test measures the correctness of key pair generation by having the implementation under test produce 10 key pairs. The private key provided is used to compute the public key, Q’. The calculated value Q’ is then compared to the supplied public key, Q.

What should the comparison check?

• Public Key Validation: Generate 12 key pairs, modify some public keys to introduce errors, and verify that we can detect those errors.

Pairings Signatures

• Signature Generation: Ten preconfigured known messages per curve supported are supplied. Generate a signature for each message. The message, public key, and signature components are returned. The signatures are compared against previous known signatures.
• Signature Verification: For each curve supported, 15 pseudorandom messages, a public key, Q, and a signature component (r, s) are supplied. Modify some of the provided values and verify that signature verification fails.

Pairings

• How to validate operations? Compare against known results?

TSS

• Encrypted TssMessage
  The private key can decrypt the intended recipient’s parts and no others.
• Detection of invalid TssMessage
  -> Different polynomial commitment
  -> Different PaticipantDictionary
  -> Detection of invalid proof
• Aggregation of TssMessage
  -> An aggregated private share has the same length of its original source
  -> An aggregated private share is different from its original source
  -> Threshold number of messages can produce a valid public key
  -> Public key does not change when rehasing
• Aggregated Signatures
  -> Unforgeability of group signature:
  Less than threshold number of signatures cannot produce a valid aggregated signature
  More than threshold number of signatures can produce a valid aggregated signature
  -> Fixed length of threshold signature. Our scheme ensures that the size of a threshold signature is fixed (i.e., not depending on the number of signers).

Other tests mentioned in the bibliography that might apply for the TssMessage generation:

• Bit Contribution for Key Test
• Bit Contribution for Nonce Test
• Bit Contribution for Plaintext Test
• Bit Exclusion Test
• Ciphertext Length Check Test

EVM

• a stored signature can be retrieved correctly
• a stored public key can be retrieved correctly
• a valid TSS signature can be correctly validated.
• an invalid TSS signature can be correctly detected.
• Efficiency of verification.

Material:

• Cryptographic-Algorithm-Validation-Program:
• https://csrc.nist.gov/CSRC/media/Events/lightweight-cryptography-workshop-2019/documents/papers/systematic-testing-of-lightweight-crypto-lwc2019.pdf
• https://github.com/swingbyprotocol/tss-lib
• https://www.ietf.org/archive/id/draft-hallambaker-threshold-sigs-00.html
• https://github.com/IBM/TSS

[mxtartaglia-sl]

In the TSS-Library, the operations that rely on a source of randomness are:

• Proof Creation for the TssMessage.
• Creation of the ciphertext for the TssMessage.

As for the operations that rely on order:

• decryptPrivateShares: relies on the order of the TssMessages
• aggregatePrivateShares: relies on the order of the shares
• computePublicShares: relies on the order of the TssMessages.

In Pairings-Signature-Library, the creation of the private key depends on a random value.

[mxtartaglia-sl]

Here is the document:
https://docs.google.com/document/d/1Dc22J8-E39Bq__soPwh1yhDPrhXZE_aeoeJeBaugapo/edit?usp=sharing
@rsinha @litt3 @edward-swirldslabs @timo0 @lpetrovic05
cc: @poulok
Please review
Thanks

[lpetrovic05]

@mxtartaglia-sl It seems I cannot comment in the doc, so I will leave my comments here:

Measure the time taken for pairings, group operations, and field operations. → what are the performance parameters to compare against? What do we do with the results?

I would say we should have a JMH performance test at the top level. So generate shares, aggregate signatures and so on. What I have been doing with JMH results is just adding them to the class as a comment. I think these results should give us an idea about how long certain tasks take, how many shares can we practically support etc.

[edward-swirldslabs]

I'm in favor of prioritizing the complex algorithmic tests and leaving the functionality tests of basic algebraic operations till the vary end.

[mxtartaglia-sl]

Test plan document: https://github.com/hashgraph/hedera-services/blob/develop/platform-sdk/docs/proposals/TSS-Library/TSS-Library-Test-Plan.md