Implementing a zero-knowledge proof of membership

[pgrinaway]

Hi,

I've been trying to implement this zero knowledge proof of membership technique. I was wondering if you had any advice on the following regarding design:

Where to put the code to create a random group generator (I had thought I could just write G::elem(Integer) where Integer is the group generator, but that doesn't seem to work--the compiler complains that there is no variant elem. Perhaps it is better to implement the random group generator function inside the group implementations?

Thanks. Apologies if not clear or if I just missed something painfully obvious.

[whaatt]

Good question; the short answer is basically that this function should live on each implementation of the Group trait, since it's presumably tied to the behavior of the group.

We have a trait UnknownOrderGroup: Group with a function unknown_order_elem that was originally supposed to encapsulate this behavior. (Here, UnknownOrderGroup refers to a group containing elements of unknown order, rather than the group itself having unknown order.)

For implementing the non-interactive argument systems in BBF, however, we realized that the generator value returned by unknown_order_elem can be the same each time, as long as the element returned has unknown order. In the case of the RSA group, we always return 2.

(Issue #43 addresses the security implications thereof.)

To implement this functionality, I'd either patch unknown_order_elem or more likely add a new function to the interface unknown_order_elem_random.

Hope this helps! Please let me know if you have any more questions.