[EMAIL PROTECTED] writes:
> Hello,
>
> My reaction to it is make a note of it and go on.
Good idea! I have just put it in the TODO file (rev 8eb7e1dc4069).
> As VIFF only works for passive adversaries this is not a problem at
> the moment, but it should be noted so we do not forget about it when
> the time comes to protect against active adversaries. By then they
> might have fixed things in the underlying structure.
That would be nice! :-)
> On a side note I have a proposal for how to limit/standardize the
> size of the packets. Currently if I understand correctly each
> operation is given a number and a subnumber and so on. E.g.
> 11.3.6.2.1 this might expand to quite a number of elements if you
> have to go real deep into the tree.
Correct, but I don't think this is a real problem since the depth of
the tree will normally be quite small.
The tree is determined by the stack depth when the methods in the VIFF
runtime call each other. Each time a method decorated with
@increment_pc calls another decorated method, we enter a new level in
the tree.
Tomas and I have previously discussed other ways to keep track of the
program counter, but they all ended up growing in size proportional to
the depth of the *dependency tree* between the variables.
So in a program like this
x = a * b
y = x * c
z = y * d
the variable z would depend on all others:
z
/ \
y d
/ \
x c
/ \
a b
We do not want a scheme where z would carry a program counter of
length 4 in this case. And so the current scheme wont do that. If the
program counter start at [0] before the assignment to x, then it will
grow like this:
x = a * b -> [1, 0]
y = x * c -> [2, 0]
z = y * d -> [3, 0]
Now that I study the code again I believe I have found a bug: the
callback method in Runtime does not increase the program counter, and
so in mul, both _shamir_share and _recombine sees the same program
counter. And _recombine doesn't even need the program counter since it
simply calls shamir.recombine. Oh well, I better try and fix that...
Thanks for prompting me to look over this once more -- the program
counter code is deep magic, I'm afraid :-/ It also took quite a while
to get it to the code you see today, previously you had to increase
the PC yourself at the correct moments. That was no fun!
> My proposal is to limit the size of what is sent by hashing these
> values. Into a fixed 64 or 128 bit value. Then keep a list of
> possible operations and their corresponding hash values in each
> node. This list of hashes might grow quite big, but in my view it
> might still be manageable.
>
> For loops and such we have to define a max number of iterations or
> have a small counter along with this hash value.
The cool thing about the current scheme is that loops don't increate
the number of components in the program counter -- they only increase
one of the counters.
> [...]
>
> Assuming binary encoding (but we could also go for encoding in
> ascii) The packet for shares are then as follows:
> 1-byte version number (01)
> 1-byte packet type (01 - for shares)
> 4-byte salt
> 1-byte X number of shares are in this packet
> Repeated X times:
> 8 or 16-byte of hash value
> log(p)/8-byte share value
I definitely think we will eventually need something like this -- a
format where each packet is a number of plain bytes that can simply be
read and turned into integers quickly and securely.
--
Martin Geisler
_______________________________________________
viff-devel mailing list (http://viff.dk/)
[email protected]
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
