Keepassxc: KeePass Database Standard Discussion

[droidmonkey]

Placeholder for KeePass Database (KDBX) standard discussion. This post will be edited to include a list of features and upgrades we would like to bring to Dominik for consideration in the next KDBX format update.

Must Haves:

• [ ] Standardize on Argon2id instead of Argon2d
• [ ] Add Password Modification Datetime
• [ ] Database/Entry Custom Data modification time
• [ ] Built-in Entry Template Specification (https://github.com/keepassxreboot/keepassxc/issues/863#issuecomment-680292058)
• [ ] Built-in TOTP Specification (otp attribute)
• [ ] Built-in Hardware Key Specification
• [ ] Built-in Quick Unlock Specification
• [ ] Built-in favorites/pinned items
• [ ] Only support straight binary key files
• [ ] Multi-valued core and custom fields
• [ ] Proper storage format for and deduplication of BLOBs (SQLite can handle this)

Nice To Haves:

• [ ] Custom icon naming
• [ ] Graph instead of tree structure (one item can belong to multiple groups, makes tagging somewhat redundant)

Optional Support:

[droidmonkey]

Looping in @keepassium @mmcguill @PhilippC
Original issue that spawned this conversation: https://github.com/keepassxreboot/keepassxc/issues/4293#issuecomment-583742873

[mmcguill]

Might be worth adding the idea of "Favourites" or "Pinned" items, items that appear upfront when user opens the database. It's a pretty popular/handy feature in Strongbox and it would be great to have it standardised across the KeePass world.

[georgesnow]

Curious do all the variant apps support tags? If so why not just standardize on a tag? Maybe “Pinned” (case insensitive). And document it that way?

That would mean those apps that want to support it can and it wouldn’t matter to any other platform (or native KeePass, MacPass,KyPass etc)

[georgesnow]

And if someone happens to add it as tag the first time just prompt them explaining the use of the “Pinned” as a tag

[droidmonkey]

@georgesnow that's exactly the reason to make it _part of the standard_ instead of just arbitrarily deciding on a tag and gaining application concurrence. Tags might not be the best choice anyway since they are user defined and can conflict.

[georgesnow]

I am certainly not disputing adding the standard, which is always a better solution for something like this. However, seeing as the native KeePass tends to be conservative in their approach to making such changes (and understandably so).

The suggestion was more of interim solution (should have been clearer about that). That is just based on is there any reference for how long features take to get integrated in the KeePass standard?

The interim solution could be easily revertible or convertible by an app at later time when the new standard is implementated. It provides the benefit to the users now, but doesn't force compliance and break anything in other KeePass ports. I am certainly not saying it's ideal as you said due to user conflict issues. Again was just a thought, but sounds like thinking is not to do an interim solution and just wait, which I get.

[droidmonkey]

Correct, I am trying to avoid implementing a multitude of "minor" interim solutions. That creates significant code bloat with exceptions and workarounds depending on which version of the standard you are on. The myriad of plugins made for KeePass over the years demonstrates why this is not a good thing. They all made their own unique standards.

[F3000]

Example from Enpass for tags :

Here they are user defined and the developers from Enpass using a pre defined “Apple Watch” Tag to display all entries on the watch which get tagged with this .

In my eyes “pinning” should be in the standard and tags only for special things a developer decide

[funnym0nk3y]

Is there a plan, when those features could be introduced in the standard and into XC?

[droidmonkey]

This would be a keepassxc 3.0.0 type move. Ideally we'd get Dominik on board with this as a well.

[funnym0nk3y]

Hmm, I guess 3.0.0 is still far away. Thanks anyway! Is somebody in contact with Dominik?

[droidmonkey]

Not yet, want to get our full proposal together first using actual rfc style.

[funnym0nk3y]

If you need help let me know!

[hokonch]

Related #398 #3558

KeePassDX, the alternative KeePass client for Android, recently added multiple URL formats that are incompatible with Keepass2Android. The app uses WebDomain and WebDomain[counter] instead of KP2A_URL and KP2A_URL_<counter>.
https://github.com/Kunzisoft/KeePassDX/issues/524#issuecomment-708251598

Given the popularity of Keepass2Android, it's reasonable for KeePassXC to support its vendor prefix at this time, but I'd like to see this feature standardized with a common prefix in the future.

[strongbox-mark]

That's a pity, are we too late to ask the KeePassDX team if they change/standardize? Is this gone to Production yet?

[droidmonkey]

I'd just bake a proper one into kdbx 5 at this point.

[J-Jamet]

Hello gentlemen, I read the discussion succinctly, I may have missed some information, please remind me if I am wrong.

That's a pity, are we too late to ask the KeePassDX team if they change/standardize? Is this gone to Production yet?

Indeed, KeePassDX is already in production with the WebDomain label feature. For my part, I just did not use the KP2A nomenclature which clearly indicated that it came from KeePass2Android, prefix ("KP2A_") and preferred used a more generic one.

This functionality also includes fields with ApplicationId[n] label and package name as value which allow opening applications directly from an entry. I just saw that KeePass2Android released its new version 1.08c-r1-nonet with this changelog : _"No longer storing package names of Android apps in the URL field"_. But I don't know what that means yet.

As I indicated in my comment, I am of course ready to harmonize things, which will be much better in the future, and I think custom label fields need to be more appropriate and generic.

[strongbox-mark]

Hi @J-Jamet - Yes, I hear you KP2A_ seems a little too specific, and I think KeePassXC uses kpxc_ for some of it's extensions (Audit Exclusions, etc).

Thanks for the extra info on your URLs and Applications - Sounds interesting and it may be possible to use these on iOS too...

Maybe we should just go with "kp_ext_*" or "kdbx5_" or something like that for features we think would be very useful additions?

[PhilippC]

please note that KP2A does not really care about any prefix or so. If it searches for an entry matching a URL, it will first look into the URL field but if nothing matches there, it will search all other fields. If KP2A creates a new field for an android packages name, this is now called AndroidApp[counter], but again, it's just a name which doesn't have a meaning. If a new standard would define new types like URL, AndroidApp etc. that might simplify the matching.

[J-Jamet]

Thank you @PhilippC for the details.

So we can replace the ApplicationId[n] label by AndroidApp[n], which is fine and will allow better compatibility.
It does not prepare for IOS apps, maybe it is a good thing if we want to separate the links available for applications which would not exist on Android or IOS. But would not work with the same names of packages (It does not matter to me but maybe important with people who have more than one type of phone). To discuss.

For URLs, we will harmonize with a common prefix. But if the prefix is ​​neither important for KeePassDX, nor for KeePass2Android, the method of visualizing links from KeePassXC is maybe too restrictive and should apply to all custom fields if a link is present whatever the label.

[droidmonkey]

I would prefer to use the existing reserved keyword "Url" and add a common suffix "_N". My upcoming work on entry templates is aiming for that suffix for any repeatable fields. AndroidApp and iOSApp are great reserved prefixes.

[phoerious]

I like FIELDNAME[n]. The User-Interface could generally display fields following this pattern as multi-valued. In fact, for KDBX5 I would write multi-valued fields into the specification, so that we don't have to agree on some weird key nomenclature.

[phoerious]

BTW I added the following suggestions to the list at the top, which been lingering in my head for some time:

• Multi-valued core and custom fields
• Proper storage format for and deduplication of BLOBs (SQLite can handle this)
• Graph instead of tree structure (one item can belong to multiple groups, makes tagging somewhat redundant)

[droidmonkey]

Great idea, conversion from single value to multi valued fields can be easy too when upgrading from kdbx4 to kdbx5. One point for multivalue is to preserve order, this can be done through xml order or with explicit "order=#" attribute.

We should also move a lot more stuff into attributes versus fields.

[phoerious]

Or in SQLite by adding an order attribute. I am more and more in favour of using SQLite, especially considering storage of binary blobs.

[J-Jamet]

Multi-valued core and custom fields: I'm ok for this :)

OK, so to resume (for short-term changes, I plan to change the format for the next update):

• URL: URL[_N]
• Android Application Id or Package Name: AndroidApp[_N]
• IOS App Id or Bundle Id: iOSApp[_N]
• For elements specific to an application or plugin, it's only in plugin data otherwise we can ask here if it is useful elsewhere.

In any case, [_N] means the first element has no suffix, the following ones start from _1 (ie: URL, URL_1, URL_2).
_Acronyms can stay with capital letters_

Also, does everyone agree that the OTP format adopted by default is the URI otpauth?
Because it is a pain to maintain with all the plugins that exist on KeePass (as described above).
Is it a problem to capitalize for you or for the current plugins (simply to harmonize)? -> label OTP and not otp.

@phoerious For SQlite, tell me if I'm wrong but are you thinking of using it as external storage tools, not directly in KeePass format? Is it a technical choice of KeePassXC to deal with BLOBs?

Graph instead of tree structure: Are you thinking of including elements in the XML format or is it just at the parser level?

Built-in Quick Unlock Specification: How do you see the quick unlock, because I realize it is a subject with multiple interpretations :

• Is it leaving the database open and offering a visual unlocking?
• Does it close the database and temporarily store the master key to open with a temporary key?

[phoerious]

Is there a reason for prefixing the numbers with an underscore?

SQLite is a consideration for KDBX5 (or KDBS for that matter). It would replace the XML in order to provide a more scalable storage backend.

[J-Jamet]

Is there a reason for prefixing the numbers with an underscore?

Yes, because @droidmonkey prefers. :D Otherwise we don't care

SQLite is a consideration for KDBX5 (or KDBS for that matter). It would replace the XML in order to provide a more scalable storage backend.

Okay, why not, it could be more efficient indeed.

[phoerious]

I believe that was meant to be Url_1, Url_2 etc., not Url[_1], Url[_2]. ;-)

[droidmonkey]

Prefix of _ to me just separates the attribute name from the sequencing. Makes it clearer what the name is especially when looking at the advanced attributes page.

[J-Jamet]

@droidmonkey Tend to agree with this argument

@phoerious I don't understand what you mean. The brackets are just to explain the concept, I was suggesting URL, URL_1, URL_2. But do you want to have only the first letter in uppercase with acronyms and why?

[phoerious]

I guess it should be something that is not too unpleasantly technical when viewed with a non-conforming client, but explicit enough to not cause unwanted effects with existing attributes. For KDBX5, it's a non-issue, since multi-values fields need only one key.

Edit: Ah, I thought the brackets were part of your syntax. I suggested Url[1], Url[2] etc. But I am fine with Url_1, Url_2 as well.

[J-Jamet]

For KDBX5, it's a non-issue, since multi-values fields need only one key.

I understand that KDBX5 or KDBS format is important and I agree with the new standardization.
But we also have to think about migration and backward compatibility.
Sounds harmless with uppercase and underscore, but not everyone will migrate overnight (KeePass app creators and users who might want to keep an old format for whatever reason).
I still have a lot of users on my side who are still on KDB so we have to harmonize as much as possible even old formats so that the migration goes smoothly.

[droidmonkey]

I think we can uniformly agree that kdb needs to be read only (or import only on our case). Kdbx 3 needs to be formally deprecated. I have no interest in letting people cling onto old, potentially less secure, data formats that they don't have any understanding of at all.

[J-Jamet]

I think we can uniformly agree that kdb needs to be read only (or import only on our case). Kdbx 3 needs to be formally deprecated. I have no interest in letting people cling onto old, potentially less secure, data formats that they don't have any understanding of at all.

However KeePass 1.38 is still downloadable and still maintained by Dominik. Personally, I cannot pretend that the format is no longer in use even if I want. Of course, I push to go on the new versions, but either it is completely stopped by everyone or not.
If you have a list of security flaws in these older formats, I'm interested in reading it. We could use this argument to stop their uses altogether.

[droidmonkey]

Maintain multiple formats for no reason at all is a security flaw in and of itself. Opportunity for failures abound. Older versions of kdb and kdbx do not support modern KDF such as argon2 and do not have critical HMAC checks to verify data integrity. Not a security flaw, but certainly an issue. Just because someone makes something available doesn't mean you have to support it. KeePassX is still available, we actively discourage its use since it hasn't been updated in 5 years. I doubt keepass 1.x is updated frequently and with the same rigor as keepass 2.x. Things have to be retired, the world changes, I'm in the camp of "move or die".

[0xpr03]

KeePass 1.38 is still downloadable and still maintained by Dominik

From the Outside: I think it'd make sense to already involve them into this discussion. That way you could get some input what the constraints are for them or for example if there are any deprecation plans for 1.X. Otherwise you may end up doing all the work and getting a no at the end.

[J-Jamet]

Older versions of kdb and kdbx do not support modern KDF such as argon2 and do not have critical HMAC checks to verify data integrity.

I agree on this point but like you said it's not a flaw. It surely deserves that we warn people to migrate, not that they are forced.

Just because someone makes something available doesn't mean you have to support it

Historically, KeePassDroid is compatible with this format. I could have completely abandoned it but I preferred to scale backwards compatibility by redoing the entire architecture of the project. It was clearly a choice! :) I don't recommend using this format (it was only a technical challenge). I am ready to remove it from KeePassDX in the future, that's not the problem.

KeePassX is still available, we actively discourage its use since it hasn't been updated in 5 years

Same, but here KeePass 1.38 was released last year

Things have to be retired, the world changes, I'm in the camp of "move or die".

Indeed I see that, I didn't think the open source world was like this. I'm not as categorical as you on the subject.

Now the fateful question : To return to the main point, does that mean you only want to use the new KDBX5 format when it's in place? RIP KDBX3/KDBX4?

@0xpr03 I completely agree, it's easiest to ask Dominik directly, I'll send him an email.

[0xpr03]

Indeed I see that, I didn't think the open source world was like this. I'm not as categorical as you on the subject.

(I think it applies even more to OS. People could pay you for supporting totally outdated stuff or maintain it by themselves. Otherwise you're doing the work of a corporation for 0€ which will end up in a burnout.)

[J-Jamet]

It was the sentence to convince! :heart: :dagger: :drop_of_blood:
I just sent Dominik an email regarding the subject. It started with a small observation but an interesting debate.

[droidmonkey]

My plan is to hard deprecated kdbx3 with our 2.7 release (message to user, upgrade now please!) And move kdbx3 to import only when kdbx5 is complete. I think it is more than generous to support the previous major release in addition to current release. Thanks for reaching out to Dominik, I think its time to make decisive moves.

[J-Jamet]

Okay, in this case I am also thinking of warning users for this purpose with major versions of KeePassDX ~to deprecate older versions of databases.~ This may take a little longer than KeePassXC but will be done over time.

Edit: A simple warning message will inform users of a new format.

[strongbox-mark]

Great discussion. I think it would be great if we could get Dominik involved. It's his baby after all. I'm not sure how busy he is, or interested in pushing/extending the format? Please let us know how it goes @J-Jamet - Maybe he could join us here!

[J-Jamet]

@strongbox-mark I already sent him an email with the link to the issue, I'm not going to harass him. I'll tell you if I have an answer.

[phoerious]

I have seen quite a few people who insisted they still needed KDB oder KDBX3 or some shit and their reason has always been "the new format isn't compatible with my mobile app". After I pointed them to the correct apps, they usually switched right away.

I believe it is important to keep general support for the old formats around, but it can be import-only and you have to save in a new format. That is totally up to every single application, though. If you implement KDB[XS]5, nothing keeps you from fully supporting the old formats as well. I would recommend nudging users into the right direction, though. If you never deprecate things, users will forever keep using it. There will never be a point where you can discontinue something because nobody is using it anymore if you are not actively working towards that state.

[DReichl]

The KDBX 4 format does support more features and follows more best practices than the KDBX 3 and KDB formats, but I'm not aware of any real problems with the older formats (especially, I'm not aware of any practical cryptographic attack against them). There are apps that are still using the older formats and aren't maintained actively (which I don't really consider to be a problem as long as there aren't any security issues); deprecating the formats would unnecessarily break compatibility with them. Therefore, I'm not going to do that.

If you want to stop supporting the older formats (e.g. in order to reduce complexity), feel free to do that. For such a format, just show a message that it is unsupported by KeePassXC (calling it "deprecated" would be confusing).

I'll post my thoughts about the other ideas here soon. Thanks!

[droidmonkey]

Good point, we will refrain from using deprecated. We went a bit hard on the key file format, apologies

[J-Jamet]

Thank you @DReichl for these clarifications. As the old formats are not deprecated and do not represent security concerns. I will keep them until the implementation of new elements takes too much work for compatibility or migration.

[phoerious]

In the end it means the same thing and for the average end user it for sure does. Deprecated doesn't mean bad, unsafe or anything, it simply means "unsupported in the future". Perhaps we should clarify that only KeePassXC (and some other apps) will stop supporting the old formats (or at least creating new files in that format).

[DReichl]

Argon2id vs. Argon2d.
Of the three Argon2 variants, Argon2d has the best resistance against GPU/ASIC attacks (which is important for database files), and the advantages of Argon2i are far less relevant in our case; see:
https://keepass.info/help/base/security.html#secdictprotect
Therefore, I think that Argon2d is the best choice in our case.

Is there a point that I'm overlooking?

[phoerious]

It's not an easy decision, actually. In theory, Argon2d is better for scenarios without a side-channel attack surface. This is probably the main scenario for an encrypted password file, but doesn't always have to be considering multi-user systems and the fact that most users have a web browser running all the time. I asked my colleague from the cryptography chair for an opinion and those were also his concerns, although in a case where these things actually matter, you are most likely dealing with state-sponsored adversaries and should take more precautions anyway (like not running your web browser while using KeePass and not using it on a shared system).

The main reason why we are considering Argon2i, however, is something as profane as tooling support. Argon2d has very little support in terms of libraries. The only reason we are using the original reference implementation is that libsodium (on which we already depend anyway), implements only Argon2i. We literally have to patch the argon2 library to rename symbols, so that both implementations do not clash at link time.

That said, for normal online password hashing, Argon2i ist probably always the better choice. For our use case, Argon2d may be the safer bet in most cases. But the question is: Does the difference matter enough in practice to rule out a tooling decision?

[phoerious]

Addendum: As I research this further, I see more tools implementing only Argon2i (PHP, for instance) and the general consensus being that Argon2d should NOT be used for password hashing. I guess this assumes online password hashing for authentication, though.

[J-Jamet]

the general consensus being that Argon2d should NOT be used for password hashing. I guess this assumes online password hashing for authentication, though.

Do you have a link to the article that explains this consensus?
What about Argon2id? It would be a good thing to use the hybrid version, after that it remains to be seen if there are the adequate libraries.

[phoerious]

The consensus is what I perceived inspecting different sources. It is in no way authoritative. ~Argon2id in particular has even worse (or similarly bad) tooling support.~ (EDIT: it doesn't) I'm actually not quite sure why we have that on the list and not 2i. Otherwise it sounds like a jack of all trades.

[J-Jamet]

Because it's advocating, here's a document that explains different attack methods and why Argon2id is advocate by default.
I have to read it more precisely to give a more informed opinion, but it may be useful.
https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/?include_text=1

[hokonch]

libsodium (on which we already depend anyway), implements only Argon2i

According to the libsodium documents,

Libsodium supports Argon2i and Argon2id.

In addition, the RFC draft says

Argon2id MUST be supported by any implementation of this document,
whereas Argon2d and Argon2i MAY be supported.

[phoerious]

All right, then I misremembered and Argon2id is indeed what we had in mind. The current IETF RFC draft appears to be tending towards id as the go-to default. The current draft expires 12 March 2021. Perhaps we should wait until then and choose the recommended option.

EDIT: Ah, PHP does indeed support both i and id, but not d.

[droidmonkey]

Sorry late to this, as @hokonch stated, Argon2id is the shall implement. All crypto tool providers are actively NOT implementing Argon2d. The only way to get it is to use the reference implementation library. I petitioned libsodoum to implement several years ago and they told me to pound sand. https://github.com/jedisct1/libsodium/issues/656

[DReichl]

On a server, side-channel attacks of course are relevant. If I'd implement a key derivation for a server, Argon2id also would be my first choice, and I'm not surprised that the RFC draft recommends this.

I think we agree that the resistance against GPU/ASIC attacks is important in our case (it actually was the primary motivation to add Argon2). By switching from Argon2d to Argon2id, we'd lose some of this resistance and gain some side-channel attack resistance instead. It isn't clear to me whether this trade is worthwhile. Janek, you mentioned attacks in multi-user systems and through web browsers. I'd like to learn more about such attacks. Do you have a link to an article/website where I can read more about this? Did anyone accomplish such an attack (extracting sensitive information from a different process on a client PC)? I searched the web, but only found attacks that aren't really interesting (e.g. detecting certain user activities by observing the CPU cache, but this is very far away from extracting sensitive information).

Shall we implement Argon2id as an option? Users who worry about side-channel attacks could then select Argon2id, whereas users who prefer the best resistance against GPU/ASIC attacks (like me) could select Argon2d. As the key derivation is extensible since KDBX 4, adding support for Argon2id is easy; the database format doesn't even need to be changed for this (only support for the new algorithm needs to be added). I'd be happy with this solution.

[droidmonkey]

Given that we have all implemented Argon2d already this isn't really a big concern of mine. I just wish libsodium implemented it so we didn't need a separate library. I'm ok with not adding more options and just keep using 2d into the future.

[phoerious]

I am not really an expert on side-channel attacks, but from what I understand, there are at least initial PoCs for cache timing exploits via Javascript in a browser. The same attacks are of course also possible (and probably even easier) on multi-user systems such as shared hosting servers.

Argon2d becomes vulnerable if you can detect memory patterns, since its memory access is data-dependent and you can abort early if the pattern doesn't match. Argon2i prevents this by ensuring the access pattern in each iteration is the same. This data-independent array access method also makes Argon2i the slower of both variants, which is why it is recommended for password hashing (besides general resistance against timing attacks in online systems and multiuser environments). Argon2id sits in the middle and provides the best of both worlds, hence it is the recommended option unless you have a very good reason to use one of the other two.

Of course, Argon2i is totally capable of resisting GPU attacks. Both variants make time-memory trade-offs extremely unfavourable. Overall, it is simply less resistant and needs more rounds to provide the same level of security against this kind of attack. Hence, Argon2d would be used for things like PoW in blockchains where side-channel attacks are entirely irrelevant, but has little application elsewhere.

In the end a somewhat strong password and reasonable parameter choice should make your transformation strong enough with all three options so that you may as well start brute-forcing the AES key. But before you go down that route, don't forget the heavy $5 wrench.

I cannot really give you good hints for where to look in the literature, but the Open Sesame paper by Wetzels (although a student paper?) is worth a read and I also found this Reddit thread to be quite interesting: https://www.reddit.com/r/crypto/comments/c8a299/cache_timing_attacks_against_argon2d/
I can ask my colleague if he has better literature recommendations (besides Biryukov et al. of course).

In the end, I am all for going with the recommended standards and that is Argon2id. The benefits are better tested, well-analysed and proven as well as often faster implementations than for any niche variant. I also want to get rid of libargon2 (and the nasty binary patching), which isn't really meant for use in production the way other mainstream crypto libraries would be. Making both d and id an option wouldn't allow us to do this. And I don't mean you wouldn't be allowed to support Argon2d (KDBX4 is extensible after all). I only mean that it shouldn't be part of the minimum supported set of KDFs that would go as a MUST into the spec and thus would not be the default in any implementation.

[DReichl]

Do you mean the following cache timing exploits via JavaScript in a browser?
https://www.cs.columbia.edu/2015/spy-in-the-sandbox/
Although interesting, this is one of those attacks that I don't really consider to be a threat for us; you can only detect certain user activities, not extract sensitive data (as mentioned explicitly in the article).

Thanks for the hint about the Open Sesame paper and the link to the Reddit thread. I've read them, but I'm still not seeing evidence that side-channel attacks are a real threat on normal client devices right now (in contrast to side-channel attacks against servers). There are ideas how such local attacks might work in theory, but I'm not aware of any successful attack in practice (probably due to the noise on client devices, etc.). This might change in the future though, thus I understand that some people worry about it.

All three Argon2 variants aim for GPU/ASIC resistance, but with respect to this, Argon2d is a bit better than Argon2id. By switching from Argon2d to Argon2id, we don't simply get some side-channel resistance for free; we lose some GPU/ASIC resistance. This is a good reason for using Argon2d, if you don't fear side-channel attacks.

The KDBX format is supported by different apps, on different platforms, using different cryptographic libraries, which may change over time. I understand that you want to simplify your code (reducing code complexity is a good thing), but I don't think that the availability of certain implementations of an algorithm should influence the decision whether to use the algorithm; the decision should only be based on whether the algorithm is suitable (from a design point of view, with security having the topmost priority, where security may have different facets like in our current case).

In light of these points, I think that it's best to support both Argon2d and Argon2id, and let the user choose. The documentation should clearly mention the advantages/disadvantages of the two variants and the current state of side-channel attacks on client devices, such that the user can make an informed decision.

I'll add support for Argon2id in KeePass now. This may take a while (I'm currently still working on something else that will take a few more days, and properly implementing Argon2id will also take some time), but I'm sure it'll make it into the next KeePass release. I'll post here when my implementation is ready.

Thanks!

[phoerious]

I think tooling support is a very strong argument and I definitely trust a well-tested implementation of a widely-deployed version of an algorithm a lot more than a niche implementation of a niche algorithm. That is the same reason I keep using AES, even if other algorithms may be better in theory and I am certainly not relying on some old reference implementation code. The go-to standard algorithm and a widely-deployed implementation of it will always receive more cryptanalysis and vulnerability research.

By switching from Argon2d to Argon2id, we don't simply get some side-channel resistance for free; we lose some GPU/ASIC resistance.

And that is not true per-se. You can compensate easily by sacrificing a bit of decryption time with a higher round setting. In practice I don't see any reason to trade the advantages of recommended and widely-deployed standards for rather hypothetical protection against targeted ASIC attacks. I believe if you have to be worried about that, your name is probably Edward Snowden and if you are in that position, then ramping up the rounds a bit isn't going to be a huge inconvenience.

Do you mean the following cache timing exploits via JavaScript in a browser?
https://www.cs.columbia.edu/2015/spy-in-the-sandbox/

Not necessarily exactly that, but something like that, yes. But I am also thinking about Spectre/Meltdown and similar low-level exploits. I don't see the risk of this becoming lower in the future and as more data and compute moves into the cloud, I can only imagine the attack surface to widen.

My main point, however, is that I don't like going against the standards without a VERY good reason. And "a bit" of ASIC resistance isn't going to cut it for me. I also don't see that any of the libraries are going to change their minds on this. If anything, the support for Argon2d will only get worse. I do agree with the libsodium maintainer Jonathan cited earlier that "Argon2d doesn't have any major benefits over Argon2id." and " It's not the one its authors recommend."

As I said, everybody is free to provide as many additional KDFs as they like. We also offer TwoFish as an additional block cipher (not even sure if anybody really uses that). But I think keeping Argon2d as the default is the wrong signal. The default should be something that is a) generally recommended for the purpose of password hashing and b) widely available and well-tested. Everything that does not meet these criteria should be optional, so we are not forcing KeePass-compatible apps to implement something they are not really comfortable with or which they don't see the need to other than keeping users from running into frustrating issues trying to open their database on another system.

The documentation should clearly mention the advantages/disadvantages of the two variants and the current state of side-channel attacks on client devices, such that the user can make an informed decision.

And I am totally on board with that (given what I pointed out above).

[phoerious]

@DReichl Since from your last comment, I can assume that Argon2id will certainly be an option (default or no default), I submitted a PR against our code base that adds support for it. Please see #5726. Key derivation with this change has become noticeably slower with the same round and memory fill settings (not massively, but it's noticeable).

The UUID I chose is 9e298b19-56db-4773-b23d-fc3ec6f0a1e6.

[DReichl]

I've finished implementing Argon2id and have notified all KeePass port developers; you should have received an e-mail.

If anyone else wants to test it, here's the latest KeePass development snapshot:
https://keepass.info/filepool/KeePass_201203.zip
https://keepass.info/filepool/KeePass_201203_Source.zip

A database file for testing the compatibility can be found here:
https://keepass.info/filepool/KeePass_201203.kdbx
The master password is "123".

Updated documentation:
https://keepass.info/help/base/security.html#secdictprotect

[phoerious]

Cool. We'll merge ours then. I see you used the proposed UUID, so no changes required on our side.

Edit: Tried opening the test KDBX with my branch, works like a charm.

[strongbox-mark]

Great! I'll aim to get this into Strongbox asap.

[phoerious]

Our's is merged into develop with a backport to 2.6.3 pending.

Current snapshot if anybody wants to try: https://snapshot.keepassxc.org/build-66141/

[J-Jamet]

Nice! Good work! will take a little more time for me but it's also scheduled for soon.

[PhilippC]

Just released a Keepass2Android build (1.08d-r0) in https://play.google.com/apps/testing/keepass2android.keepass2android with support for Argon2id

[DReichl]

Nice, thanks!

Only support straight binary key files.
We've discussed this already. The XML key file format has various advantages; they're documented here:
https://keepass.info/help/base/keys.html#keyfiles

KeePass 2.47 (which will probably be released in the beginning of January) will introduce version 2.0 of the XML key file format (I've notified all port developers, but I'm posting a part of it here again, in case anyone else wants to test it). The goal is to make it easier to create a backup of a key file on paper. Furthermore, there are changes in the user interface of KeePass that should encourage the correct use of key files. In detail, the following things have been added/changed:

• Enhanced XML key file format (added hash that allows to verify the integrity of the key; values are now encoded using hexadecimal characters in order to improve the readability).
• Added command 'Print Key File Backup' (in 'File' → 'Print').
• In the dialog that asks whether to print an emergency sheet, there's now an option 'Also print a key file backup' (on Windows), if the master key contains a key file.
• Added command 'Create Key File' (in 'Tools' → 'Advanced Tools'), which shows a dialog for creating a new key file (random key) or for recreating a key file from a printed backup.
• Changed default key file extension from 'key' to 'keyx'.
• Key file dialogs now only show '.keyx' and '.key' files by default.
• When clicking the key file 'Browse' button in the master key creation dialog and selecting a file that is not an XML key file, KeePass now asks whether to use the file as key file anyway.
• Improved key file loading/saving error messages.

Here's the latest KeePass development snapshot:
https://keepass.info/filepool/KeePass_201207.zip
https://keepass.info/filepool/KeePass_201207_Source.zip

Example package (containing a key file, a database file, a key file backup printout as PDF, and screenshots of the UI):
https://keepass.info/filepool/KeePass_201207_Ex.zip

[phoerious]

Enhanced XML key file format (added hash that allows to verify the integrity of the key; values are now encoded using hexadecimal characters in order to improve the readability).

All right, I can get behind this. Hash checks for integrity are a nice thing to have. But I still find the other formats besides the normal hashed key file somewhat ridiculous.

Key file dialogs now only show '.keyx' and '.key' files by default.

This will confuse many users. We do that by default when generating a new key file, but many users have key files that do not end with .key. In fact, from what I can see most people have no clue about what other key file formats KeePass actually understands and even less about what format it generates by default. When we started showing warnings about non-hash key files, people's confusion wasn't about why we stopped supporting those file formats. Instead, they were convinced they were using a "normal" or "arbitrary" file, because "that's how KeePass does it" and then they were confused why we would enforce a "special" key file format. Only after we told them to actually look at what kind of key file they had been using all that time, they noticed that they had an XML key file and not an "arbitrary" file. This thing is somewhat of a legend.

When clicking the key file 'Browse' button in the master key creation dialog and selecting a file that is not an XML key file, KeePass now asks whether to use the file as key file anyway.

Okay, so that is about what we are doing with non-hash key files at the moment. To be clear, we are talking about a future file format version (KDBX5 or KDBS5 or what have you), so we don't have to be backwards compatible here. I would propose the following: For KDBX4, we keep supporting the other existing key files and for whatever comes next, we

• use the new XML format as the go-to default, since it has the obvious advantage of enabling error detection,
• hash everything that is not in the new XML format,
• drop support for the old XML, binary, and hex key files, since they are entirely silly.

[droidmonkey]

One important piece to implement if you are encouraging print out of the key file is a way to easily recreate it. The end user shouldn't have to retype XML and hash values. Recommend a way to just take the hex value key info and regenerate the rest of the file for the user. The print out should just contain the key value, not the xml bits.

[phoerious]

(added hash that allows to verify the integrity of the key; values are now encoded using hexadecimal characters in order to improve the readability).

BTW why no base64? Would be the more compact standard encoding for such things. I see hex encoding hardly anywhere these days except for SHA hash values. Binary values inside a KDBX are also base64. Is hex really "more readable"? It's certainly a lot longer.