I don't think this really solves any actual crypto problems. I also suspect it's pretty hard to solve any of the big problems while retaining this level of simplicity. But I'm sure you'll learn stuff along the way. More inline.
On Fri, Apr 17, 2015 at 12:04 PM, Ron Garret <r...@flownet.com> wrote: > > On Apr 17, 2015, at 11:26 AM, z...@manian.org wrote: > > > At some level, this is in the same conceptual space as Peerio / Minilock. > > That’s right. > You should take a look at reop as well which is an even older nacl PGP clone. https://github.com/tedu/reop > > > The primary notable difference I see is you have used a binary format > for keys and messages. > > That’s not the main difference that I claim. The message format is almost > irrelevant (except insofar as SC4 messages are fairly compact and easy to > parse). The main advantage I claim for SC4 is the combination of > reasonable security and low friction. > > > Minilock uses a compressed curve25519 point without any metadata as > public key. This is more compact than your format. It'sBase58 encoded it is > tweetable which is very nice. > > SC4 and Minilock use the same underlying crypto. The reason SC4 keys look > longer is that it gives you separate keys for signing and encryption. But > SC4 keys could be easily made tweetable if people cared about that. > NACL encryption is authenticated. The shared secret is used in the MAC as well encryption steps. If all you want is an encryption app, you don't need a ed25519 signing key as well. If you want signing as well as encryption in your set of capabilities, you could use the system for converting curve25519 keys to ed25519 keys that TextSecure uses but you need a full curve implementation rather than just the NACL apis. > > > Minilock uses JSON for the message format rather than a binary format. I > also really like using a protocol buffers for message formats which is what > TextSecure does. > > These are things that only technical people tend to care about. I’m > trying to optimize for low friction to encourage non-technical people to > use it. > > This is mostly minutiae but because JSON doesn't specify ordering of fields, it's somewhat annoying to implement signed objects is JSON though there is http://jwt.io/. Protocol buffers free users from writing their own binary parsers. I think it lowers the barrier to implementation for others. > > It looks like your key portability strategy is for users to manage their > keys directly as file they provide to instances. Peerio has switched to > providing users with a wordlist from which the private key can be derived > through a KDF for portability. > > My intent is to build a key server that will make the key sharing process > seamless. But I wanted to start with a completely standalone version to > make sure I didn’t have any obvious problems with the crypto first. > > rg > >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
