[throwaway15908]

Ok, fine. I still dont feel comfortable, but here is the link.

https://github.com/proxemy/dotfiles/blob/master/scripts/toke...

The vault is regular kdbx with an additional password file.

Thank you for your time btw.

[pwg]

> I still don't feel comfortable,

No loss pointing out that you also publicly show the decryption script. If your system is not resilient against an attacker that knows everything, except the key, then your system would violate Kerckhoffs's principle (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).

But you still do not explain how this token relates to the vault, nor how decrypting the token is a necessary dependency to decrypting the vault.

[throwaway15908]

>how this token relates to the vault, nor how decrypting the token is a necessary dependency to decrypting the vault.

That is actually a good point i didnt fully understand myself, let me check ...

The only thing i could find quickly is https://keepass.info/help/base/keys.html

I dont know how these factors are combined. Damn. Ill keep digging. Thanks.

> Kerckhoffs's principle

An attacker from the outside needs to know 2 passwords, one for the one time decryption of the token and my master password for the vault every time.

EDIT:

Hashed. If a key file does not match any of the formats above, its content is hashed using a cryptographic hash function in order to build a key (typically a 256-bit key with SHA-256). This allows to use arbitrary files as key files.

From the link above. So my 8kb keyfile gets reduced to sha256 and used as an additional key. So this is not really a gain. A attacker does not need to guess all the random 8kb blobs, possible, just all sha256 hashes, just.

Any suggestions to overcome this reduction?

EDIT2:

There is no overcoming. When the additional key file is fixed length in the end, size of the token does not matter, its not that future proof is my conclusion.

I have to rethink this approach. Thank you so much.