Janus Dam Nielsen <[EMAIL PROTECTED]> writes: Hi everybody
>> I am confused about the notion of security via adversary traces >> presented in those papers. It is described via two properties: >> >> * Identity Property: a public state P can only lead to one other >> public state P', regardless of the secret state. >> >> * Commutative Property: computing on secrets leads to the same >> state as opening everything and computing on open values. >> >> I think you write that this is a new idea -- have you then looked >> into how this relates to the more standard notion of Ideal >> World/Real World simulation arguments in the UC framework? > > Yes this is a new formulation of the security guaranties in the > programming language community. I have not compared this to UC, it > would be nice to do so. Yeah, it would be good to see the security formulated in a standard way... > In the paper on page two, lower left, we write that each server > party execute identical copies of the server program inn lock-step. > Based on this assumption it is reasonable to consider the server as > having a single well-defined state. However in Viff this is no > longer true due to parallelism. But it would be very nice if we > could consider the server as having a single well-defined state. I don't like this since it introduces a wide gap between the model and the real world and I believe such a gap makes it easier to come up with inefficient solutions. Sure you can implement a synchronous network on top of an asynchronous network, you can run expensive agreement protocols to ensure that everybody has seen every message and that they are all delivered in the same order. I'm thinking of protocols like those described in these notes: http://www.zurich.ibm.com/~cca/sft08/viewsync.pdf http://www.zurich.ibm.com/~cca/sft08/byzantine.pdf which are from a course I took at ETH Zurich. The message I got away from that course is that such protocols are expensive, so assuming that 3 (or more!) computers operate in lock-step is something which I would rather avoid. -- Martin Geisler _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
