Local master password using a resource-intensive hash function - is it secure?

Question

Encryption

Please comment on the approach to creating a local master password.
Context of the task being solved: protection of a common local password manager. In this case, we consider the issue of password strength only in the case of an attacker's physical access to an unmonitored (encrypted) storage.
Not being an expert in IT security and cryptography, after spending a day on a deeper study of the issue, I realized that there is no single universally recognized reliable method. For example, classical advice is limited to "inventing" a sequence of unusual words and, in addition, to apply some algorithms for replacing or rearranging part of the characters.
As a result, such a password can look spectacular, a feeling of reliability is created. But in fact, how many common words are there? 5000, 10000? And how many options are there for permuting the first letter, adding an underscore, changing the layout (not applicable for touch devices)? Well, we take a group of 10 people and allocate an hour of time, I doubt that the output will be more than 1000 variations that can be reliably remembered. We multiply these numbers by each other and by the length of the phrase, in the end it turns out no better than a random set of 10 characters. Those. the method is not suitable if I have not missed anything in the logical chain.
As a result, I formulated two master password rules for myself:
1. Resistant to brute force.
2. Memorable enough not to write down anywhere.
The dilemma is that the points contradict each other. In the first, the password should be really cumbersome and long, from 20 characters. But then it is extremely difficult to remember.
Can a password be both long and short at the same time? :)
It seems, maybe. We assume that the attacker knows the hash and algorithms of the original password, there is no salt. In practice, this will not be the case, but even with open source software (Veracrypt, for example), I have no way to verify this. Plus, this software is updated periodically, there may well be errors and backdoors. But the kernel is the same anyway - the hashed password.
It is mathematically proven that hashes cannot be converted back into a password. Seems like a fairly reliable statement.
Accordingly, the only option to pick up a password is brute force. Naturally, with the use of dictionaries: the same sets of words, phrases, rhymes, permutation options and everything that the "average person" can come up with. Plus rainbow tables. How many modern computing devices can generate passwords per second, already billions? OK. let it be a trillion, with a reserve for the future :)
Based on this, the following idea appeared: brute force is a brute force method, its effectiveness depends solely on computing capabilities (if the password is really random). But what if you create a password using a very resource-intensive hash function, but at the same time the "key" itself remains short ?
For example, we take the PBKDF2, Scrypt, Argon2 algorithms (the first thing that was googled). Let there be all 3 for greater reliability. We enter the key "123", the length is 50 characters and settings so that the hash generation for each algorithm takes 1 second on an average PC. Ideally, if the RAM also eats at least 1GB (I haven’t figured out yet whether this is possible). As a result, to turn 123 into a hash using the first algorithm, it takes 1 second, then we serve the resulting 50-character password as a key and generate a hash from it using the second algorithm, then similarly to the third.
At the output, 3 seconds of computing power were spent and a 50-character random password was obtained from an elementary password (hexadecimal in fact, but its length compensates for this shortcoming). Which is already physically impossible to pick up by brute force.
Ok, let's say an attacker knows that I used these 3 algorithms with such and such settings. And in cryptography, it is generally accepted that he knows. Even if it has 1000 times more power, as a result, by brute force in 3 seconds, the attacker will get 300 variations. The initial key 123, of course, is not difficult to pick up, but what if there is a random set of 7 characters here? Let 1 character be 72 variations, 72 to the seventh power is 10030613004288 variations. With 300 options per second, it takes 1060 years to get this password with 100% probability. With a 1% probability it takes 10 years. Perhaps it will suit me, given that there is neither a million bitcoins nor missile launch codes inside :)
As a result, in practice, it remains to remember the 7-digit key phrase, and the selected algorithms and settings can be written side by side in clear text so as not to complicate your life. And also choose the necessary software that in a couple of clicks will allow you to generate the necessary hash, so that in terms of time this action does not take more than manually entering even a 20-character password.
As a bonus, we get an interesting effect: it is enough to change one character for the original password (for example, add "2", "3", etc. at the end) to get a completely new hash. And it is already used as the final password somewhere else.
Question : where is the mistake, why won't it work?
I would really like to find such an algorithm for myself, based solely on mathematically verified statements, and not on the reliability of any software. For this purpose, I specifically took 3 hash algorithms in a row so that the compromise of one would not jeopardize the original key phrase.

Answer 1

This will work. Moreover, VeraCrypt, KeePass, and even Rar work approximately the same way. To get a key from a password that has already encrypted data, use some kind of KDF (key derivation function). This function is one-way, resource intensive and slow. It consists of many rounds of hashing or block encryption (where the result of one iteration serves as the key for the next, hence the irreversibility). And between iterations, a unique salt is also mixed in there so that the pre-calculations do not help to speed up the process.
The PBKDF2, Scrypt and Argon2 you googled are just such KDFs, and serve exactly the purpose that you voiced: turn a relatively simple password into a crypto-resistant key, with brute force protection.
Yes, if you turn up the complexity, you can get generally acceptable security even with a short password. Only it must be truly random, otherwise the number of options from 72^7 will be reduced to much more modest values.

Answer 2

I will answer with a simple phrase:
Peer into infinity like no one else.
Understand - create what you want.