You are alluding to Kerckhoff's Principle. When we design cryptographic systems, we assume that the attacker will know everything about your system except for the entropy derived parts (Keys/passwords/etc, typically) - this is because we can't guarantee that they don't know details, but must assume that they don't know our generated keys. Any password generation scheme follows this reasoning - if a password scheme is said to be secure, then you can believe that an attacker knowing which scheme you're using isn't a problem.
The reason that it isn't a problem is due to the way that password namespaces work. If you demand that a user generate a password based off of a known diceware list, such as the EFF list, and you demand that it is at least 4 words long, then we can compute the namespace complexity.
First, we'll figure out the namespace of a single word - In the EFF diceware list, you roll five six sided dice and pick the result that comes up. Because there are five positions with six options, we can compute 6^5, which gives us 7776 - this simply means that there are 7776 different possible words for each place.
Now, we can compute the minimum namespace complexity of four of these words. This is simply done by taking the number of possible words and raising it to the power of the number of words in the password - 7776 ^ 4. This gives us 3656158440062976 (3.6 Quadrillion) possible different passwords of four EFF diceware words.
Now, to guess how long this would take, we have to make some assumptions -
You are using a good hashing algorithm - scrypt, bcrypt, PBKDF2, etc.
The attacker has consumer grade hardware. - We'll look at some benchmarks for an array of 8x 1080 TIs, which are top of the line at time of writing, but shouldn't be taken as the maximum hash rate - the NSA, etc probably has special hardware just for hashing passwords as fast as possible.
We can see from this benchmark that in OpenCL, an attacker with 8x 1080 Ti can attack good algorithms at the following rates:
- scrypt at a rate of ~ 6.4 million hashes per second.
- bcrypt at a rate of 184 thousand hashes per second.
- PBKDF2-SHA256 at a rate of 775 thousand hashes per second.
- SHA1 (just for comparison, don't use this for passwords) at a rate of 101 billion hashes per second.
So for our given namespace of 3.6 quadrillion possible passwords, we can compute the following expected times to crack - please keep in mind that on average, 50% of the namespace will need to be exhausted, not 100%.
- scrpyt - 571274756.25984 seconds (~9 years)
- bcrypt - 19870426304.690086956521739130435 seconds (~315 years)
- PBKDF2 - 4717623793.6296464516129032258065 seconds (~75 years)
- SHA1 - 36199.588515475009900990099009901 seconds (~.2 days)
So, we can see that you need to implement a good hashing algorithm as well.
Two things are missing from this algorithm - first, we didn't omit words shorter than 4 characters. The EFF diceware list has many words that are 3 characters long. If you increase the minimum word length, you reduce the namespace. I think the EFF list has ~500 words that are 3 characters long, but that's a guess. So, the namespace is slightly less complex.
Second, we treated these passwords are randomly derived. Because you instead wanted sentences, we need to keep in mind that sentences aren't random. If you want the sentences to make sense, then there are attacks you can perform against them - you can use Markov chains and other fun stuff to generate likely sentences rather than plain brute forcing the password. I have no statistics on how much easier this is than brute forcing, so I'm going to go ahead and say you should assume it makes a huge difference and is much weaker.