dss with encryption as default

[sjmackenzie]

The dss has been designed to operate on open hostile networks that is the internet. It makes sense that Collet's paper didn't place strong emphasis on the topic of encryption, as he wanted to prove the concept. With this new implementation I suggest that we address this topic by defaulting encryption from the get go.

Problem:

• surveillance by organisations, governments.
• the open internet and all that lurks therein. Proposed initial (partial) solution:
• encrypt messages Long-term solution:
• networks of trust

Few systems build encryption into the core. Here we have an opportunity to engineer encryption into the very foundation, and possibly do it in such a way as not to impact porformance.

what would be the best way to introduce encryption? Shall we make good use of the delay and encrypt the payload while the loop sleeps? How do we leverage existing encryption libraries out there, given that the whole DSS will be implemented in oz. Expose a c++ API in the vm? Write our own encryption libraries in oz?

[sjrd]

I do believe we need some kind of security concerns addressed, indeed. Encryption of the messages seems a good thing to start with.

Now, I wonder: isn't encryption "just" a filter applied on the TCP streams? (after handshaking and key negotiation, of course) If this is true, is it necessary to implement it from the grounds up? Can it not be added easily later, when we have something that "works" already?

As for leveraging existing libraries, that is of course a good question. In any case, for conceptual reason I do not want to enter any encryption code in the VM core. It should be additional repo, well separated from the rest.

Moreover, we must not include or call upon any encryption library using a symmetric key greater than 64 bits in the Mozart project per se. We would have trouble with the US export laws or something like that (I'm not an expert, I just noticed SourceForge were picky about this criterion). If we want that, it must be made available through a separate project.

Now, that said, I have no strong opinion on whether we should code an encryption library in Oz or expose a C++ API. Probably the best long-term solution is to have a mechanism in the VM (or more likely the VM environment) that allows to easily load a dynamic C library and interact with it from Oz code.

[sjmackenzie]

Regarding US laws, it shouldn't affect us. Those laws are for the export of encryption technology out of the US. There is nothing AFAIR concerning the import thereof. I pretty sure this is the case. Those sourceforge projects were most likely US based.

Agree on it being a separate project and agreed on your last point regarding inclusion into the project, but this raises a hairy issue which I'll find links to shortly.

Agreed on getting it working first but the DSS should be regarded incomplete till it has encryption. Replicating those libraries in oz is a momumental task requiring peer review by hardened experts. OTOH existing encryption 'libraries' are indeed not libraries so compatibility is troublesome. It'll be difficult 'including' them into the vm.

So a bit of time needs to be invested to move forward on this properly. On Feb 17, 2013 6:43 PM, "Sébastien Doeraene" notifications@github.com wrote:

I do believe we need some kind of security concerns addressed, indeed. Encryption of the messages seems a good thing to start with.

Now, I wonder: isn't encryption "just" a filter applied on the TCP streams? (after handshaking and key negotiation, of course) If this is true, is it necessary to implement it from the grounds up? Can it not be added easily later, when we have something that "works" already?

As for leveraging existing libraries, that is of course a good question. In any case, for conceptual reason I do not want to enter any encryption code in the VM core. It should be additional repo, well separated from the rest.

Moreover, we must not include or call upon any encryption library using a symmetric key greater than 64 bits in the Mozart project per se. We would have trouble with the US export laws or something like that (I'm not an expert, I just noticed SourceForge were picky about this criterion). If we want that, it must be made available through a separate project.

Now, that said, I have no strong opinion on whether we should code an encryption library in Oz or expose a C++ API. Probably the best long-term solution is to have a mechanism in the VM (or more likely the VM environment) that allows to easily load a dynamic C library and interact with it from Oz code.

— Reply to this email directly or view it on GitHubhttps://github.com/mozart/mozart2/issues/16#issuecomment-13683958.

[sjmackenzie]

link in question: http://mrmekon.tumblr.com/post/12199418635/gnupg-is-not-a-library

this might be a solution. The netbsd guys are pretty solid [pdf] http://www.netpgp.com/KeyConvergence.pdf

[sjmackenzie]

okay I've done my homework.

as I'm building a product around mozart that requires strong encryption thus I really need the dss to support it. I think a good way forward is using CurveCP and NaCL. all code wont touch the vm and will be put into the boost part of the code. I really want to use curvecp as authentication isn't based on IP addresses. it replaces the tcp stack totally.

please read this blog post and the related links. http://hintjens.com/blog:34 http://hintjens.com/blog:35 negative: lastly it possibly impacts how a ticket is constructed, as each peer needs to know the public key of other peers.