内容简介:This is Hierarchical Threshold Signature Scheme (HTSS) worked byThe main merit of HTSS is vertical access control such that it has "partial accountability”. Although TSS achieves joint control to disperse risk among the participants, the level of all share
Hierarchical Threshold Signature Scheme
Introduction:
This is Hierarchical Threshold Signature Scheme (HTSS) worked by AMIS . Comparing to Threshold Signature Scheme (TSS), shares in this scheme are allowed to have different ranks.
The main merit of HTSS is vertical access control such that it has "partial accountability”. Although TSS achieves joint control to disperse risk among the participants, the level of all shares are equal. It is impossible to distinguish which share getting involved in an unexpected signature. TSS is not like the multi-signature scheme as the signature is signed by distinct private keys in multi-signature scheme. It is because Shamir’s secret sharing only supports horizontal access control.
For example, an important contract not only requires enough signatures, but also needs to be signed by a manager. Despite the fact that vertical access control can be realized on the application layer and tracked by an audit log. Once a hack happens, we will have no idea about who to blame for. However, in HTSS framework, through assigning different ranks of each share induces that any valid signature generated includes the share of the manager.
HTSS has been developed by Tassa and other researchers many years ago. In our implementation, we setup up this theory on TSS(i.e. just replace Lagrange Interpolation to Birkhoff Interpolation). Meanwhile, our protocol of sign (i.e. GG18 and CCLST20 ) can support two homomorphic encryptions which are Paillier and CL scheme.
This code will be audited soon.
One of references of HTSS is A Hierarchical Threshold Signature or See.
Table of Contents:
Implementations:
Like the classical TSS, HTSS also contains three protocols:
- DKG: Distributed key generation for creating secret shares without any dealer.
- Signer: Signing for using the secret shares to generate a signature.
- Reshare: Refresh the secret share without changing the public key.
The algorithms can be downloaded in here .
Remark:
- Comparing to TSS, each share in HTSS is generated by DKG having difference levels (or called rank). The level 0 is the highest.
- If all levels of shares are zero, then HTSS reduces to the classical TSS. (i.e. In this case, Birkhoff interpolation reduces to Lagrange Interpolation).
- After perform the progress of DKG, each participant will get (x-coordinate, share, rank). Assume that the threshold is 3. Therefore, any three shares (x-coordinate, rank): (x1, n1), (x2, n2), (x3, n3) with n1 <= n2 <= n3 can recover the secret or sign if and only if n_i <= i-1 for all 1 <= i <= 3. In general, assuming the threshold is t, any t shares (xi,ni) with ni <= nj for all i < j can recover the secret or sign if and only if n_i <= i-1 for all 1 <= i <= t.
Example:
Let threshold = 3, and participants = 4. Assume that the corresponding rank of each shareholder are 0, 1, 1, 2. Then authorized sets in this setting are
- 0, 1, 1
- 0, 1, 2
- 0, 1, 1, 2
The other combinations of shares can not recover the secret (e.g. 1, 1, 2).
DKG:
We implement a modified version of DKG in Fast Multiparty Threshold ECDSA with Fast Trustless Setup . We point out the different parts:
- Replace Lagrange interpolation with Birkhoff interpolation and generate own x-coordinate respectively.
- We do not generate a private key and the corresponding public key of homomorphic encryptions (i.e. Paillier cryptosystem or CL Scheme) in the key-generation. Move it to the beginning of Signer.
Signer:
Our implementation involves two algorithms: Fast Multiparty Threshold ECDSA with Fast Trustless Setup and Bandwidth-efficient threshold EC-DSA . The main difference of two schemes is applying different homomorphic encryptions. One is Paillier cryptosystem and another is CL scheme. We point out the difference between our implementation and their versions.
GG18:
- Replace Lagrange interpolation with Birkhoff interpolation .
- In the beginning of signer, we generate a key-pair of the homomorphic encryption.
Remark:Our version is the algorithm of GG18 without doing range proofs in MtA(cf. Section 3, GG18 ).
CCLST:
- Replace Lagrange interpolation with Birkhoff interpolation .
- In the beginning of signer, we generate different parameters for each participant in the homomorphic encryption scheme. In their protocol, all participants use the same parameters but different key-pairs, which are generated in DKG.
- All zero-knowledge proofs are non-interactive version (i.e. This part will be audited soon).
Reshare:
It is the standard algorithm replacing Lagrange interpolation with Birkhoff interpolation .
Usage:
Peer:
We create an interface named `PeerManager`. It defines three methods to be implemented.
NumPeers SelfID MustSend
Before you try to go through a multi-party algorithm, you should create a peer manager instance first. Here is an example for DKG.
type dkgPeerManager struct { id string numPeers uint32 dkgs map[string]*dkg.DKG } func newDKGPeerManager(id string, numPeers int, dkgs map[string]*dkg.DKG) *dkgPeerManager { return &dkgPeerManager{ id: id, numPeers: uint32(numPeers), dkgs: dkgs, } } func (p *dkgPeerManager) NumPeers() uint32 { return p.numPeers } func (p *dkgPeerManager) SelfID() string { return p.id } func (p *dkgPeerManager) MustSend(id string, message proto.Message) { d := p.dkgs[id] msg := message.(types.Message) d.AddMessage(msg) }
Listener:
We create an interface named `StateChangedListener`. It defines one method to be implemented.
-
OnStateChanged
: Handle state changed.
type listener struct{} func newListener() *listener { return &listener{} } func (l *listener) OnStateChanged(oldState types.MainState, newState types.MainState) { // Handle state changed. }
DKG:
Distributed key generation (DKG) is a process that multiple parties participate in the calculation of a shared public key and private key. To create a new DKG instance, there are some inputs caller must provide in our implementation.
- curve : an elliptic curve (e.g. S256)
- dkgPeerManager : a peer manager for DKG
- threshold : minimum number of participants required to sign
- rank : the rank of this participant
- listener : a function to monitor the state change
myDKG, err := dkg.NewDKG(curve, dkgPeerManager, threshold, rank, listener) if err != nil { // handle error } myDKG.Start() // send out peer message... myDKG.Stop() dkgResult, err := myDKG.GetResult() if err != nil { // handle error }
After DKG, all the participants would get the same public key and all the x-coordinates and ranks. Each participant would also get their own share.
Signer:
A (t,n)-threshold signature is a digital signature scheme that any t or more signers of a group of n signers could generate a valid signature. Here, we support two encryption algorithms for signing: Paillier, and CL. Caller must specify which encryption to be used. The security level of two homomorphic encryptions can be found in.
// 1. Paillier homo, err := paillier.NewPaillier(2048) if err != nil { // handle error } // 2. CL safeParameter := 1348 distributionDistance := uint(40) homo, err := cl.NewCL(big.NewInt(1024), 40, c.Params().N, safeParameter, distributionDistance) if err != nil { // handle error }
To start signing, you should provide some inputs for creating a new Signer instance.
- signerPeerManager : a peer manager for signer
- publicKey : the public key generated from DKG
- homo : a homomorphic encryption (Paillier of CL)
- share : the private share from DKG
- bks : the Birkhoff parameter of all participants
- msg : a message to be signed
- listener : a function to monitor the state change
Note that, threshold
signers are required to participate in signing. Therefore, the length of bks
must not be less than threshold
.
mySigner, err = signer.NewSigner(signerPeerManager, publicKey, homo, share, bks, msg, listener) if err != nil { // handle error } mySigner.Start() // send out public key message... mySigner.Stop() signerResult, err := mySigner.GetResult() if err != nil { // handle error }
After signing, all the participants should get the same signature.
Reshare:
Refreshing share (reshare) computes new random shares for the same original secret key. Before resharing, here is also some inputs you need to prepare.
- resharePeerManager : a peer manager for reshare
- threshold : minimum number of participants required to sign
- publicKey : the public key generated from DKG
- share : the private share from DKG
- bks : Birkhoff parameters from all participants
- listener : a function to monitor the state change
Note that, reshare process requires all peers to participate.
myReshare, err = reshare.NewReshare(resharePeerManager, threshold, publicKey, share, bks, listener) if err != nil { // handle error } myReshare.Start() // send out commit message... myReshare.Stop() signerResult, err := myReshare.GetResult() if err != nil { // handle error }
After resharing, all the participants should get their new shares. For more usage, please check tss/integration/tee_test.go
.
Examples:
Standard threshold signature:
There are three people co-founding a small store. Many goods come in and out every day. To increase efficiency, they agree that if any two of them confirms a transaction, the transaction should be valid. In this case, they could utilize threshold signature.
In DKG stage, all of them should create a peer manager specifying number of peers to be 2
. And all of them should have the same value of rank
to be 0
. Then in signing stage, any two of them could generate a valid signature.
- Ranks: (0, 0, 0)
- Threshold: 2
DKG:
// S256 for example curve := btcec.S256() id := "myID" peerNum := uint32(2) threshold := uint32(2) rank := uint32(0) // each co-founder dkgPeerManager := newDKGPeerManager(id, peerNum, dkgs) myDKG, _ := dkg.NewDKG(curve, dkgPeerManager, threshold, rank, listener)
Signing:
msg := []byte{1, 2, 3} peerNum := uint32(1) homo, _ := paillier.NewPaillier(2048) // get result from DKG result, _ := myDKG.GetResult() // any two of co-founders signerPeerManager := newSignerPeerManager(id, peerNum, signers) mySigner, _ := signer.NewSigner(signerPeerManager, result.PublicKey, homo, result.Share, result.Bks[id], peerBks, msg, listener)
Hierarchical threshold signature:
Imagine a department in a company is consisted of three employees and one director. The company stipulate that any transaction should be approved by at least three people and one of the approval must be the director. In this case, there are four participants but their powers might be different.
In DKG stage, all of them should create a peer manager specifying number of peers to be 3
. Three employees should set the rank
value to be 1
but the director should have the rank
value to be 0
(smaller the value, higher the rank). In signing stage, any two of employees along with the director could generate a valid signature. If three employees without the director try to sign a message, the signing process will return an error.
- Ranks: (0, 1, 1, 1)
- Threshold: 3
DKG:
// S256 for example curve := btcec.S256() id := "myID" peerNum := uint32(3) threshold := uint32(3) employeeRank := uint32(1) directorRank := uint32(0) // each employee dkgPeerManager := newDKGPeerManager(id, peerNum, dkgs) employeeDKG, _ := dkg.NewDKG(curve, dkgPeerManager, threshold, employeeRank, listener) // the director directorDKG, _ := dkg.NewDKG(curve, dkgPeerManager, threshold, directorRank, listener)
Signer:
msg := []byte{1, 2, 3} peerNum := uint32(3) homo, _ := paillier.NewPaillier(2048) // get result from DKG (for employee) result, _ := employeeDKG.GetResult() // get result from DKG (for director) result, _ := directorDKG.GetResult() // two of employees and the director signerPeerManager := newSignerPeerManager(id, peerNum, signers) mySigner, err = signer.NewSigner(signerPeerManager, result.PublicKey, homo, result.Share, result.Bks[id], peerBks, msg, listener)
Benchmarks:
Our benchmarks were in local computation and ran on an Intel qualcore-i5 CPU 2.3 GHz and 16GB of RAM.
GG18(Paillier case):
- Threshold: 3
- Three shares with ranks (x, share, rank): (108, 4517821, 0), (344, 35822, 1), (756, 46, 2)
- Public Key: 2089765*G
- The bit-length of Paillier public Key: 2048 (ref. Appexdix )
- curve: S256
(Ran 10 samples)
+-----------------+--------------------------+------------------------------+ | Fastest Time | Slowest Time | Average Time | +-----------------+--------------------------+------------------------------+ | 0.719s | 1.150s | 0.902s ± 0.125s | +-----------------+--------------------------+------------------------------+
For CCLST:
- Threshold: 3
- Three shares with ranks (x, share, rank): (108, 4517821, 0), (344, 35822, 1), (756, 46, 2)
- Public Key: 2089765*G
- The security level: 1348(i.e. the bit length of fundamental discriminant) (ref.)
- distribution distance: 40 (cf. Section 3.1 )
- the challenge set C: 1024 (cf. Section 3.1 )
- r1 challenge bit translation: 40 (cf. Section 3.1 )
- curve: S256
(Ran 10 samples)
+-----------------+--------------------------+------------------------------+ | Fastest Time | Slowest Time | Average Time | +-----------------+--------------------------+------------------------------+ | 2.452s | 3.754s | 3.229s ± 0.396s | +-----------------+--------------------------+------------------------------+
Appendix:
Security levels of two homomorphic schemes:
The Table below is referenced by Improved Efficiency of a Linearly Homomorphic Cryptosystem .
+-----------------+--------------------------+-----------------------------------+ | Security Level | RSA modulus (Paillier) | fundamental discriminant ΔK (CL) | +-----------------+--------------------------+-----------------------------------+ | 112 | 2048 | 1348 | | 128 | 3072 | 1828 | | 192 | 7680 | 3598 | | 256 | 15360 | 5972 | +-----------------+--------------------------+-----------------------------------+
Useful Cryptography Libraries in this Repository:
- Binary quadratic forms for class groups of imaginary quadratic fields
- Castagnos and Laguillaumie homomorphic Scheme
- Paillier homomorphic cryptosystem
References:
- Fast Multiparty Threshold ECDSA with Fast Trustless Setup
- Bandwidth-efficient threshold EC-DSA
- Hierarchical Threshold Secret Sharing
- Dynamic and Verifiable Hierarchical Secret Sharing
- Linearly Homomorphic Encryption from DDH
- Improved Efficiency of a Linearly Homomorphic Cryptosystem
- A Course in Computational Algebraic Number Theory (Graduate Texts in Mathematics)
- Maxwell Sayles: binary quadratic form
Other Libraries:
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
移动应用的设计与开发
[美] 弗林 (Brian Fling) / 马晶慧 / 电子工业出版社 / 2010-5 / 59.80元
本书全面介绍了如何在移动设备上设计和开发应用程序。书中从介绍移动产业的生态环境和移动媒体开始,阐述产品策划的方法、产品架构、视觉设计和产品类型的选择,并详细描述了产品实现过程中所用到的一些技术、工具和概念,最后还简单介绍了如何获得利润和降低成本,肯定了iPhone在移动设备发展史上起到的巨大推动作用。本书不仅能让读者了解到移动设计和开发的知识,更重要的是,它揭示了移动开发的代价高昂、标准混乱的根本......一起来看看 《移动应用的设计与开发》 这本书的介绍吧!