Extra encryption options

[awsdert]

Summary

1. I want the option to encrypt my database by my password, to the point that it cannot be unencrypted without the password.
2. I also want to select extra encryption options when creating a database / changing it

Examples

LastPass.com is an active example of the by password option. For the 2nd one the encryption UI would have something like this:

Encryption:
1. Method: [SHA256] Seed: [0xDEADBEEF] [-]
2. Method: [Password] Password: [Example1234] [-]
3. Method: [AES] Seed: [0xC0FFEE] [-]
[+]

Context

Doesn't feel secure enough if I can't at least encrypt by password, also having multiple layers of encryption that can use different methods forces more time to be put into brute force decryption, even on quantum computers - which lets face it, countries at bare minimum will certainly employ against each other, why would they then not turn that tech they already have on us if they deem it worth doing so?

[awsdert]

For the implementation method to be compatible with existing databases, assuming you store the method in the file as a string then just put "Multiple" then anything that supports it will expect the initial bytes to be a list of decryption methods to use, in the order they're to be used, if it's just a number (which doesn't seem very flexible to me) then just take some value from the reserved range (I'm sure you wouldn't already have 127-256 different encryption methods in use yet).

As for the encryption by password I would turn treat the password itself as a bignum seed and employ basic LSHR random number generation with it, can then just just add to each byte in the database the number it spits out modulated by 256, here's some pseudo code:

Encryption:

for ( i = 0; i < db_size; ++i )
{
    alup_rand_r( bignum, bits, password, len * CHAR_BIT );
    dbmem[i] += bignum[0] % 256;
}

Decryption:

for ( i = 0; i < db_size; ++i )
{
    alup_rand_r( bignum, bits, password, len * CHAR_BIT );
    dbmem[i] -= bignum[0] % 256;
}

Edit: Made a mistake in the loop, fixed it. Also the alup_rand_r is something I plan to make in my ALU project (Aiming for full ANSI C), not to sure about the name & parameters but that's what I would go with roughly, the project is MIT licensed so feel free to copy-paste the code you need from it, I haven't finished with the FPN stuff yet but the integer stuff should be ready to go, division by 0 yields 0 as it should, if you don't change the original value when "dividing" then you have 0 changes to count

[droidmonkey]

I'm really not sure what you are asking for here, but it's not going to happen. You can use a key file and/or hardware key in addition to password if you like.

[awsdert]

A key file does not solve the fundamental problem, AES etc are known standards, there's no variation in what to expect when brute forcing decryption, on the other hand passwords vary wildly and thus exponentially increase the decryption time if used as an additional layer of encryption as I'm requesting, is the goal of KeePassXC to be as secure as can possibly be for the most sensitive data anyone can have? It should therefore be a natural requirement to enable layered encryption as I've asked and password encryption to multiply the difficulty of brute force decryption via quantum computing which will sooner or later become a common place thing just as computers themselves became a common place thing.

[droidmonkey]

I don't think you know what you are talking about to be honest.

[awsdert]

What makes you say that?

[awsdert]

Really? Just gonna ignore me when I ask a legitimate question? You do realise employers check how you treat users when you go looking for work right? What if they come across this thread and see your attitude to someone who was civil/polite throughout the thread? Even if you don't like responding to me at least show you have enough professionalism to answer my questions.

Edit: To be clear I, nor anyone worth responding to, would expect you to answer immediately but 2 days without a answer of any kind? Even you have to admit that's unreasonable.

[awsdert]

droidmonkey, if you're going to criticize someone at least explain WHY you're criticizing them, otherwise you're just being an ass

[michaelk83]

I'm not an expert, but to the best of my understanding:

KPXC already encrypts the database using a key derived from your passphrase and other credentials, using industry standard methods that are designed to make brute-forcing impractical. I expect they will update their algorithms as new developments are made in the industry, as they have done before. You're not going to gain any additional security by adding another layer of (amaturish) encryption when KPXC does multiple rounds of encryption already. Just use a strong passphrase.

And read the manual: https://keepassxc.org/docs/KeePassXC_UserGuide.html#_database_settings

[droidmonkey]

Thank you, that's exactly what I was going to write. I'm too busy to rewrite our user guide on every post though.

[phoerious]

To be more precise: A randomly generated key file is a lot stronger than most passwords. The only downside is that it's stored in plaintext on the hard disk. You solve that problem by using a YubiKey instead. So no, we are not going to add another rather arbitrary layer of "password encryption" on top, since the password you enter is already used as part of the encryption key, so adding one more offers no additional security. But thanks for your suggestion.

[awsdert]

I'm not an expert, but to the best of my understanding:

KPXC already encrypts the database using a key derived from your passphrase and other credentials, using industry standard methods that are designed to make brute-forcing impractical. I expect they will update their algorithms as new developments are made in the industry, as they have done before. You're not going to gain any additional security by adding another layer of (amaturish) encryption when KPXC does multiple rounds of encryption already. Just use a strong passphrase.

And read the manual: https://keepassxc.org/docs/KeePassXC_UserGuide.html#_database_settings

I gave up on this thread, but this was helpful, a lot more clear than "you don't know what you're talking about" and yes I do use a strong passphrase, it just doesn't feel like enough.

Anyways what about the multiple encryptions bit? Why was that refused? Also mind pointing me to what was used to develop KeePassXC's algorithm for encrypting by password? I only gave that example because I couldn't think of any other way to do it fast while still requiring the original password/passphrase, using the password/phrase as a seed instead of the actual numbers used to encrypt the data seemed more secure than using the password directly to encrypt the data.

[awsdert]

To be more precise: A randomly generated key file is a lot stronger than most passwords. The only downside is that it's stored in plaintext on the hard disk. You solve that problem by using a YubiKey instead. So no, we are not going to add another rather arbitrary layer of "password encryption" on top, since the password you enter is already used as part of the encryption key, so adding one more offers no additional security. But thanks for your suggestion.

Never heard of YubiKey before now (used to just use LastPass for managing my passwords but out of work right now so the password strength feature is lock away behind a paywall) but after looking it up I realise I would need to fork out for it (which I can't afford to do right now), if I remember rightly KeeWeb uses the same databases, do you know if that provide the 2 factor authentication YubiKey is meant for?

[awsdert]

Thank you, that's exactly what I was going to write. I'm too busy to rewrite our user guide on every post though.

It's not the user guide that I needed though, I already have a strong password and I'm using maximum encryption instead of the default 100 or whatever it was, it still doesn't feel enough though, also it wasn't clear in the UI that the password would be used as part of the encryption process which is why I brought it up, design the UI well enough and the guide will be redundant.

[michaelk83]

Anyways what about the multiple encryptions bit? Why was that refused?

They're already doing multiple encryption rounds. (Technically, the multiple rounds are on the password, to generate the key that is used to encrypt the database. But that's good enough, since it essentially creates a near-random very long key, which is impractical to brute-force; and you can't decrypt the database without the correct key.)

I already have a strong password and I'm using maximum encryption instead of the default 100 or whatever it was, it still doesn't feel enough

It doesn't feel enough because you don't understand what is being done and what the threats actually are. Or so it seems.

Also mind pointing me to what was used to develop KeePassXC's algorithm for encrypting by password?

Do read the manual section I linked to. It lists some of the algorithms that are being used. Those are industry standard algorithms that you can read about online. Read how they work, and why they were designed that way. It's not our job to teach you about encryption, and this isn't the place for it.

KPXC uses a 3rd party library for the implementation, currently Botan (previously libcrypt, IIRC). You can read about it on their website and read their code on github.

I only gave that example because I couldn't think of any other way to do it fast while still requiring the original password/passphrase

These algorithms have been developed over decades by multiple professional teams, with others looking for weaknesses, and still others finding solutions to those weaknesses. You're not going to get better results by thinking something up in a just few minutes.

using the password/phrase as a seed instead of the actual numbers used to encrypt the data

That is already what is being done.

[awsdert]

Anyways what about the multiple encryptions bit? Why was that refused?

They're already doing multiple encryption rounds. (Technically, the multiple rounds are on the password, to generate the key that is used to encrypt the database. But that's good enough, since it essentially creates a near-random very long key, which is impractical to brute-force; and you can't decrypt the database without the correct key.)

It's only impractical for current computers, for quantum computers it's still very practical which is why I suggested the multi-layer encryption, I don't mean multiple just on the one encryption method, I mean multiple methods layered one after another, it's only a matter of adding a UI, a loop that calls the existing handlers and adding a code/id for the loop to be identified for decryption, that's not a lot to ask, maybe an day's work at most, not unreasonable.

I already have a strong password and I'm using maximum encryption instead of the default 100 or whatever it was, it still doesn't feel enough

It doesn't feel enough because you don't understand what is being done and what the threats actually are. Or so it seems.

I understand the threats, getting hold of my password (not possible as I keep it in my head) and brute force decryption using the 100s of processors a GPU or quantum computer has. That quantum one is the one that concerns me as it WILL become a reality in time.

Also mind pointing me to what was used to develop KeePassXC's algorithm for encrypting by password?

Do read the manual section I linked to. It lists some of the algorithms that are being used. Those are industry standard algorithms that you can read about online. Read how they work, and why they were designed that way. It's not our job to teach you about encryption, and this isn't the place for it.

I didn't ask you to teach me how to encrypt, I asked you to point me to the resources used to develop what XeePassXC uses, I'm sure a few links where noted even if not all of them were.

KPXC uses a 3rd party library for the implementation, currently Botan (previously libcrypt, IIRC). You can read about it on their website and read their code on github.

That's more helpful, thank you, that's what I meant be pointing to the resources used for development.

I only gave that example because I couldn't think of any other way to do it fast while still requiring the original password/passphrase

These algorithms have been developed over decades by multiple professional teams, with others looking for weaknesses, and still others finding solutions to those weaknesses. You're not going to get better results by thinking something up in a just few minutes.

I wasn't expecting to, I was just giving a bit of pseudo code for a possible implementation of a layer of encryption, I would not expect it to be used by itself if at all.

using the password/phrase as a seed instead of the actual numbers used to encrypt the data

That is already what is being done.

Glad to he- er, read it.

[michaelk83]

AFAIK, there are no multiple algorithms to use. There are different ones for different purposes, and there are outdated ones, but not like a library of interchangeable ones. Coming up with your own is likely to only be weaker than the existing ones. And the whole exercise is futile, because if KPXC can tell which algorithm was used, so can an attacker. It's more useful to use a stronger key. But you get diminishing returns past a certain point (which is still plenty strong enough for today's threats).

The algorithms currently used are specifically designed to make it hard for GPUs. I don't know about quantum computers, but I doubt they're as much of a threat as you think. That's what I really meant by "don't understand what the threats actually are". Yes, they are coming, but not anytime soon, and not to someone's desktop. They are clunky and complex machines that require an engineering team to maintain and operate. Does any organization that can operate them, actually care enough about your personal passwords, to waste such expensive resources on you (or on any of us here)? I doubt it.

Maybe they'll be a bigger threat in a decade or so, but that's a long time in the software world. And meanwhile, security expects do know they are coming, and are working on ways to deal with them. When such developments come out, I'm sure the team here will adopt whatever new best practices that such experts will come up with. But we are not there yet.

[awsdert]

I don't mean coming up with my own, what I mean is you let the user decide at list of algorithms to use and in what order to then one by one apply each algorithm to the data or what the previous algorithm "returned", then in order to decrypt it they would need to do the same in reverse, each time a "password" algorithm is encountered during the decryption process the UI would prompt the user for the appropriate password and continue once they've given the right one (assuming there's some way of checking that, else just bulldoze on and report whatever error/s encountered when possible). The point of saying "multiple" in the database is just so the current database format can be used and any software that doesn't understand "multiple" to mean "at start of data read a list of decryption algorithms to use, when done you'll be at the start of the actual data" will just say "unsupported format" or "corrupt data", either way it will not decrypt it.

Edit: The advantage of this method is that you can then use multiple passwords with a layer of encryption in between each used password, that means any hacker would then have to acquire not just one password but as many as the database needs to be decrypted and know at which nth layer those passwords should be used.

Edit 2: As for who cares about my passwords enough to brute force them, countries might not but what about criminal organisations or worse, actual companies that claim to have our "best interests" at heart, at least the criminal organisations don't put up a pretense once they've got a hold of details you don't want them to have, the companies on the other hand try to deceive you on top of trying to take every last pence you have. Either way both of them have the money to afford that equipment for using on many people.

[michaelk83]

Do read about what the existing algorithms actually do, and why, because what you're suggesting doesn't add anything useful. Moreover, asking for multiple passwords is just a recipe for data loss. Users have enough trouble with just one password.

But you can treat the "multiple passwords" as just one long passphrase, with different parts of it being used in different parts (or stages) of the encryption. That's pretty much what already happens (obviously, it's more complex than that).

Anyway, use a longer passphrase if you want, and use a YubiKey if you want a 2nd credential. (And sounds like you may want to invest in a good tinfoil hat, while you're at it.)

[awsdert]

I'm not saying multiple passwords should be mandatory, just an option for those confident enough to not forget or at least able to make hints for themselves that don't directly give away the password / passphrase, both of which I am.