Comment by CiPHPerCoder | Hacker News Reader

Comment by CiPHPerCoder | Hacker News Reader

Their solution is very similar to the mode prescribed by [1] and implemented in [2].

There are actually two problems with bcrypt:

  - It truncates after 72 characters
  - It truncates after a NUL byte

If anyone is dead set on following Dropbox's example, make sure you aren't passing raw binary to bcrypt. You're playing with fire.

Additionally, if you're going to use AES-256, don't implement it yourself. Use a well tested library that either uses AEAD or an Encrypt then MAC construction.

[1]: https://paragonie.com/blog/2016/02/how-safely-store-password...

[2]: https://github.com/paragonie/password_lock

Not sure I understand the purpose of a MAC in this case. What benefit does it provide to hash storage? If the attacker has write access to your database to tamper with the hash, they will mostly likely also be able to sign up as a user, and clone that (properly signed + encrypted) hash over to whichever account they want to log into. When cracking the hash, they'll just ignore the MAC.

nitpick: encrypt-then-MAC is an AEAD construction.

Nitpick to counter your nitpick: Not necessarily.

It's an AE construction, but not necessarily an AEAD construction. You can have IND-CCA3 security without additional data.

The converse is also not necessarily true (i.e. an AEAD scheme could be based on MAC-then-Encrypt and IIRC there are some that are built that way), but that's a less useful counterpoint. The recommended AEAD constructions (AES-GCM and ChaCha20-Poly1305) are EtM.

Reply on news.ycombinator.com