[throwaway15908]

I should have said that the token file is several kb in size, about 1/20 of my vault size, and of course random noise.

I am aware that future hardware or algorithms could bring down the cost of brute forcing it, thats why ive choose several kb size.

[pwg]

> I should have said that the token file is several kb in size, about 1/20 of my vault size, and of course random noise.

None of which matters.

What matters as to whether an attacker can decrypt it is the algorithms used to encrypt the token.

[throwaway15908]

But an attacker can never tell if the current guess to crack the token is the right one. Its just random noise in the end.

[pwg]

You have not explained how the token relates to decrypting the vault.

You have also not explained how the vault is encrypted (I'm assuming it is encrypted somehow, otherwise an attacker simply downloads the vault and has your credentials).

You can't expect us to give you anything but generic statements if you don't explain how your system works.

[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.