4 ms·

But wait… if the entire key is derived from the passphrase, if two people both choose the passphrase "password", would they not then get the same public and pri

But wait… if the entire key is derived from the passphrase, if two people both choose the passphrase "password", would they not then get the same public and private keys? Can I not brute force people's private keys by taking millions of common passwords¹ and generating public keys from them, and then seeing which ones match my friends? Am I wrong? Doesn't this seem much easier to brute force than a RSA key? (Presuming the private key hasn't been compromised; if it has, it's likely protected by a password, and then these two are about equal.) ¹accepting that some will get rejected because of "uses the zxcvbn library in order to impose a strict limit on the amount of detected entropy present in entered passphrases. miniLock will not allow passphrases that fall below the threshold of 100 bits of entropy"

diafygi 12y ago
Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.html#L37 https://github.com/kaepora/miniLock/blob/master/src/index.ht...
- akerl_ 12y ago
  Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.
  - diafygi 12y ago
    Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.
    - sillysaurus3 12y ago
      What about making the user choose two passphrases, which are concatenated together by the tool? Cracking a single passphrase may be easy, but cracking two concatenated passphrases is significantly harder. E.g. password 1: "the quick brown fox jumps over the lazy dog" Password 2: "jack be nimble jack be sick" Final result, used to derive a keyfile: "the quick brown fox jumps over the lazy dogjack be nimble jack be sick" Notice how "quick" was switched with "sick" in the last word. Now there's no pattern that can be easily cracked. If we force a user to explicitly do something like that, then this can still work. That example was chosen intentionally to be weak. It shows that even with two relatively weak passphrases, the result is still somewhat strong. If we add extra requirements on top of that, such as forcing the user to use numbers and capitalizations, then the result should be sufficiently unique.
      - akerl_ 12y ago
        No, because then the person generating their table just takes that into account. It's slighly harder, but not noticeably so compared to how secure it needs to be.
        sillysaurus3 12y ago
        It seems like as long as the complexity of the passphrase is sufficient, then a rainbow table can't be effective. For example, a 128-bit random AES key is a kind of passphrase that's generally not susceptible to a rainbow table attack (though it's very hard for humans to remember). So the problem here is, how do you force the user to make their passphrase sufficiently complex? Passphrases also don't protect against keyloggers, which is a downside of this approach.
        akerl_ 12y ago
        You force the password to be sufficiently complex by doing what you said: creating it (pseudo)randomly. The aforementioned 128 bit random AES key is robust, assuming the PRNG is solid. A user-provided password utilizing the human mind as its PRNG will never come close.
  - MichaelGG 12y ago
    Please enlighten us on how to generate rainbow tables for passphrases. Assuming they use a lower bound of 6 bits per character, a 100 bit phrase is 46 characters long. Off the top of my head, I'd use a book of quotations, popular lines from movies, etc. And try to hit common permutations of each. So there's a bit of low hanging fruit. But that could be detected when they generate their key. Remember, salt doesn't really prevent anyone from using "password" or the first line of Billie Jean.
    - akerl_ 12y ago
      Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. But that's not the case: https://github.com/dropbox/zxcvbn/issues/39 https://github.com/dropbox/zxcvbn/issues/39 And as an attacker, I'm using my rainbow tables specifically to target the low hanging fruit. It gives me the best initial odds, and also the best return on any given hit: I'm way more likely to get more users per match for things in the common phrasebook, by nature of it being the common phrasebook.
      - MichaelGG 12y ago
        I don't get your point with your link. It says it cannot detect certain repeated character runs, or the word "password" in Morse code. Basically you're arguing against memorizing the key. That means users are forced to keep a file around. It ignores the many cases where you don't want to have to maintain a file.
      - thibauts 12y ago
        Anyway what will be easy to remember for a human will be sequences exhibiting high ngrams correlation, which is efficiently modeled by markov chains. Wondering if studies have been done from this perspective on password strength, and how chains generated from leaked password / passphrase collections would deviate from ones generated from common language.
      - x1798DE 12y ago
        >Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. I'm fairly skeptical of the ability of software to "ensure high-entropy passphrases". I don't think it's trivial to anticipate the entropy-lowering strategies that people will come up with in order to help them remember their passwords.
  - diafygi 12y ago
    How about my proposed salting change? This would thwart a one-table attack. https://github.com/kaepora/miniLock/pull/14 https://github.com/kaepora/miniLock/pull/14

diafygi 12y ago

Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.html#L37 https://github.com/kaepora/miniLock/blob/master/src/index.ht...

akerl_ 12y ago
Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.
- diafygi 12y ago
  Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.
  - sillysaurus3 12y ago
    What about making the user choose two passphrases, which are concatenated together by the tool? Cracking a single passphrase may be easy, but cracking two concatenated passphrases is significantly harder. E.g. password 1: "the quick brown fox jumps over the lazy dog" Password 2: "jack be nimble jack be sick" Final result, used to derive a keyfile: "the quick brown fox jumps over the lazy dogjack be nimble jack be sick" Notice how "quick" was switched with "sick" in the last word. Now there's no pattern that can be easily cracked. If we force a user to explicitly do something like that, then this can still work. That example was chosen intentionally to be weak. It shows that even with two relatively weak passphrases, the result is still somewhat strong. If we add extra requirements on top of that, such as forcing the user to use numbers and capitalizations, then the result should be sufficiently unique.
    - akerl_ 12y ago
      No, because then the person generating their table just takes that into account. It's slighly harder, but not noticeably so compared to how secure it needs to be.
      - sillysaurus3 12y ago
        It seems like as long as the complexity of the passphrase is sufficient, then a rainbow table can't be effective. For example, a 128-bit random AES key is a kind of passphrase that's generally not susceptible to a rainbow table attack (though it's very hard for humans to remember). So the problem here is, how do you force the user to make their passphrase sufficiently complex? Passphrases also don't protect against keyloggers, which is a downside of this approach.
        akerl_ 12y ago
        You force the password to be sufficiently complex by doing what you said: creating it (pseudo)randomly. The aforementioned 128 bit random AES key is robust, assuming the PRNG is solid. A user-provided password utilizing the human mind as its PRNG will never come close.
- MichaelGG 12y ago
  Please enlighten us on how to generate rainbow tables for passphrases. Assuming they use a lower bound of 6 bits per character, a 100 bit phrase is 46 characters long. Off the top of my head, I'd use a book of quotations, popular lines from movies, etc. And try to hit common permutations of each. So there's a bit of low hanging fruit. But that could be detected when they generate their key. Remember, salt doesn't really prevent anyone from using "password" or the first line of Billie Jean.
  - akerl_ 12y ago
    Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. But that's not the case: https://github.com/dropbox/zxcvbn/issues/39 https://github.com/dropbox/zxcvbn/issues/39 And as an attacker, I'm using my rainbow tables specifically to target the low hanging fruit. It gives me the best initial odds, and also the best return on any given hit: I'm way more likely to get more users per match for things in the common phrasebook, by nature of it being the common phrasebook.
    - MichaelGG 12y ago
      I don't get your point with your link. It says it cannot detect certain repeated character runs, or the word "password" in Morse code. Basically you're arguing against memorizing the key. That means users are forced to keep a file around. It ignores the many cases where you don't want to have to maintain a file.
    - thibauts 12y ago
      Anyway what will be easy to remember for a human will be sequences exhibiting high ngrams correlation, which is efficiently modeled by markov chains. Wondering if studies have been done from this perspective on password strength, and how chains generated from leaked password / passphrase collections would deviate from ones generated from common language.
    - x1798DE 12y ago
      >Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. I'm fairly skeptical of the ability of software to "ensure high-entropy passphrases". I don't think it's trivial to anticipate the entropy-lowering strategies that people will come up with in order to help them remember their passwords.
- diafygi 12y ago
  How about my proposed salting change? This would thwart a one-table attack. https://github.com/kaepora/miniLock/pull/14 https://github.com/kaepora/miniLock/pull/14