Hi
I'm not sure I understand completely the distinction between multiple
inheritance and mix-ins. I guess I'd better go read a couple of pages
in Learning Python before I say anything.
But in my opinion, an important issue is encapsulation of protocol
implementations. I think a typical user of the runtime would prefer to
simply invoke compare() on the runtime rather than, say,
compareToft05() or compareToft07(). By typical user I mean e.g. a
compiler or a programmer that is developing a higher-level
application. Will the mix-in approach allow the runtime to hide the
actual implementation of a protocol like comparison? Perhaps except in
a single place, where the user tells the runtime what protocols to
use.
If not, we would have problems like this: A programmer implements some
large application, say, a quadro-auction, involving thousands of lines
of code with calls to compareToft07(). Then Tomas Toft happens to
invent an even faster comparison, compareToft08() ... which I guess is
not unlikely ;). The programmer will then have to rewrite his
application, changing all calls to compareToft07() to compareToft08()
in order to use the fastest available comparison.
Best regards,
Thomas
On Jan 31, 2008 4:54 PM, Janus Dam Nielsen [EMAIL PROTECTED] wrote:
Hi Martin,
I am not so confident with the code base that I can judge which
methods goes into which classes. So I am just going to tell you about
cohesion. In OO programming one should strive to achieve as high a
degree of cohesion for each class as possible. That is each class
should serve ONE specialized and well defined purpose. Hence I think
it would be great to split the Runtime class into multiple pieces.
Mixins are the think you would want to use in the case of your
comparisons, since it is not something which is only well defined for
one protocol, but a given comparison make sense for multiple protocols.
--
Janus
Den 31/01/2008 kl. 4.40 skrev Martin Geisler:
Hello,
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:
Basic infrastructure: These methods are not specialized to deal with
crypto as such, they simply provide a means for players to talk with
each other:
* __init__
* add_player
* shutdown
* wait_for
* synchronize
* callback
* _exchange_shares
Protocols for passive security. This includes Shamir sharing, PRSS,
and opening of such shares:
* shamir_share
* _shamir_share
* _recombine
* prss_share
* prss_share_random
* open
We also have the basic protocols for doing arithmetic with shares:
* add
* sub
* mul
* xor_int
* xor_bit
Then comes the comparison protocol from Tomas' progress report, also
knows as the SCET comparison protocol:
* greater_than
* _finish_greater_than
* _diamond
* convert_bit_share
The final group would be the newer comparison protocol, also by Tomas:
* greater_thanII
* greater_thanII_preproc
* greater_thanII_online
* _finish_greater_thanII
* convert_bit_share_II
I propose that we split the Runtime class into these classes:
* BaseRuntime containing common code needed by all runtimes.
* PassiveRuntime inheriting from BaseRuntime with the standard
Shamir-based protocols.
The comparison protocols could live in their own classes, maybe named
* ComparisonToft05Runtime
* ComparisonToft07Runtime
for a lack of better names. These classes would not inherit from
PassiveRuntime since they can also be used with a runtime that
provides protocols for active security.
So they could be made as mix-in classes instead. That is a class that
you inherit from if you needs its functionality, please see
http://en.wikipedia.org/wiki/Mixin for some background.
A combined runtime class could then be made as
class Combined(PassiveRuntime, ComparisonToft05Runtime): pass
or
class Combined(PassiveRuntime, ComparisonToft07Runtime): pass
depending on your need. The comparison protocol would be present in a
greater_than method in both cases. When we have an ActiveRuntime
class, then programs may define their runtime class as
class Combined(ActiveRuntime, ComparisonToft07Runtime): pass
I guess none of us is used to mixin classes, but the advantage as I
see it is that we avoid the problem of blessing one particular
protocol as the right one. We could of course also make the
inheritance hierarchy so that there is a ComparisonRuntime class that
inherits from PassiveRuntime and implements a particular comparison
protocol. But then how would we easily reuse that code for the active
case? A simple dot graph showing that I mean in the case where we use
normal
