search

Everybit-legacy / everybit.js

Secure messaging and username management
http://www.everybit.com
75 stars 9 forks source link

Key generation proposal #25

Closed jrootham closed 10 years ago

jrootham commented 10 years ago

There should be several options for key generation when signing up. 1) Press a button and get a randomly generated passphrase. 2) If you don't trust the RNG enter dice rolls to generate a passphrase. 3) If you are suspicious of the site, download a python script and word list and use it to generate a passphrase. Paste an obscured version of the phrase into the site (obscured to prevent users from entering dumb passphrases). 4) If you are completely paranoid, enter the public key.

See git repositories jrootham/randomWords and jrootham/passphrase for the python version.

jaromil commented 10 years ago

Hi there, I'm following your developments with great interest, thanks!

What size a key need to be? In the Tomb script we also have key generation (256 bytes long) functions that ascii armor and symmetrically encrypt the results using GPG. It is a transportable way to store key files and Tomb offers ways to steganographically hide it into jpgs or backup it into printable QRcodes to be stored in books.

https://github.com/dyne/Tomb

I'm just wondering if there is something reusable for you in our script or even if we can support key generation also for puff/freebeer based systems.

jrootham commented 10 years ago

Ah, I might have mistitled the issue. I am talking about generating passphrases, which are then used to generate keys. My phrases are 6 words long, each generated by 6 die rolls. XKCD on steroids. Something over 90 bits of entropy.

My understanding is that we are using elliptic curve algorithms from bitcoin. Not sure how long the resulting keys need to be. Shorter than RSA in any event.

On Sun, May 11, 2014 at 3:24 AM, Jaromil notifications@github.com wrote:

Hi there, I'm following your developments with great interest, thanks!

What size a key need to be? In the Tomb script we also have key generation (256 bytes long) functions that ascii armor and symmetrically encrypt the results using GPG. It is a transportable way to store key files and Tomb offers ways to steganographically hide it into jpgs or backup it into printable QRcodes to be stored in books.

I'm just wondering if there is something reusable for you in our script or even if we can support key generation also for puff/freebeer based systems.

— Reply to this email directly or view it on GitHubhttps://github.com/puffball/freebeer/issues/25#issuecomment-42764033 .

Mattasher commented 10 years ago

Correct, it uses elliptic curve algos. The keys are generated from an array of 32 integers of between 0 and 255. So total bits of entropy is 32 * 8 = 256.

Each die roll produces about 2.58 bits of entropy, so you'd need about 100 of them to explore the full (usable by our ECDSA, AFAIK) space of the curve,

Mattasher commented 10 years ago

I should add that just because your algo doesn't have enough entropy to cover the full possible space, doesn't mean it's necessarily less secure. All randomness is epistemic to us humans, which means that if the other person doesn't know how you generated it, then even a limited space can be effective.

For example, suppose you pick your first 240 bits with actual coin tosses. Then, to generate each new key, you do 16 addition coin tosses. So each new key has only 16 bits of entropy, and you never explore more than a fraction of the space. However, unless someone realizes you are repeating the first 240 bits and guesses them, your alogrithm has just as much (effective) entropy as building the full 256 bits each time.

jrootham commented 10 years ago

How much entropy is necessary? At some point you are just gilding the lily.

On Sun, May 11, 2014 at 12:46 PM, Matt Asher notifications@github.comwrote:

I should add that just because your algo doesn't have enough entropy to cover the full possible space, doesn't mean it's necessarily less secure. All randomness is epistemic to us humanshttp://www.statisticsblog.com/2012/02/a-classification-scheme-for-types-of-randomness/, which means that if the other person doesn't know how you generated it, then even a limited space can be effective.

For example, suppose you pick your first 240 bits with actual coin tosses. Then, to generate each new key, you do 16 addition coin tosses. So each new key has only 16 bits of entropy, and you never explore more than a fraction of the space. However, unless someone realizes you are repeating the first 240 bits and guesses them, your alogrithm has just as much (effective) entropy as building the full 256 bits each time.

— Reply to this email directly or view it on GitHubhttps://github.com/puffball/freebeer/issues/25#issuecomment-42775757 .

jaromil commented 10 years ago

ACK. Memorable passphrase generation is also nicely implemented and explained to users by jpgen https://github.com/jtwalters/jpgen example side with docs: http://jpgen.joelwalters.com

Still worth mentioning a different scheme: non-memorable passphrases of 256bits encrypted as files and protected by symmetric encryption (shorter password). This way users can transport keys and associate them to devices (like usb, bluetooth etc.) which become keys to access the service. This authentication scheme could be at least an option, it is useful for certain installations.