Topic: Measuring the randomness of a seed phrase (Read 661 times)

Measuring the randomness of a seed phrase is indeed an interesting topic. While I'm not aware of a specific software tool that provides a 0-100 scale for randomness, it's crucial to understand the concept of entropy in seed phrases. Quality computer-generated seed phrases tend to have high entropy, making them more secure.

Measuring the randomness of a seed phrase is indeed an interesting topic. While I'm not aware of a specific software tool that provides a 0-100 scale for randomness, it's crucial to understand the concept of entropy in seed phrases. Quality computer-generated seed phrases tend to have high entropy, making them more secure.

I would suggest you stop reply to post with main purpose of SEO spam, which sometimes padded with AI generated text to make it less spammy.

Yes, clearly. If I can predict what you would choose 1% of the time versus I can predict what you would choose 10% of the time, then that's an order of magnitude difference.

They really aren't. There is no evolutionary advantage to imagining or visualizing completely abstract random numbers. There is, however, a strong evolutionary advantage to noticing patterns, sequences, order, and so on. Our brains are hardwired to be ordered and logical, which is why we are so terrible at picking random numbers and why there are tens of thousands of examples of brainwallets being hacked.

There is a package called rng-tools, originally written by Jeff Garzik, which will do this:

https://github.com/nhorman/rng-tools
https://linux.die.net/man/8/rngd

Shot noise, as you would get from a webcam pointed at a light source, can be a source of true random numbers.

If we are able to measure the randomness of a seed phrase, then we will be able to configure bruteforce software in a way that it will be able to try to generate certainly random seed phrases, right? If true, then it remains questionable, whether 99% randomness is better than 90% randomness.

And you, definitely can't be more random than a computer because computer can calculate millions and billions of possibilities in a second and choose the one option out of millions and billions while your brain only generates one process at that moment and at the same time thinks how random it would be. Computer doesn't overthinks about randomness but you do. You follow your logic, a certain way.

I didn't know you can do this. Stack Exchange) suggests feeding it with basically a microphone or webcam. To quote:
I've never worried about this.

For your example, i would worry more about
1. Human error when entering value (e.g. you enter GDP of Belgium on 1982 rather than 2021) or performing calculation.
2. Whether you can reconstruct seed phrase in the future. If you don't have backup of the source data, you'll have to re-find it on google search where the information could be different due to various reason such as number precision or history manipulation.


Or just feed your string to /dev/urandom instead. I believe you can do that with echo "example" >> /dev/urandom, although i don't know whether it's proper way to do it.

Exactly That's why it's impossible to check if a seemingly random string was created randomly.

I'd say it's unlikely to be brute-forced. But I still don't see the point: if you want to create your own random, just flip coins.
If you want it to be something you can remember and reproduce later to restore your seed, then the examples you gave are terrible. Chances are you forget parts and can't find back all details.

Why not use both? Create your own string, and simply add it to a random coming from a random number generator. Kinda like the way Split key vanity addresses are created. As long as at least one of the strings is random, the result is random.

Yes, it is demonstrably less random. Whether it is less random enough to be bruteforced depends on your starting points and how many factors you use, I would assume.

As ranochigo has explained, the random number generators you would use on your computer or hardware wallet to generate a seed phrase perform a similar process of taking a bunch of different numbers and combining them. However, you are picking constants which can be known to anybody who looks them up. An electronic CSPRNG will draw entropy from things like interrupt timings and thermal noise, which are impossible for an outside observer to know. You are proposing simply multiplying these numbers together, whereas your CSPRNG will use a combination of functions, including things like XOR and one way hash functions to combine these data in more difficult to predict ways.

To respond to your proposed method, it might be difficult to bruteforce that, because no one would probably try to string the exact same multiple factors together to form a seed. However, the predictability of that would be far lower than what your CSPRNG gives you and for a very simple reason. Both of them usually works in the same way, but rather, the CSPRNG that is included usually takes in multiple non-deterministic and random variables (hardware interrupts, keyboard timings, timers, etc) and in addition to that, an algorithm to debias and whiten the entropy. When talking about absolutes, our algorithm is definitely more unpredictable because they are non-deterministic processes.

However, by using a bunch of factors that are known to everyone, the probability of your seeds being predicted is far higher than one which uses inputs from random processes which no one can feasibly guess. The advantage of having CSPRNG that is random enough such that any adversary has no idea of how the states where at the point of generation is what makes cryptography secure. Your selection of factors might be arbitrary and random (but arguably not) yet the factors themselves are pre-determined. Besides, it doesn't offer significant advantage, using known variables as a source of entropy rather than using a RNG.

The main question would that is it consistently secure enough over multiple iterations? Probably not. The CSPRNG present in your OS is definitely consistently more un-predictable in comparison.

Thank you for continuing to engage with the thought experiment.  Well yes, if someone were to use something like this, the factors would have to be kept private and the calculations for each would have to be done offline, via library archive, books and family records, etc.  The interesting question to me, isn't whether the result could be raw bruteforced, but rather is it demonstratively worse/lower quality/less random/less entropy (semantics in this regard aren't my strongpoint, choose the appropriate term) than a CSPRNG SW-generated phrase.

And again, from what I can tell throughout this whole thread, is that it is likelyworse... but ultimately cannot be demonstrated as such.

Obviously it's not random in the sense it is a constant which can be reliably reproduced over and over. But it is random in the sense that its digits are randomly uniformly distributed (as far as we can tell).

On a tangent here, but I can tell you that's not a "quality" seed phrase because it has an invalid checksum.

It's more that if a human created it, then we know it will have less than 256 bits of entropy. The matching game ranochigo linked to on the first page shows that if you are manually picking 0s and 1s, you aren't random. If you randomly pick words from the list, there is an inherent bias and you aren't totally random there either. Even if you toss a coin, there is a human instinct that if you tossed TTTTTTTTTTTT to think "that's not random enough" and throw it out and redo those tosses. Will the seed phrase you end up with be completely insufficient and able to be hacked? Maybe, maybe not. But it will almost certainly have less than 256 bits of entropy.

If you want to follow that logic, then we should also be excluding every key which has already been used? In fact, if you want a 256 bit key, then you need to immediately exclude all numbers with leading zeroes, which is half the range from 1 to 2²⁵⁵.

To raw bruteforce with no knowledge of what you have done? No, probably not. But given that you've just typed all these things in to Google, there are now dozens of servers around the world that know you had a specific interest in these numbers at the same time for some reason.

If you don't trust your OS's /dev/urandom, then aside from getting a new OS, I would suggest the best way to manually generate a seed phrase is from coin flips, specifically using Von Neumann's algorithm as I have discussed here to remove any potential bias.

What about:

Taking your favorite football running back, taking his career yards gained and converting that number to millimeters.  
x
GDP of Belgium (or whatever country of your choice) in 1981 (or whatever year), converted to Japenese yen (or whatever currency) in trillions (or to whatever point the '0's start due to rounding).
x
pi from 34 to 47 decimals (or choose the range randomly), find the nearest prime number
x
number of minutes between when your maternal grandparents were married to when the second tower fell on 9/11.

(you don't know who I am, my favorite team, when I was born, who my grandparents are).

Then from that string of numbers, systematize taking numbers between 1-2048 from the string (so any number 1-2048 has equal chance).  Mix up the resulting 12 outputs and draw them out of a bowl one at a time.

This would seem "sufficient" to me.  Thoughts?  Of course, it's a lot more effort than just using a generator, and you're liable to leave a trace of all the research being done here (and maybe that's part of the point), but as a thought experiment, I don't see how a system like this or something similar could be vulnerable to bruteforce.  Particularly if you know nothing about me, I don't see vulnerability in factors 1, 2 and 4 (number 3, ok, prime numbers get scarce as you go up...).  The only thing that could be a problem is that those factors may not generate as many digits as I would like, you'd need to come up with more and more such factors.  Also, you'd have to keep these factors off computers, which would require a lot of hand-calculating, then burn the evidence, etc.

Edit:  Also, I don't know if the multiplication of large numbers leaves vulnerabilities.  If so, other mathematical "mixing" functions could be substituted instead.

Yes, in the best case, it is like writing code, that is almost equivalent to "if(false)". However, there are two important issues:
1. It makes code more complex, which means that in case of some bug, it is more likely to do something stupid. For example: by negating some condition, you could accidentally get the code that generates only keys with patterns, instead of only keys without it.
2. By picking "the list of numbers that should be excluded", implementers will fall into the trap of randomness. They are trying to exclude interesting numbers, and often end up with excluding too much. It is like trying to eliminate numbers that are divisible by 2, because they are even. Then by 3, because they are also non-random. And ending up with Ulam spiral, where those prime numbers (that were left after exclusion) can still form lines, so an attacker trying to linearly find keys, can still reach them.

Depends actually, in certain cases, we can and in some I can't do so. For example, if I ask you to think of 12 phrases, do you think you've chosen them because they have some sort of association with each other and something that you've seen before? Some cases that I thought of:

Base case:
User select the best 11 words that they like the best and calculate the 12th, assuming BIP39 checksum. It would be vulnerable for obvious reasons, it shouldn't take too long to build a dictionary of the most commonly associated phrases and bruteforce them. This would be very predictable, build a RNN and scrape all of the known data sources for words association.

Next best case:
User randomly selects 11 words from the wordlist by scrolling down the list on their computer, stops at random timings and records down the first phrase that they see, and calculate the last word for checksum. Possibly random, but probably not, humans are inherently bad at estimation and they cannot possibly be always random at deciding stop points. This is still predictable.

Next case:
User lists out all of the words on a giant piece of paper and uses a dart to throw at it, while being blindfolded and records all of the words that the darts land on. Possibly random, but not exactly random because the way that the user throws the dart can result in it being biased. This can somewhat still be predictable, though arguably less than the previous two.

Of course, non-exhaustive cases but human errors are often present when entropy is involved. There are possibly cases where your selection can be random and unpredictable, or they can be still associated with each other depending on your actions and how much it compromises your ability to be random. You can select the words yourself and it can be random but chances are, human influence would result it being less random and less secure than it can be. Rather, if you were to use known sources of randomness which were put through rigorous testing and debiasing/whitening algorithm, then your entropy would probably be much much better than the former.

Remember, the speed at which bruteforcing is done is pretty quick and having anything that is predictable/less than random would narrow down the search range significantly. Leaving something like this up to chance wouldn't be a ideal.

No. It's just as secure. Being 0.00000000000000000000000000000000000000000000000000000000000000000000001% more secure doesn't matter. It's just a waste of programming for something that's never going to happen.

Sure, but don't you make it, in the very least, more secure if you exclude numbers like 1, 10, 888, 2^256 / 2 etc.? There's astronomically small chance of being selected, but there's an unnecessary chance. Unless there's a reason we shouldn't exclude that subset, which probably lies on the "how to" situation.

So, the answer to why we shouldn't exclude that insecure subset, is that we're likely to make less secure the rest of the numbers of the set. It makes some sense, yes.

We would have worse security. If you exclude 888 explicitly, then you could still reach 1234. If you exclude all numbers below 2^32, then you could still reach 2^33, and someone doubling the base point could sweep that after 33 point doublings. If you introduce a lot of exclusions, based on a lot of patterns you noticed, then you could downgrade your "n" to a smaller number than something around 2^256, and then you will no longer have 128-bit public key security.

By leaving things as they are, and picking a number from the full range, the whole strength is in the algorithm itself, that is battle tested by many users for many years. Since 2009, it is also covered by money they put on their keys, and that cryptography is so strong, that those who lost their keys, still cannot get their old coins. As long as you can see that many coins from the earliest blocks are not moved, you can be quite sure that the algorithm used by Bitcoin Core to generate them, is good enough.

Trying to change that, is similar as if you wanted to design a hash function, that would never produce a lot of leading zeroes, because that result "looks non-randomly". Of course, you can pick any theoretically ideal fully random number generator, and then produce a lot of data. Then, after producing 2^32 hashes, you could find one with 32 leading zero bits, and complain "hey, this random number generator produced a non-random number!". But this is not the case. If you needed 2^32 different results to get that single value, which have 224 bits, instead of 256 bits, then your generator is still good enough.

So, it is better to leave that unlikely opportunity to generate private key 888, than to "fix" it, and making cure worse than the disease.

If you pick a number between 1 and 2^256, you don't have to worry about "border cases". The search space is large enough to be absolutely sure it won't be 888 (I mean: 000000000000000000000000000000000000000000000000000000000000000000000000000888).
If you're a bank handing out 4 digit PIN codes, you may want to avoid codes like 0000, but that's only because the search space is very limited.

Thank you for the entire response.  I want to pick up on this point.  No issues with your statement of not being able to positively prove randomness for the reasons you stated.  I would think though you could test the inverse.  Can you prove that a human-generate seed isn't random (or rather, is patterned/predictable).  I'm not suggesting that all 2048^12 possibilities are scorable for randomness on a scale.  I'm saying that if we know some are not sufficient, we should know why they are not sufficient and to what degree they are patterned/predictable.  At some point we will hit a limit, but what is that point?  

The chances of your wallets selecting those subset of numbers is astronomically low. You have 2^256 to choose from, I highly doubt you would ever get any address anywhere near those that were already tried. It would be a massive waste of resources to keep those indexes and limiting the pool of numbers wouldn't be that ideal either.

Yep, that is correct. Cognitively, the human brain works by associating events together through a part of their memory. If a human were to think of a certain string of phrases, chances are the phrases appeared somewhere before and they chose that specific string based on some form of recollection. You can possibly prove it, if you were to scrape all the data there is on the internet, it might be inconclusive because they aren't exhaustive.
The former is generally true but the latter would depend on the quality of the source of entropy (are they deterministic or stochastic processes?), the way the entropy is processed and how it gets used. Desktop wallets generally use entropy given by /dev/random (which by itself uses multiple sources of entropy -> debiasing before initializing the CSPRNG) , sometimes XORed with other random data and this is more than sufficient for our uses. There are flawed implementations out there, but so long as it has been rigorously tested and correctly implemented, it will be secure.
It was a pretty fruitful discussion! My initial venture into cryptography was filled with question like these as well, glad that you're bringing these topics up to discuss!

That means that a software should not mark 888 as a good choice, because while random, it is not secure. So there exists a subset of numbers that are not secure but are random. Is it wrong to think that if we excluded that subset, we'd have better security? Seems to me like the problem lies how to do it, and not on if it's wise to do it.

There is no such barrier. Again, the same answer, and the same link I gave you is still relevant: https://xkcd.com/221/


That means, you are good to go, if your key is generated in a way, that is hard to repeat by someone else. By this definition, 888 is not a good choice, because there are bots scanning keys from the base point upwards, and sweeping anything they could find. The same for Pi: it is a bad choice, if you use it directly. However, nullius created a puzzle based on that, and after many years, it is still not taken.

So, the answer to your question is: anything that could not be guessed by others, is random enough. Of course, if you are not an expert in cryptography, then trusting some wallet like Bitcoin Core is better than making your own algorithm from scratch.

Thank you all for the insights.  I hope it's understood, my intention isn't to be contrary, I'm trying to better understand this for myself and that it's purely for sake of the enjoyment of learning something new.  Further, I'm not trying to justify or convince anyone that a person can better produce a seed than a computer.


If I give you the following list of words:  
rookie, brand, fossil, soda, arena, neutral, mango, yellow, ticket, chair, reunion, husband

What I'm hearing is, the only way you can tell me, if this is a "quality" seed or not, is if you are told what generated it.  

• If it was a CSPNG that created it, then it's sufficiently random/unpatterned.  
• If I created it, then by way of natural human cognitive bias, there must be/highly likely to be some pattern that is more guessable by some computer program.  

But there's no way a computer program can ever tell if it's indeed quality or not based on the list itself.  We just *know* that if a human created it, it's certainly insufficient and if a CSPNG SW program created it, it is positively sufficient.

If what I've stated above correctly represents the consensus on this topic (albeit in a simplistic way), the logic of this still eludes me.  If there is agreement among the geniuses in the world that study this stuff for a living that this is indeed the case, then I guess I will just add it to one many of life's mysteries to me.  I'm new to this board, I hope I didn't immediately embarrass myself for asking the question!

One thing I never understood is what sets the barrier between looking random and being random. For example, number 888 has the same chances theoretically to be picked between 1 and ~2^256, but it shouldn't, even if the process was completely random, because anyone playing with strange numbers can compromise the key. So you don't want a completely random process, you want one that generates randomly looking numbers, which raises the question of which numbers are looking random, or more importantly, which ones don't?

What proof do we have that Pi is random, even if not definite? Do you mean it is very questionably random?

Depends on implementation. Brainflyer is astonishingly good at cracking V1 Brainwallet phrases. Scrypt with salt would slow the process down a lot but I definitely wouldn't trust my money with it.

Unfortunately, that is the best that we can do. As we've said, the predictability of a seed or a random binary string cannot be determined from a single sample and that you need a relatively large sample to be able to ascertain that it is free of bias, and therein lies the question; how big of a sample size is sufficient? The answer is definitely not just a few of them and would possibly just be infinity.

The whole concept of "Don't trust, verify" comes with the fact that we are able to determine the authenticity of binary files with hash functions, or ability to inspect the code before compiling the code yourself. Entropy is unfortunately, something that you cannot measure and trying to evaluate a random process with certainty would be absurd (because then it won't be considered unpredictable anymore). ** Though note that urandom actually estimates the amount of entropy that is being added to the pool, but that involves a constant stream of data.

/dev/(u)random provides sufficient entropy for all the cases that we need. You can certainly generate your own entropy, a fair unbiased dice, atmospheric noise or the decay of an uranium ore if you want something random. I'd like to think of the security of Bitcoin as a binary result, "sufficient" or "insufficient". If you were to use a fair unbiased dice (6 sided), record down 99 rolls and calculate a SHA256 hash of that, I guarantee that the entropy would be sufficient (not perfectly perfect, but I won't have any doubts about it). What is the possibility that someone replicates all of your 99 rolls, with the same numbers, in the same exact sequence?

Indeed in all integer bases greater than or equal to 2.

If it were possible to check if the numbers being outputted were indeed completely random and cryptographically secure, then there wouldn't be such a large field of research dedicated to random number generators, or so many cases of weak random number generators leading to wallets bring compromised. Testing a single output as you are suggesting is meaningless. Let's say I toss a completely fair coin five times and get the following results: HTHHT. Fine, that looks random enough. Now I do it again and get TTTTT. Wait, that doesn't look random at all! Why? Both of those sequences had exactly a 1/32 chance of occurring.

A Chi-squared test simply tests for bias. It cannot tell you whether you are generating actually random numbers. It also requires multiple observations for each expected value, so cannot be applied to 256 bit numbers.

The issue here is there are potentially trillions of text inputs to analyze, so it becomes largely impractical to test the seed phrase against all of them (that is not mentioning the many different and creative ways the inputs could be transformed into the seed phrase).

It becomes more of an issue to analyze what are the more common ways people abuse randomness to make random-looking but statistically speaking, weak sequences, and I don't think you'll get very far with that without machine learning.

The issue is not the term you are using, it is what you are measuring. When you measure randomness, you are measuring the process and not the result itself. So, the question should be "how random is the process that generated this string of bits?" and not "how random is this string of bits?" The reason is simply that in a purely random process, every result is equally likely and thus equally hard to guess.

The problem of results with identifiable patterns is not that they aren't random results, it is that they are potentially results from a non-random process, and it is much more effective to attack non-random processes. However, the likelihood of generating such results using a random process is low enough that it is not a problem. For example, a password that happens to be one of the 1 million variations of the most commonly used 8-character passwords would be trivial to guess, but the odds of a random 8-character password using letters and numbers being one of those is 1 in 2 billion.

OTOH, there are statistical methods of evaluating the randomness of a process using the results. One example is the Chi-squared test. The accuracies of these tests depend on the amount of data and a single seed is not enough to be useful.

Thanks all.  Interesting discussion.

Perhaps my semantics weren't the best, using the word "randomness" whereas a better word could have been "non-patterned". 

If the randomness or "non-patternedness" isn't quantifiable/measurable as is the consensus here, then the scientific method can't be fully applied to the effectiveness of seed generators.  We only get to hypothesis based on deductive reasoning.  To judge the quality of outputted seed phrase solely on what generated (such as CSPRNG) it, rather than something intrinsic to the phrase itself that is testable, seems to violate the "Don't trust, verify" principle, no? 

It is still an open question whether pi is  normal or not. Academics continue their discussions on this matter. Read for instance the brief on the results obtained by David H. Bailey from Lawrence Berkeley National Laboratory which emphasizes "that the new result he and Crandall have obtained does not constitute a proof that pi or log(2) is normal".

So, before taking any conclusion on my statement, DYOR,  and don't rely entirely on Wikipedia. There are plenty research works on this matter.

And to conclude - just nice citation supporting my thought:

Pi is believed to be normal in base 10 [1], meaning it contains all finite sequences of digits. In which case your statement is obviously false.

An occurrence of some sequence of k digits in pi is only a sign of non-randomness if ithe index at which it occurs can be written in much less than k digits...

[1] https://en.wikipedia.org/wiki/Normal_number

Try 10111000, you'll realize that you can always win the code after a while. Essentially a De Bruijn sequence in combinatoric math, and if you analyze the source code, then you would realize exactly how to outsmart that algorithm.

But the point is actually to get 50-50, with neither side winning. Winning/losing would both point to your inputs having a pattern and the code to either always play the wrong moves or the right moves. It's one of the many possible ways to see a pattern in inputs, but it serves as a good demonstration why humans cannot be good at entropy.

This looks interesting: http://www.loper-os.org/bad-at-entropy/manmach.html

I have tried this website here for fun: https://numbergenerator.org/random-256-bit-binary-number

It produced the following:

0000000000001000101110010110010111110110100010101101110111000011110010111100001 0110101000100100011101001000100100100001001110101111000001001110000000000001010 0100110110000001011010101010000010011001001101111001000010101001011100100111000 0111011101001001101

I have played the game above using this input and it "won" the machine with a score of 56% approximately.

Ahh ok. In that case 12 zeroes in a row from a set of 16 possible characters would indeed by exponentially more unlikely. My (quick) calculations put it at approximately 1 in 76,569,678,407.

That's another problem you've touched on there. Pi, as far as we know, is random, uniform, and normal, although this hasn't been definitively proven. It could potentially be a good source of entropy, except that it is a widely known mathematical constant. And given that pi is infinite, random, and normal, then at some point in it you will find sequences of numbers which appear decidedly non-random. Since we are talking about 12 zeroes in a row, pi contains 12 zeroes in a row at position 1,755,524,129,973.

pi is the  mathematical constant with fixed digits, so any part of it can not be viewed as random because it can be calculated and besides  knowing it allow you with near 100% guarantee to point out the next digit/s.

AFAIK true random numbers may  be obtained only via digitization of fundamentally unpredictable and  stochastic  physical phenomena like quantum ones, atmospheric, etc..

How about 9428367110839506348425063820855586539232765? Looks random, right? Except that it's part of the first million decimals of pi.

The same with seed phrases: you can create one based on a Shakespear book. The seed will look random, but it's created deterministically. You can only tell it's not random once you find the source.

I stand corrected. I wasn't thinking about the binary representation, just in hex representation. I'll have a go at this combinatorics problem when I have some time but I suspect you're right that it isn't exactly extraordinary case even when considering that.

It isn't too useful actually. The suite is used to test for generation of a large set of entropy seeds, and it cannot be used to calculate the entropy of a specific keys, or a bunch of specific keys even. Usually used by people who are directly testing the source of entropy.

In addition, the suite is recommended to test for the randomness but not about non-predictability (which is also different). If you are developing your own source of CSPRNG (ie. another implementation of urandom), then you should use that. Otherwise, it is useless to evaluate for individual entropy because the sample size is far far smaller than required to test for that.

An interesting article by Random.org discusses this issue better than me: https://www.random.org/analysis/, stumbled upon it while finding sources of RNG previously. They conduct real-time analysis with the test as well, they yield interesting results.

The seed phrases are random as much as random  the sequences of bits from which they are generated. The ideal case is that when those the sequences are truly random and unpredictable.

To assess the randomness of generated bits one can use NIST Statistical Test Suite which includes 15 specific tests. The output of those tests  are  capable to tell if provided data are the result of pure chance.

The relevant guide on how to use NIST Statistical Test Suite is located here.

I would just point out that this isn't an accurate statement. 12 consecutive 0s has a 1 in 4,096 chance, which is definitely not "extraordinarily rare" to start with. But if you take a 24 word seed phrase with 256 bits, then there is actually around a 1 in 34 chance that you get 12 consecutive 0s somewhere in those 256 bits. And of course you can double that chance if you consider 12 consecutive 1s as well.

So for roughly every seventeen completely random 24 word seed phrases you generate, you'll have a string of 12 consecutive 0s or 1s. This is why it is difficult to assess randomness like OP is proposing. Strings which look random may not be at all, and strings which look predictable can indeed be entirely random.

The issue lies when you associated randomness with a uniform distribution. Contrary to popular belief, they are actually not synonymous. For Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), they are subjected to the next-bit test where you cannot predict the next few bits given the first few bits. That requirement is fulfilled by your OS's CSPRNG and thus it qualifies as being sufficiently random.

Now, back to the topic. Sure, you can reject a result where you have 12 consecutive '0's in your key, but that is extraordinarily rare and it would prob never be executed in any code that you write. Hence, there is no good reason for anyone to include test-cases which tests for this. Going by that, the definition of having entropy would then be having the results for which each character has the equal probability of being in each space (ie. non-biased). A counter-example is this:
Against these which are generated with a CSPRNG:

The former has low entropy, even though each character appears exactly once, which means that by normal standards, you would consider each character as having the equal probability to occur at least once. Yet, that is predictable. The second is generated with a CSPRNG, which is random yet there are repeated characters present. That is unpredictable. Given a large enough set, think infinity, each of the values would possibly be uniformly distributed. The mathematical model doesn't exist, there is no telling of how random something is because it is not designed to be predictable. Analysis with any results are often done with something that can be measured and thereby predictable.

There is no need to implement any algorithms to test for this. Your wallet client probably incorporates /dev/random which is a CSPRNG within your OS. random continually collected entropy from the environment and blocks if there isn't any sufficient entropy being collected. In addition, your wallet also seeds using entropy collected from other sources. Hence, trying to evaluate entropy is unnecessary and provides a false sense of security.

Thank you for the response.

It seems to be true that you can definitively say that a seed phrase is "bad"/not random (such as 12 repeating words, or sequential forwards or backwards).  If you can measure that some are "not random", there ought to be (I would think) some algorithm that captures such combinations and gives them a quantifiable score, which you can then expand towards "less random" combinations.  Perhaps you hit a limit at some point, but it seems to me that there should be a mathematical model to represent "badness".

No. If there is a method to accurately determine the randomness of strings or cryptographic keys, we wouldn't have so much issues with CSPRNGs. We would be able to just test the entropy using algorithm. The issue is that there is no way of testing if a key is truly random, variance could skew your results to have more x characters than another for example. Even if you introduce a huge sample size, there is no telling if a bias is inherent or it is just a coincidence with variance. There are instances where the lack of CSPRNG is evident; most evidently with Bitcoin signatures but they are attacked in unique ways and are not determined using a fixed algorithm.

If you are using a reputable wallet, one of the key things that is heavily scrutinized is the CSPRNG mechanism used during seed generation. That being said, you're probably in safe hands.

As to how bad humans are at generating entropy: http://www.loper-os.org/bad-at-entropy/manmach.html.

I was wondering if there are any measurement techniques (software tools) that can quantify the randomness of a seed phrase.  I've read numerous times that humans picking their own seed phrase is not advisable, because it would not have the level of randomness a (quality) computer-generated seed phrase would produce.  Therefore, their must be some test or method of measuring this.  I'm picturing something like a 0-100 scale, where the first word repeated 12 consecutive times would be 0 or extraordinarily close to 0, and the best entropy sources designed for seed phrase generation would be something close to 100, but there may be other ways to measure.

Is there anything like this?  I would think there would be, but I haven't come across is, nor have I heard anyone advertise to "test the randomness of your phrase", though I get the skepticism of entering the phrase into such a system introduces a risk (you'd only want to do it on a trusted, air-gapped device).

For nothing else, I'm curious as to "how bad" a human is at generating seed phrases randomly, versus computer.