| > So there is no possibility to brute force. Brute force is the one option that is always available to an attacker. What makes brute force untenable in most instances is the amount of time the attacker may need to wait for brute force to find the decryption key. And that amount of time is dependent upon the algorithms used and the amount of hardware an attacker is willing to devote to the brute force option. An attacker that does not have access to your vault and token can try neither brute force nor look for cracks in the method you use to encrypt the token that might allow for decryption. An attacker that does have access to vault and token is given the ability to try brute force and to look for cracks that might allow decrypting the vault. State 1 (attacker does not have the vault or token) is lower risk than state 2 (attacker has access to the vault and token). By storing your vault, and this token, in a public repository you have increased your risk. Whether the increased risk means your "locks" will be picked is unknown, but you are more at risk of having them picked than if you did not have your vault and token in a public repository. |
> An attacker that does have access to vault and token is given the ability to try brute force and to look for cracks that might allow decrypting the vault.
My reasoning for the token is, that an attack has to brute force both, the token and _after success,_ the vault. But the token is just a random blob with no HMAC and in my public repo is a script that directly tells you, that you will always get a random blob – correct password or not.
> to look for cracks
Is not possible afaik.