Interesting project, but I do have some questions. “Industry leading
encryption” doesn’t tell me much. It would be really nice to see a
documentation section on the crypto and how it relates to your protocol,
with some discussion as to the thinking behind it. The godoc, which
seems to only describe how to use it as a programmer, tells me it’s “ECIES and
AES-256 encryption”, but that leaves a lot of gaps: what curves are
being used, what block mode, etc… I ended up digging around the code,
but I happen to do a lot at work with Go and cryptography, so it’s more
natural for me to do; I don’t think users shouldn’t have to take that
From digging in the code, it looks like AES-256-CBC with HMAC-SHA-256,
using the NIST P256 curve, which isn’t really standard (typically, P256
with AES-128-CBC and HMAC-SHA-256, or P384 with AES-256-CBC and
HMAC-SHA-384). Maybe the site could clarify what industry it’s standard
for to give some background. This isn’t to say the choices are wrong,
it’s just unusual to see a curve designed for a 128-bit security level
used with AES-256, and to see HMAC-SHA-256 used with AES-256. The site
also says it uses the same technology as Bitcoin, though it uses a
different elliptic curve than Bitcoin (secp256r1 in EMP, secp256k1 in
Bitcoin). I’m not familiar with Bitmessage’s cryptographic choices, so
I’m not sure if it’s using the same design or not.
This is all to say that I’d be interested in reading more about your
design choices, where they came from, etc. I’d also love to see a
security model and an explanation to an end user as to when they should
use this, where it’s applicable, how to safely use it, etc… I think
adding user documentation will go a long ways to helping your product.
Duly noted. I’ll work on that. We were trying to avoid going deep on a consumer facing page. We’re still missing a lot of documentation. That’s something that is in the works. There’s also another client/interface in the works right now. Thanks for the feedback!
It doesn’t have to be the first customer facing page, either. Just as
long as there’s an (easy to find) discussion somewhere in the docs. I’d
also argue that your consumers should have deep technical docs on the
security of the package, particularly since this is a package built on
the premise that it uses secure cryptography.
I agree 100% if you’d like to help with those pages we could use a hand!
Maybe now would be a good time to talk about limiting the number of tags to the best 3?
I tend to agree. That seemed strange.
Which three tags do you want? I can change the tags on the post.
lets cut it down to distributed, go, programming.
The problem is ease of use versus expert friendliness. OTR leads in the paranoid and something like telegram leads in average Joes.
Open Whisper Systems' Text
Signal are stellar,
usable, and secure messaging systems.
I can’t speak to text secure but I have used signal before and it’s great.
We’ve been wrapping up emp, our encrypted messaging protocol. We’re working on cleaning up a few bugs and can always use an extra set of eyes: