[freehaven-dev] Comm Broadcasts / Crypto

[Michael J Freedman <mfreed@MIT.EDU>]

In response to Roger's points...

> I believe we decided earlier that the haven module would be doing the
> signing, as well as the encrypting?

I agree that we talked about separated the crypto libraries to reside
solely within the haven module.  However, when we've been writing the
mixnet API, this doesn't support broadcasts very well.

If you wish the haven to do all encryption/signing, then haven will
actually do broadcasts by merely querying comm for

     Node* get_available_nodes() 

which we have as a primitive, then 

     int send(Node X, char* message)

for all nodes available, as opposed to merely calling something like:

     int broadcast(char* message)

From a software design standpoint, I think it's more natural to handle
broadcasts within the comm object, rather than the haven module.  It
also significantly decreases the number of necessary socket
communications between comm and haven.  Of course, than adds a
dependency for comm on the crypto libs. 

Personally, I would choose using :broadcast() and letting comm sign 
and encrypt everything, as there are going to be many broadcasts in
the system.    Thoughts?


> I guess the only stickler is that your mixnet API only has support for
> "send this pile of bits to servnet Y", but in the case of a document
> request, the recipient isn't a servnet node.

We'll add some functionality to the comm API to provide mixnet transfer
of (assembled) documents to other destinations (i.e. nym mailboxes, etc.)


> The next question is, if shares are huge, does anybody really want to be
> keeping them in ram as strings? Or should each intermediate stage be
> building a file and then handing around a filename between modules?

> It is becoming more and more appealing to never actually "load" a file in
> the haven module, but merely hand around filenames. Should comm consider
> doing this too?

Hrm.  I think you struck an important point there.  File handles
do appear much more appealing.  Will definately consider, although this
does presuppose a greater dependence of shared resources (disk) between
haven and comm object, but I don't think that's really all that important.

I think we'll start doing/thinking about this, but need a little more
time to think of implementation factors.

Thanks,
--mike