Martin Geisler <[EMAIL PROTECTED]> writes: Hello again,
> I have thought a little about how we can split the current Runtime
> class into smaller pieces. Currently runtime.py contains five classes
> and the Runtime class contains 26 methods. That is too much
> information in one file. I think we can group the methods like this:
Now that we have a Bracha broadcast the Runtime class has grown a bit
again :-) I would really like to divide it into smaller parts so that it
becomes easier to hack on.
I suggested a hierarchy like this:
* BasicRuntime
* PassiveRuntime
* ActiveRuntime
with two mixin-classes:
* ComparisonToft05Mixin
* ComparisonToft07Mixin
Was there an agreement that this would be a good idea?
I ask because I am slightly in doubt myself... for example, where do we
put the PRSS functionality? I guess prss_share can be used in the
presence of both passive and active adversaries since it only relies on
a secure broadcast which we now have in both cases. So PRSS should be a
mixin class too?
What about prss_share_random, the one where a random value is picked
without communication. Is that actively secure? What happens if a player
selects a wrong random share for himself?
Depending on where the PRSS functionality ends up, the convert_bit_share
method might or might not be suitable for a mixin class too.
So in the end I hope PassiveRuntime and ActiveRuntime will turn into a
small set of core methods and then we have a large number of methods
which can use either of them.
--
Martin Geisler
pgpKzQKFKorBW.pgp
Description: PGP signature
_______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
