4 ms·

I don't buy this "explanation" for the following reason: Even if they could not anticipate an attacker tampering with user data, surely they should've been abl

I don't buy this "explanation" for the following reason: Even if they could not anticipate an attacker tampering with user data, surely they should've been able to anticipate filesystem corruption? Let's not pretend that MACs and secure integrity checks were a modern marvel just because CCA attacks were seen as theoretical back then.

eridius 11y ago
The Agile Keychain format has a field called "contentsHash" (which looks to contain 32 bits of data). I'm assuming that's some sort of hash (perhaps crc32) of the encrypted contents, used to protect against corruption (but not against malicious attackers).
tptacek 11y ago
Can you help me understand what your fundamental argument is here? It seems pretty straightforward that the old, unauthenticated format is bad. Clearly, they didn't take crypto design very seriously when they shipped a product based on it. Is there some deeper subtext here? Whatever that subtext might be: it's especially weird coming from you, since you're the author of the story at the top of this thread, about a current version of KeePass that uses unauthenticated encryption. The EtM CBC+HMAC crypto design we're talking about for 1Password is years old.
- sdrapkin 11y ago
  "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

The Agile Keychain format has a field called "contentsHash" (which looks to contain 32 bits of data). I'm assuming that's some sort of hash (perhaps crc32) of the encrypted contents, used to protect against corruption (but not against malicious attackers).

tptacek 11y ago

Can you help me understand what your fundamental argument is here? It seems pretty straightforward that the old, unauthenticated format is bad. Clearly, they didn't take crypto design very seriously when they shipped a product based on it. Is there some deeper subtext here? Whatever that subtext might be: it's especially weird coming from you, since you're the author of the story at the top of this thread, about a current version of KeePass that uses unauthenticated encryption. The EtM CBC+HMAC crypto design we're talking about for 1Password is years old.

sdrapkin 11y ago
"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.