Insecure Keys

[urandom2]

From @arnottcr on January 16, 2015 4:14

Based upon how I am reading your data/prefs.js file, it seems like the key that the user sees or enters is a string version of of the crypto-key or keypair. This allows for insecure keys, there are several solutions. GPG forces unique key generation, this means that you have to share a key file, not a simple string making it less user-friendly but more secure. Another option is to use a key derivation function like bcrypt to generate the keys. This has the advantage of being user friendly and not as insecure, but if two people want "cheese" as their password, they will have identical "secure" passwords. A side note, I need to look up how secure using a kdf for key material generation is, but as long as you use binary field ecc, it should be fine. [ie. Does not work for RSA or ecc over prime field] Furthermore, this method makes private keys that while secure have two different ways to being shared: with the kdf password or directly in binary. Each has advantages and disadvantages, but both force pubkeys to be directly in binary. There is no shorthand to share just the pubkey because you are not supposed to be able to push a kdf the other direction. I like option one, but it requires pki.

Copied from original issue: winhowes/grd.me#4

[urandom2]

From @winhowes on January 24, 2015 20:10

Let me know what you end up thinking is the best direction on this one. I've currently restricted the minimum key length to 6 characters

[urandom2]

I really like the gpg implementation for generating keys. They generate secure keys from a random source then store them securly on disk. There is no place for user error, the default generates fairly secure keys and advanced users can generate better keys, but the software works with all.

With a 6 char minimum you are allowing log2(94^6)=~40 bit keys, no?

I think here we should really be doing the same. For this we will need a dedicated way to pass public keys. I think we should allow the user to have several options and choose the easiest to them. I think we both like the stego pubkey idea, so we should offer this. Also, we should offer a text dump of the pubkey that can be submitted to a place like Facebook. We can offer a public key infrastructure as well. Finally users should be able to export and import their key-rings.

I really like the concept of never having shared or long-term secret keys, with everything being encrypted using ephemeral keys. I think that we can leverage the power of axolotl to keep the round trip times down to one, and still allow group messaging. This does require that message recipients be known before sharing a message, which while a cost allows us to always have pfs.

I would really like to stay away from KDFs, as they make a one way linkage between a password and key, that is forever. As long as you remember the password, someone can rubber-hose that key out of you. The exception to this is for securing your keyring: generate a random symmetric key for use encrypting the keyring, create a kek with a kdf and save that to disk, then for decryption use the passphrase to recover the symmetric key.

[urandom2]

From @winhowes on January 31, 2015 6:49

Public key infrastructure set up :) #5

Right now how it works is it uses the key you enter to generate a 256 bit key. And so there is a 6 character minimum, but the generate button will produce a 64 char key, so ~419bits, which then gets mapped into a 256 bit key. I like the flexibility of people being able to generate their own keys and with the generate button I don't think that it's that bad. I agree with your statement about KDFs as long as the user remembers the password, but with the generate button they wouldn't remember the password so I feel like it'd be fine. No?

As for PFS, I think I may have a way to do it without knowing group size. I'll need to think it over a bit, but I think I have something. If not I have another idea which will give users the option to use pfs and force them to define their group size rather than forcing that on everyone (that makes things like posting encrypted tweets hard)

[urandom2]

Alright, so it looks like with base64 encoding you get 6 bits per character, which is the same thing that pgp does for ascii armoured keys. I think it is important to give the user the ability to share their pub keys via the clipboard, but we should try to encourage them to use other methods first [stego, pki, etc.] and allow them to use the clipboard as a backup. What do you think about preventing the user from directly accessing private keys, aside from a keyring backup file?

Lets discuss on Monday, or I will writeup then if you cannot meet, how we want to implement pfs.

[urandom2]

From @winhowes on February 1, 2015 7:50

Yeah let's discuss this one on Monday. I think you've brought up a lot here that has been on my mind for a while.

[urandom2]

I think the current implementation is sufficient, there are a few quibbles that I have about small things, but most of them will become fixed or irrelevant if we move to pfs. So I think it would be more useful to place our efforts there. I will go ahead and close this, feel free to reopen it if you feel it is unresolved.

[urandom2]

From @winhowes on February 3, 2015 4:7

sounds good. Feel free to post those thoughts/quibbles in pfs topic