One of the more frustrating problems that a KeePass user can experience is determining whether a database can't be opened because the provided Master Key is incorrect or the database is damaged. Knowledge that a Master Key is definitely incorrect will positively impact a user's efforts to remember the Master Key and/or explore other user based causes for the failure, e.g. wrong database, wrong composite key, link to a damaged Windows User account etc. Whereas, knowledge that a database is definitely corrupt allows the user to focus on the file repair or restore options that are available. One final benefit accrues to KeePass. A user is less likely to be dissatisfied if they can assign a cause to a failure.
If it takes the same or more effort to fail to verify a Master Key as it does to fail to decrypt an intact database, the probability of correctly guessing a non-trivial Master Key is unaffected by the additional information that a database is intact. Presumably a corrupt database is not easier to decrypt.
It seems to me that a Master Key verification capability is likely both feasible and valuable provided that:
verification of a Master Key is at least as difficult as decrypting the database, and
the data needed to confirm the Master Key does not weaken the encrypted database.
I would be interested in understanding if the above analysis is faulty, or if there are additional considerations that would render the capability infeasible. One additional consideration that I am aware of, is the likelihood that a database format change would be required.
Note: If it is already possible to distinguish between an incorrect Master Key and a corrupt database then that information should be provided to the user. Presumably a credible attacker would have access to the information or has determined that it does not change the probability of mounting a successful attack.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-06-12
The error message is actually already different, at least in French and English for KP2.x
What is your current language? Do you use the latest language pack?
Regards,
Etienne
Last edit: Anonymous 2014-06-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In KeePass 1.x & 2.x I am aware of the relatively new message about the absence of integrity checks.
If I provide an incorrect Master Key during the repair import in KeePass 2.26 (dev) the the import fails without further messages. I don't have a corrupt database to test, so I am basing my comments on my memory of past posts.
In a comparable test with KeePass 1.27 the error messages don't distinguish an incorrect Master Key from a corrupt database.
The general intent of my query is to explore whether it is feasible to provide better guidance, through more informative error messages, to users that are having difficulty opening their databases.
Last edit: wellread1 2014-06-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The KDBX format has been designed to support this. KeePass 2.x does detect an incorrect master key and shows an error message indicating this ('The composite key is invalid!').
In contrast, the old KDB format does not support this. KeePass 1.x cannot distinguish between an incorrect master key and a broken database file. This feature cannot be added reasonably without breaking the current database format, which I'm not really willing to do at this time.
The error messages shown in repair mode are not useful for diagnosing the situation, as almost all checks are disabled (as intended).
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right! I got a little confused concerning the 2.x messages. My post was triggered by a 1.x post so those messages were freshest in my mind. My misdirected concerns were mostly toward 2.x. The 1.x situation is what it is.
That said, I don't think I have ever mentally integrated the full extent to which KeePass 2.x tests for various conditions before returning a particular message. Because I never saw them together, it was difficult dispel all uncertainty upon encountering an individual message, no matter how emphatic its wording.
I believe it would be helpful if the complete range of 2.x error messages were documented in Help, and the conditions that give rise to each message were expanded upon briefly. Regular users probably don't have the patience to independently raise each message through testing and users that are experiencing a database access failure certainly don't.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the more frustrating problems that a KeePass user can experience is determining whether a database can't be opened because the provided Master Key is incorrect or the database is damaged. Knowledge that a Master Key is definitely incorrect will positively impact a user's efforts to remember the Master Key and/or explore other user based causes for the failure, e.g. wrong database, wrong composite key, link to a damaged Windows User account etc. Whereas, knowledge that a database is definitely corrupt allows the user to focus on the file repair or restore options that are available. One final benefit accrues to KeePass. A user is less likely to be dissatisfied if they can assign a cause to a failure.
If it takes the same or more effort to fail to verify a Master Key as it does to fail to decrypt an intact database, the probability of correctly guessing a non-trivial Master Key is unaffected by the additional information that a database is intact. Presumably a corrupt database is not easier to decrypt.
It seems to me that a Master Key verification capability is likely both feasible and valuable provided that:
I would be interested in understanding if the above analysis is faulty, or if there are additional considerations that would render the capability infeasible. One additional consideration that I am aware of, is the likelihood that a database format change would be required.
Note: If it is already possible to distinguish between an incorrect Master Key and a corrupt database then that information should be provided to the user. Presumably a credible attacker would have access to the information or has determined that it does not change the probability of mounting a successful attack.
The error message is actually already different, at least in French and English for KP2.x
What is your current language? Do you use the latest language pack?
Regards,
Etienne
Last edit: Anonymous 2014-06-12
I use English, no language pack.
In KeePass 1.x & 2.x I am aware of the relatively new message about the absence of integrity checks.
If I provide an incorrect Master Key during the repair import in KeePass 2.26 (dev) the the import fails without further messages. I don't have a corrupt database to test, so I am basing my comments on my memory of past posts.
In a comparable test with KeePass 1.27 the error messages don't distinguish an incorrect Master Key from a corrupt database.
The general intent of my query is to explore whether it is feasible to provide better guidance, through more informative error messages, to users that are having difficulty opening their databases.
Last edit: wellread1 2014-06-12
The KDBX format has been designed to support this. KeePass 2.x does detect an incorrect master key and shows an error message indicating this ('The composite key is invalid!').
In contrast, the old KDB format does not support this. KeePass 1.x cannot distinguish between an incorrect master key and a broken database file. This feature cannot be added reasonably without breaking the current database format, which I'm not really willing to do at this time.
The error messages shown in repair mode are not useful for diagnosing the situation, as almost all checks are disabled (as intended).
Best regards,
Dominik
Right! I got a little confused concerning the 2.x messages. My post was triggered by a 1.x post so those messages were freshest in my mind. My misdirected concerns were mostly toward 2.x. The 1.x situation is what it is.
That said, I don't think I have ever mentally integrated the full extent to which KeePass 2.x tests for various conditions before returning a particular message. Because I never saw them together, it was difficult dispel all uncertainty upon encountering an individual message, no matter how emphatic its wording.
I believe it would be helpful if the complete range of 2.x error messages were documented in Help, and the conditions that give rise to each message were expanded upon briefly. Regular users probably don't have the patience to independently raise each message through testing and users that are experiencing a database access failure certainly don't.