Hello, My reaction to it is make a note of it and go on. 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.
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. 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 end result is that we standardize the packet sizes more than we do today. Any hash value that is not recognized is discarded, thereby avoiding a flooding attack. To avoid collisions and to add uniqueness each time we do some MPC we uses an unique salt. Using a 128 bit hash a collision is extremely unlikely, but if one is found then we can change the salt value. 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 Tord Siterer Martin Geisler <[EMAIL PROTECTED]>: > Martin Geisler <[EMAIL PROTECTED]> writes: > > Hi again! > >> We use the marshal module in the ShareExchanger class to, well, >> marshal data in shares before they are exchanged. [...] > > I forgot to add that the solution to this should be easy in our case. > We only send very simple data over the network: > > * Program counters which are tuples of integers. > > * GF256 objects which contain a single byte for the value. > > * GFElement objects which contain a long int prime modulus and a long > int value. > > I think that is it, which means that we can use something like the > struct module for packing the 32-bit integers into bytes and something > a little more complicated for the long integers. > > When we start using the GMPY module again for the big integer > arithmetic, we might be able to use the gmpy.binary function. But I > don't know how that function will handle arbitrary binary data... > > In both cases we should know in advance how many bytes to read (since > we know the field size), so we can simply always read that many bytes. > > > All this business about protecting against malicious input data is of > course somewhat silly now when VIFF assumes a passive adversary. But I > think it is good to think about it already now since it will make > things easier for us when we begin looking at security against active > adversaries later on. > > -- > Martin Geisler > _______________________________________________ > viff-devel mailing list (http://viff.dk/) > [email protected] > http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk > > _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
