Re: [viff-devel] SMCL security notion

[Janus Dam Nielsen]

Hi Martin,


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.



It is not clear to me how you can describe the server as one entity
with one state when it is really a set of computers -- are you
thinking of the product state for S1, S2, and S3? Is that state even
well-defined in an asynchronous network setting, or do you assume that
the coordinator synchronizes the network?
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.



You say that the adversary can observe the trace which shows how the
configuration change on the server, but with secret values masked out.
Shouldn't the adversary be able to see the secret values of the server
parties he has corrupted?

A server is not a client, so a server only has shares of secret values.
We assume that the adversary at most corrupt a number of servers upto  
the threshold. If he corrupts more, then all our security guaranties  
are off.
So assuming that the adversary does not have access to the secret  
values is not a problem.




Oh, and using the term "semantic security" in Section 4.5 is
unfortunate since it already has a standard definition in
cryptography:

  http://en.wikipedia.org/wiki/Semantic_security


Thanks

--
Janus
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Re: [viff-devel] SMCL compiler status

[Janus Dam Nielsen]

Hi again,

While reading the progress repot I also looked at the code of the
compiler to get a feeling for what it can and cannot do.

Please correct me if I'm wrong, but it seems to go through a number of
standard phases not related to cryptography. Then there are these
three phases:

Yes there is a bunch of standard phases.


* Checking of annotations for open() calls -- I think this is part of
  the analysis in DefiniteAssignment.java.
The checking is done in AnnotationAnalysis.java, which is part of the  
DefiniteAssignment phase.
The code in AnnotationAnalysis.java is currently commented out, it  
needs to be upgraded to changes in the analysis framework used.



* Hoistability check which looks for I/O or assignments to public
  variables in the branches of if-statements.

Yes


* Conditional expansion where if-statements are turned into
  conditional assignments. Loops are also detected in the branches.


Yes



I found no support for

* Making things run in parallel (the word "parallel" does not occur at
  all in the source code).
There is no concept of parallelism in SMCL programs. The fact that  
the computation is distributed is abstracted away.



* Bounds checking when the protocol needs inputs to be smaller than
  the field size (needed in comparisons and new Paillier two-player
  runtime).
I haven't been aware of this being an issue. We need to handle this  
somehow.



* Counting multiplications and other stuff for preprocessing.
NYI. The multiplication optimization I implemented last week haven't  
been committet yet. It needs more integration with the rest of the  
compiler.


--
Janus

___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk