3 ms·
It uses a trapdoor commitment function. It does not have a “trapdoor” or “backdoor”. The problem is not so much in the implementation of the function, but in t
by zaroth 8y ago
It uses a trapdoor commitment function. It does not have a “trapdoor” or “backdoor”.
The problem is not so much in the implementation of the function, but in the generation of parameters required by the function. The machines need to follow a particular scheme to generate the parameters of the function in order for the commitment to be secure. Think, e.g. of ZCash, where if the initial ceremony is not completed in a specific way and trusted, then the entire system after that has specific weaknesses.
In this case, if the parameter generation is not done correctly, or if randomness generated by clients is compromised, votes can be altered.
Now one of the issues is generating random group elements. Reading one of the linked notices [1] it talks about best practices of generating a random group element.
I don’t understand exactly all the terminology in the paper (even though it is quite trivial) but it looks to me like it is talking about generating effectively a public key in an EC system.
One way to do it is to generate a random integer r between 0..q-1, which is effectively the private key, and then generate the corresponding public key by doing g^r mod p.
The problem with this approach is that in the process the machine generating the public key knows the private key. It could be thus saved or leaked.
Instead you can generate a public key directly. This requires randomly selecting a value and checking it is valid (r/p=1), which is more expensive, or alternatively select a random r in Z and return r^2 mod p.
Finally, the generation process itself must be proveably fair and random (e.g. some sort of blockchain ceremony) to be trusted.
Fundamentally the Swiss system does not specify a ceremony for trusting the parameters used by its Pedersen commitment scheme, and therefore even if the implementation is perfect it still is not secure.
Still reading...
[1] - https://s68aa858fd10b80a7.jimcontent.com/download/version/1552395686/module/7833161661/name/PIT1.pdf https://s68aa858fd10b80a7.jimcontent.com/download/version/15...
- rocqua 8y agoIf all that's needed is a public key without known private key (i.e. some element Ga with a unknown) then a simple ceremony is possible. Anyone who wants gets to submit a value H_i = G a_i. With a proof that H lies in the correct subgroup. Then the final value can bu the sum of all H_i s. The final private key would be the sum of all a_i s. If even one of those private keys is unkown, the final value is also unknown.
- nullc 8y agoYou don't need any such "ceremony" for this sort of protocol, no trusted setup is required at all: you can use a hash function to select random group elements. All thats required is that that the dlog between the respective group elements is unknown, they don't need special properties other than that. This makes it unlike the trusted setup of things like zcash (as mentioned in the grandparent post) which cannot be simply initialized randomly.
- rocqua 8y agoI don't know anything about how elliptic curve points are represented in memory, so I thought using a hash-function is difficult. If that's not the case, then there is no problem. Using hashes as 'nothing up your sleeve' numbers.
- nullc 8y agoThere are fairly straight forward options for this sort of thing... the simplest of which is you hash onto the field and check if the result is on the curve by applying the curve equation (which it will be with probability 1/2). If it is, you are done, if not increment the hash input and repeat until done. There are fancier ways to hash onto curves that can give nearly uniform points in constant time, but they're curve specific... and for parameter generation you don't need constant time.