3 ms·

"Clearly, they didn't take crypto design very seriously when they shipped a product based on it." - spot on. There is no deeper subtext. Not sure what you found

"Clearly, they didn't take crypto design very seriously when they shipped a product based on it." - spot on. There is no deeper subtext. Not sure what you found weird - eridius got my point perfectly and countered well.

tptacek 11y ago
Right, where I'm confused is, you seem comfortable using and endorsing something that by all accounts takes crypto design even less seriously than AgileBits did years ago. I'm not trying to needle you, I just don't follow where you're going with this.
- sdrapkin 11y ago
  I never claimed or implied that latest design of 1Pass repository is worse or even security-equivalent to KeePass. I simply pointed out that 1Pass team has made their share of mistakes (plural), so I have as much trust in their competence as, likely, in KeePass team. With author trust being a non-issue (humor me in this assumption), we must look at facts & evidence only. Both 1Pass and KeePass repositories are well-specified, with latest 1Pass clearly having an advantage due to AEAD. 1Pass implementation quality is unknown due to it being closed-source, and I'm not aware of any independent audits. KeePass implementation quality can at least be observed & discussed. 1Pass cannot even be discussed due to being a "trust-us" blackbox. Well, I don't trust them. I would wager that even you don't know whether 1Pass actually HMAC's their IVs. On a more holistic level, this category of software is client-based password managers (as opposed to centralized password managers like LastPass). My position is that trustworthy client-based password managers cannot be closed-source.
  - tptacek 11y ago
    You start out in a reasonable place but then rhetorically overplay your hand: I'm pretty sure they do HMAC their IV, (a) because they say they do and (b) because there are open source implementations of their file format that (i) do the HMAC verification and (ii) would not work properly if they weren't HMAC'ing their IV. You can check right now: it took 2 minutes to find the Python code that computes the HMAC. It's a minor thing to be wrong about, but it's also something you could have checked yourself before dinging me about it. :) The story of this whole thread culminates in a place where I trust 1Password a lot more than KeePass; KeePass knows they need a better cryptosystem, but retains a broken one. 1Password has an extensively documented file format with 3rd party implementations, the author of which format actually responds to academic research. I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!
    - sdrapkin 11y ago
      Guilty as charged on the HMAC'ing the IV verification - bad example for a still-valid point. You still don't know whether closed-source code is using the rng properly, sending "debugging information" containing your private data to the mothership when internet is available/stars align, creating plaintext temporary files in %temp% folder (accessible by all other apps), etc, etc. Ie. there is a myriad of things the implementation could get seriously wrong, even though the repository itself is encrypted securely. I would argue that KeePass and its loyal and vast userbase does not in fact seem to know they need a better cryptosystem (and ideally better implementation). My HN post was intended to bring this to everyone's attention. "I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!" - so would I.
      - eridius 11y ago
        Some of the things you've mentioned here you actually can test for even on closed-source implementations. It's pretty easy to trace the activity of the app to see if it creates temporary files or does network activity so you can you investigate that stuff. As for the other things, like using the rng properly and whatnot, no, you can't really check that stuff. But your implication here is that open-source apps can be trusted because you can verify that stuff, and I don't buy that. Unless you yourself are a crypto expert that's qualified to carry out such an audit, and you have the spare time / inclination to perform a full audit of the app, then there's no reason why it being open-source should make it any more trustworthy. Perhaps if some independent trustworthy third party performed the audit you could then decide to trust it, but closed-source apps can still be audited, it just requires the help of the app developer to do so. And of course even if the app is audited (whether open- or closed-source), that audit will only really verify the particular version that was audited. Future changes may introduce vulnerabilities again, so unless someone qualified to do so is constantly auditing all future changes, then you can't really trust it anymore, since your trust model is that the source needs to be independently verified to be trusted. On other hand, if your trust model is that you determine whether you trust the people involved to get it right, then it doesn't matter if the app is open- or closed-source, as long as it's developed by the right people. Granted, it can be hard to determine whether someone can be trusted to get it right without independent audits, but speaking personally, I take tptacek's "I feel like they know what they're doing" recommendation as carrying a fair amount of weight. I certainly would welcome an independent audit of 1Password, but I recognize that I can't really expect a closed-source software vendor to hand the source of their flagship application to a 3rd party. (if it isn't clear, I'm a happy user of 1Password)

tptacek 11y ago

Right, where I'm confused is, you seem comfortable using and endorsing something that by all accounts takes crypto design even less seriously than AgileBits did years ago. I'm not trying to needle you, I just don't follow where you're going with this.

sdrapkin 11y ago
I never claimed or implied that latest design of 1Pass repository is worse or even security-equivalent to KeePass. I simply pointed out that 1Pass team has made their share of mistakes (plural), so I have as much trust in their competence as, likely, in KeePass team. With author trust being a non-issue (humor me in this assumption), we must look at facts & evidence only. Both 1Pass and KeePass repositories are well-specified, with latest 1Pass clearly having an advantage due to AEAD. 1Pass implementation quality is unknown due to it being closed-source, and I'm not aware of any independent audits. KeePass implementation quality can at least be observed & discussed. 1Pass cannot even be discussed due to being a "trust-us" blackbox. Well, I don't trust them. I would wager that even you don't know whether 1Pass actually HMAC's their IVs. On a more holistic level, this category of software is client-based password managers (as opposed to centralized password managers like LastPass). My position is that trustworthy client-based password managers cannot be closed-source.
- tptacek 11y ago
  You start out in a reasonable place but then rhetorically overplay your hand: I'm pretty sure they do HMAC their IV, (a) because they say they do and (b) because there are open source implementations of their file format that (i) do the HMAC verification and (ii) would not work properly if they weren't HMAC'ing their IV. You can check right now: it took 2 minutes to find the Python code that computes the HMAC. It's a minor thing to be wrong about, but it's also something you could have checked yourself before dinging me about it. :) The story of this whole thread culminates in a place where I trust 1Password a lot more than KeePass; KeePass knows they need a better cryptosystem, but retains a broken one. 1Password has an extensively documented file format with 3rd party implementations, the author of which format actually responds to academic research. I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!
  - sdrapkin 11y ago
    Guilty as charged on the HMAC'ing the IV verification - bad example for a still-valid point. You still don't know whether closed-source code is using the rng properly, sending "debugging information" containing your private data to the mothership when internet is available/stars align, creating plaintext temporary files in %temp% folder (accessible by all other apps), etc, etc. Ie. there is a myriad of things the implementation could get seriously wrong, even though the repository itself is encrypted securely. I would argue that KeePass and its loyal and vast userbase does not in fact seem to know they need a better cryptosystem (and ideally better implementation). My HN post was intended to bring this to everyone's attention. "I'd still use KeePass before I used LastPass, though, and would still use KeePass before I used no password manager!" - so would I.
    - eridius 11y ago
      Some of the things you've mentioned here you actually can test for even on closed-source implementations. It's pretty easy to trace the activity of the app to see if it creates temporary files or does network activity so you can you investigate that stuff. As for the other things, like using the rng properly and whatnot, no, you can't really check that stuff. But your implication here is that open-source apps can be trusted because you can verify that stuff, and I don't buy that. Unless you yourself are a crypto expert that's qualified to carry out such an audit, and you have the spare time / inclination to perform a full audit of the app, then there's no reason why it being open-source should make it any more trustworthy. Perhaps if some independent trustworthy third party performed the audit you could then decide to trust it, but closed-source apps can still be audited, it just requires the help of the app developer to do so. And of course even if the app is audited (whether open- or closed-source), that audit will only really verify the particular version that was audited. Future changes may introduce vulnerabilities again, so unless someone qualified to do so is constantly auditing all future changes, then you can't really trust it anymore, since your trust model is that the source needs to be independently verified to be trusted. On other hand, if your trust model is that you determine whether you trust the people involved to get it right, then it doesn't matter if the app is open- or closed-source, as long as it's developed by the right people. Granted, it can be hard to determine whether someone can be trusted to get it right without independent audits, but speaking personally, I take tptacek's "I feel like they know what they're doing" recommendation as carrying a fair amount of weight. I certainly would welcome an independent audit of 1Password, but I recognize that I can't really expect a closed-source software vendor to hand the source of their flagship application to a 3rd party. (if it isn't clear, I'm a happy user of 1Password)