Feature request: Obfuscate database / hide its existence

[sindastra]

I would like to be able to hide the fact that a KeePass database exists, this is useful when hosting with some commercial cloud provider. I understand the database is encrypted, the point is really to hide that it even exists in the first place.

Unfortunately, when you rename the file to look like something else, the bytes 03d9 a29a 67fb 4bb5 in the file's header mark it clearly as a KeePass database. So, I had a few thoughts on possible ways:

1. Obfuscate the database (perhaps encrypting once more, but without any header) to look like some random blob of data, or perhaps make it look like some other file type entirely.
2. Perhaps encrypt just the header with some known parameters, without adding another header on top, so that Strongbox can decrypt this and know the parameters of the database once the header is decrypted. As in, some fixed size encrypted header with known parameters, to get the real parameters after decryption.
3. Perhaps simply strip the header, and let the user manually enter parameters, similarly to Linux' dm-crypt when not using the LUKS header.
4. Make it continue to look like a KeePass database, which you can unlock and use with a decoy password; however, there would be a second database inside it, that is hidden, and gets unlocked with the real password. Similarly to VeraCrypt's hidden volume feature: https://www.veracrypt.fr/en/Hidden%20Volume.html

This is just what I could come up with from the top of my head and would require more thought.

When looking at the entropy of a KeePass database, it seems to look like random data already, except for the header.

My database:

Entropy = 7.999921 bits per byte. Arithmetic mean value of data bytes is 127.4782 (127.5 = random).

I think it's just the header that might need obfuscation, but I'm not 100% sure. (:

This issue is meant as a potential stopgap solution to #124

[strongbox-mark]

Interesting idea/use case. I can understand why you'd want this... Off the top of my head I think you'd be able maybe to strip the 12 bytes out which could be assumed to be standard KeePass 4 header. However after you did this, which might evade a naive attacker/snooper, you'd still have some identifiable info in the header (the Argon2 KDF UUID for example).

It's pretty hard to achieve what you want without basically hardcoding the KDF parameters, stripping them out and writing custom code here. There are also features like 'Custom Data' in the headers that would have to go.

I think if you've got a concern like this, ideally you should run your own hosting (e.g. grab a Linode box and setup an SFTP server, or Nextcloud via WebDAV).

I do think it that this is quite niche and so I can't promise we'd be able to look at this anytime soon I'm afraid, just too many other priorities.

[sindastra]

I thought about this, and I came up with an idea. It wouldn't be perfect, but it would be easy to implement, and would thwart the naive attack/snooper, but I think it might be "good enough" to trick automated scanning.

You probably know of WinRAR, it used to be quite popular. One thing that is interesting about the specification of RAR archives, is that "it doesn't matter what's in front of it", at least up to 1 MB. It will simply scan for the RAR 5.0 archive signature (the idea being that one can add an extractor executable in front of it, to get "self-extracting" archives, but you can still open it as a normal archive, too).

Anyway, my thought was this: What if we keep the header and all as is, but allow having some other file in front of the database? Strongbox would simply scan through the file until it finds the header, and go from there. I understand that any scan tool, could then do the same kind of scanning; however, I believe cloud drives and most file detection actually care for the signature (magic number) in the header, and don't walk through files as that would be inefficient and unusual to find anything.

Many file types don't care about "garbage data" at the end, so as a bonus, many files would continue to work as they should and not look suspicious. One should pay attention to use some typically "read-only" file type, so one doesn't accidentally erase the "garbage data" just by opening the file.

Yes, a dedicated attacker would find this, but the usual automated scanning probably not.

file innocent.zip
innocent.zip: Zip archive data, at least v1.0 to extract

And it continues to work as a zip archive. I tried many extractors, and none cared about the "garbage" at the end. (:

To avoid any confusion: That's a zip with a KeePass database appended to it. The database is outside the zip. So, when a cloud drive "previews" the zip, the database wouldn't be shown there.

[strongbox-mark]

Interesting, yes, that might help.

Unfortunately as mentioned, this won't be prioritised soon, and it's also not super "easy to implement" I'm afraid.

[sindastra]

I understand it's no priority, but I wanted to share two more ideas I had:

Encrypted Zip (or 7zip)

Zip is a pretty standard format, which nowadays supports AES-256 encryption. And 7zip, while not standard, is extremely widespread as well, which also supports AES-256. If I'm not mistaken, one can choose whether to encrypt the file list or not, so if one encrypts both contents and file list, the KeePass database would be effectively hidden.

The advantage of Zip and 7zip is that there are countless libraries that support those formats. One would have to take care to make sure to use the newer Zip format, though, as the older format uses weak encryption. Further, one should choose to just "store", as in, not compress the database, since encrypted ("random") data cannot be compressed.

The disadvantage of using an encrypted archive, is, that while the database is hidden, the fact that something is hidden, is not hidden. (:

Steghide

There's this "ancient" open-source project from 2003, called Steghide.

Steghide is a steganography program that is able to hide data in various kinds of image- and audio-files. The color- respectivly sample-frequencies are not changed thus making the embedding resistant against first-order statistical tests.

With Steghide, it is for example possible, to embed data in a JPEG, in a hidden manner. (:

http://steghide.sourceforge.net/

[milesmcclane]

You may be able to achieve which leads to a similar results as your end goal states, to obfuscate, by using a tool similar to Cryptomator? There is quite a bit of success syncing SB dbs within a container if you read up about it. It’s clear you’re hiding something, of course, but no way of knowing what. Could be a solution for you.

[sindastra]

@milesmcclane Yes, on the desktop, Cryptomator works fine for this. But on the iPhone, it currently involves manual import/export with Cryptomator. There's Cryptomator 2 for iPhone, with which it should be in theory possible to do things more automatically, however, Cryptomator 2 is very unstable (in my experience).

As for getting Cryptomator support into Strongbox, there's issue #124 for this (JFYI).

I opened this ticket here to bring up ideas for more direct obfuscation, in the hopes that this would be easier to implement than trying to support a whole container format like Cryptomator.

I understand it's no priority, though. But perhaps these ideas would be useful in the future. (: