4 ms·

We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see

by maxtaco 13y ago

We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes? If you think yes, then you are making a strong judgment about the relative difficulty of two very different problems in Crypto that are thought to be quite hard. I realize there are issues surrounding coming up with good k's and keeping those k's secret; are these issues at the core of people's objections?

lifeisstillgood 13y ago
As the article pointed out, what if your key (AES_k) is compromised? I mean what is the point of storing `AES_k(p,q) if k is random` unless you keep k somewhere? What do you use that for? I like the idea of a common way of proving one owns certain social identities. It is probably worth pointing out that the level of trust we give varies - Google "trusts" I own the domain when I put their random key on my homepage. Its not the kind of trust we would send (a lot of) money using, but its the level you guys seem to be aiming for - its a good level in a fair society.
- maxtaco 13y ago
  k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.
  - tveita 13y ago
    So when you say "if k is 256 random bytes" it's a flat out lie? e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.
    - maxtaco 13y ago
      It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.
      - tveita 13y ago
        Well, no, my concern is still to tell people to stay away from Keybase.io, or if they have to use it, to not upload their private key even though it seems to encourage you to, or if they have to upload their key, to use a really strong password and not use the key for anything else. In that order. I think that asking people for their private key is a bad thing that bad sites do. A password derived key isn't random, and no amount of key stretching or pretending will change that.
        maxtaco 13y ago
        Many Random Oracle crypto proofs assume a value is random and then substitute in something that's not quite so good, so I think it's a valid thought experiment. And some passwords do have 256 bits of randomness (i.e., ~15 random words from the dictionary). I think we disagree on what margin of password security we feel comfortable with.
        tveita 13y ago
        Right, in random oracle proofs you assume that values are random, and then you replace them with something that no one can distinguish from random. Then you consider it broken when someone finds a distinguisher requiring three exabytes of output, because any distinguishable non-randomness breaks the proof. It's trivial to make a distinguisher for user passwords. Just guess "password". There's an inherent difference between random keys and chosen passwords. Random keys, used correctly, are secure. Passwords just give you a chance to provide your own security, and most people fail to do so. No one are picking 15 random words from a dictionary to make their passwords. Passwords are one of the weakest links in IT security, on par with the people, and I don't think making them more of a single point of failure is the way to better security. That's what widespread 2-factor authentication was getting us away from. Have you tried cracking uploaded keys to check the strength of the passwords?
  - lifeisstillgood 13y ago
    Can I suggest that feature is a distraction from your core offering and a really big negative perception problem. Almost everyone who will use this for the first x years will be technically savvy - for example having heard of PGP. And as such they will have seen a hundred "secure" sites that try and keep passwords and keys on the server - do not associate yourself with that level of security obfuscation. Cut some code out of your codebase, keep your marketing message small and tight - and offering to also sync keys across devices is not a tight message.
davmre 13y ago
Imagine that Keybase is compromised. It starts serving a password-prompt page that looks identical to the previous, but now sends your decrypted key straight to the malicious attacker. Storing your private key on Keybase allows Keybase to become a single point of failure, which pretty much defeats the whole point of distributed social verification in the first place.
- maxtaco 13y ago
  We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe. BTW, this argument does not extend to the CLI or other uncompromised clients. People who sync their private keys across devices with the CLI are unaffected.
  - peterwwillis 13y ago
    I'm confused. It sounds like users are able to sync their private keys with the CLI, or with the web interface. It also sounds like if they do it with the web interface, they are at risk, whereas with the CLI they are not at risk. If my understanding is correct, my question is: What is the reason for this difference in security for the two use cases, and isn't there some way to provide web access without reducing security? What about browser add-ons? Client certificates?
    - maxtaco 13y ago
      A browser extension is in our (ever-expanding) todo list. We had one a few months ago, but we have to do a fair amount of work to get it back up to snuff.
- rdl 13y ago
  And worse -- it only needs to send that special password prompt page to a specific IP or user of interest, and maybe only when it comes from a mac box (if the victim is known to do auditing on a linux box, but uses it as a regular client on mac). Shipping packaged software with evil inside to ~everyone is risky because at least one user is likely to find a bug (accidentally) and try to trace/reverse/whatever (or, at the very least, if you do networked evil, some kind of IDS/firewalling). Per-user downloads, especially at time of each use, are vastly more risky; this is the "hushmail attack".
deleted 13y ago
[deleted]

by maxtaco 13y ago

lifeisstillgood 13y ago

As the article pointed out, what if your key (AES_k) is compromised? I mean what is the point of storing `AES_k(p,q) if k is random` unless you keep k somewhere? What do you use that for? I like the idea of a common way of proving one owns certain social identities. It is probably worth pointing out that the level of trust we give varies - Google "trusts" I own the domain when I put their random key on my homepage. Its not the kind of trust we would send (a lot of) money using, but its the level you guys seem to be aiming for - its a good level in a fair society.

maxtaco 13y ago
k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.
- tveita 13y ago
  So when you say "if k is 256 random bytes" it's a flat out lie? e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.
  - maxtaco 13y ago
    It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.
    - tveita 13y ago
      Well, no, my concern is still to tell people to stay away from Keybase.io, or if they have to use it, to not upload their private key even though it seems to encourage you to, or if they have to upload their key, to use a really strong password and not use the key for anything else. In that order. I think that asking people for their private key is a bad thing that bad sites do. A password derived key isn't random, and no amount of key stretching or pretending will change that.
      - maxtaco 13y ago
        Many Random Oracle crypto proofs assume a value is random and then substitute in something that's not quite so good, so I think it's a valid thought experiment. And some passwords do have 256 bits of randomness (i.e., ~15 random words from the dictionary). I think we disagree on what margin of password security we feel comfortable with.
        tveita 13y ago
        Right, in random oracle proofs you assume that values are random, and then you replace them with something that no one can distinguish from random. Then you consider it broken when someone finds a distinguisher requiring three exabytes of output, because any distinguishable non-randomness breaks the proof. It's trivial to make a distinguisher for user passwords. Just guess "password". There's an inherent difference between random keys and chosen passwords. Random keys, used correctly, are secure. Passwords just give you a chance to provide your own security, and most people fail to do so. No one are picking 15 random words from a dictionary to make their passwords. Passwords are one of the weakest links in IT security, on par with the people, and I don't think making them more of a single point of failure is the way to better security. That's what widespread 2-factor authentication was getting us away from. Have you tried cracking uploaded keys to check the strength of the passwords?
- lifeisstillgood 13y ago
  Can I suggest that feature is a distraction from your core offering and a really big negative perception problem. Almost everyone who will use this for the first x years will be technically savvy - for example having heard of PGP. And as such they will have seen a hundred "secure" sites that try and keep passwords and keys on the server - do not associate yourself with that level of security obfuscation. Cut some code out of your codebase, keep your marketing message small and tight - and offering to also sync keys across devices is not a tight message.

davmre 13y ago

Imagine that Keybase is compromised. It starts serving a password-prompt page that looks identical to the previous, but now sends your decrypted key straight to the malicious attacker. Storing your private key on Keybase allows Keybase to become a single point of failure, which pretty much defeats the whole point of distributed social verification in the first place.

maxtaco 13y ago
We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe. BTW, this argument does not extend to the CLI or other uncompromised clients. People who sync their private keys across devices with the CLI are unaffected.
- peterwwillis 13y ago
  I'm confused. It sounds like users are able to sync their private keys with the CLI, or with the web interface. It also sounds like if they do it with the web interface, they are at risk, whereas with the CLI they are not at risk. If my understanding is correct, my question is: What is the reason for this difference in security for the two use cases, and isn't there some way to provide web access without reducing security? What about browser add-ons? Client certificates?
  - maxtaco 13y ago
    A browser extension is in our (ever-expanding) todo list. We had one a few months ago, but we have to do a fair amount of work to get it back up to snuff.
rdl 13y ago
And worse -- it only needs to send that special password prompt page to a specific IP or user of interest, and maybe only when it comes from a mac box (if the victim is known to do auditing on a linux box, but uses it as a regular client on mac). Shipping packaged software with evil inside to ~everyone is risky because at least one user is likely to find a bug (accidentally) and try to trace/reverse/whatever (or, at the very least, if you do networked evil, some kind of IDS/firewalling). Per-user downloads, especially at time of each use, are vastly more risky; this is the "hushmail attack".

deleted 13y ago

[deleted]