1. 1
  1.  

  2. 3

    Maybe now would be a good time to talk about limiting the number of tags to the best 3?

    1. 1

      I tend to agree. That seemed strange.

      1. 1

        Which three tags do you want? I can change the tags on the post.

        1. 1

          lets cut it down to distributed, go, programming.

          1. 1

            Done.

            1. 1

              ty

    2. 2

      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 that route.

      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.

      1. 1

        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!

        1. 2

          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.

          1. 1

            I agree 100% if you’d like to help with those pages we could use a hand!

      2. 1

        The problem is ease of use versus expert friendliness. OTR leads in the paranoid and something like telegram leads in average Joes.

        1. 2

          Open Whisper Systems' Text Secure and Signal are stellar, usable, and secure messaging systems.

          1. 1

            I can’t speak to text secure but I have used signal before and it’s great.