KeePassX uses an older database format (KDB) than KeePass 2.x (KDBX4). It also lacks AEAD and is actually less secure than KDBX4 according to the analyses I've read.

Just a general info: KeePassX can read and write the KeePass2 file format, but you have to checkout the git repo manually. It works for me since at least one year.

The problem is the current maintainer, it seems that he has no interest in releasing a new version :(

I don't know about AEAD, but my copy of KeePassX 2.0 alpha 6 seems to work just fine with .kdbx files.

Edit: it is available as a Mac binary on the KeePassX site.

I've looked through the source of KeePassX and it doesn't look complicated, but it requires a crypto expert to say something valuable about it's crypto. Would someone qualified mind sparing some time? I found a port of KeePassX 2 from gcrypt to openSSL ›› https://github.com/WhiteDawn/keepassbb10

Personally I didn't like KeePass 2, so I moved back to KeePassX. You can use ›› https://github.com/dvorka/keepass2-to-keepassx

Here's an awesome QML UI for KeePassX made for Jolla OS, I'm not sure how much work is required to get that to work on Android though. https://openrepos.net/content/jobe/ownkeepass

There is a ›› Python module to read KeePass 1.x/KeePassX (v3) and KeePass 2.x (v4) files – https://github.com/phpwutz/libkeepass

EDIT: TRESOR is an algorithm that runs AES Encryption Securely Outside RAM ›› https://www1.cs.fau.de/tresor ›› https://github.com/ischlecken/TresorLibrary

Well, the language isn't really in question here -- it's the crypto used for the database files themselves.

KeePassX is the old database format and KeePass 2.x+ uses a newer one. I don't know if the database format also resulted in any crypto changes.

There are 2 problems here. (1) The c# .NET implementation is lacking; (2) the fundamental crypto design of the kdbx database (which is shared by all implementations, in any language) is lacking.

Yes, but since this isn't some networked service I'm not as concerned about the general quality of the code. Offline attacks really have to focus on the encrypted password database. If an attacker has local access you're already owned -- they could just modify the application to do whatever they want... or keylog you, etc.

The safety of your database in a world where your keepass database is leaked due to a Dropbox attack or something is what really matters here, IMO.

Did they screw up the crypto so offline attacks are easier?

It's not 100% offline. As you said, if they manage to access your Dropbox, they could theoretically sync an altered database back to you. If the application leaks some information while attempting to open the database or can be made to leak information, that would be bad.

Sync it in an encfs encrypted folder, and it should be fine!

Yea, that's what I've been using for the past 2 or 3 years, I think.