[CiPHPerCoder]

I'm starting to look through the code right now. A scroll through their open source page indicates they're using libsodium, which is a good sign that they avoided most of the foot-cannons alluded to on this page: https://gist.github.com/tqbf/be58d2d39690c3b366ad

[lisper]

The SpiderOak folks seem to know what they're doing. But if you don't trust them, here's a completely open secure communications tool:

https://github.com/Spark-Innovations/SC4

It's based on TweetNaCl, libsodium's smaller sibling. It can run standalone, i.e. no server required.

No group chat yet, but that's a relatively straightforward extension. I have two-party chat working in private beta. (Chat does require a server, though.)

[CiPHPerCoder]

> The SpiderOak folks seem to know what they're doing.

I'm inclined to agree with that assessment.

> But if you don't trust them

Trust, but verify.

IIRC they were discussing hiring a friend of mine (whose knowledge in software security is something I respect greatly).

[dchest]

I wonder why they don't use golang.org/x/crypto/nacl instead of bindings to C library (libsodium-go). All primitives in it are implemented in assembly (for amd64 arch), so speed shouldn't be a concern.

[rarrrrrr]

Great question!

We really wanted to use the pure go implementation, but it doesn't cover as much functionality. Detached signatures for example.

[dchest]

Ah, yes, there are no signatures in x/crypto/nacl. There's https://github.com/agl/ed25519, however it will be slower, as there's no assembly.

Edit: oops, looks like signatures were added 2 months ago (https://github.com/golang/crypto/blob/master/ed25519/). (I guess it's the same agl's code). There is a detached version (Sign/Verify).