 Show Posts
|
|
Pages: [1] 2 »
|
Yeah but 2^124 is pretty much impossible these days.
Only way to go thru all those hashes are with GPUs.
2.1267647932558653966460912964486e+37 hashes in total.
Most GPUs have a Teraflop of 5-10 these days, however with the extra steps it would be slower so say each GPU hashes at 1TH/s.
Even with 1,000,000 GPUs hashing at 1TH/s.
It would take
21,267,647,932,558,653,966.460912964486 seconds
Which is 674,392,691,925.37588681065807218688 years....
With that amount of hash power you are better off mining ZEC or ETH and you would at least get a gauranteed profit of $1,000,000 - $1,500,000 daily.
ok, I hope this is my last post here. So the easiest path to crack an Electrum private key is to just run through the 2^124 permutations, that is the shortest route.
That is precisely the point you are not getting. How do you think an attacker can "run through" these 2^124 permutations? Please try to focus on this question, and forget the rest. First, let us agree that these are not "permutations". In mathematics, a permutation is a bijective function between two sets. However, the attacker does not have a simple function that takes integers up to 2^124 and maps them to the set of seeds accepted by is_new_seed(). So let us not talk about "permutations", but about "valid seeds". So, how would an attacker "run throught" these 2^124 valid seeds? The only way he can do that is to test all seeds, and to filter out the ones that are not valid. That means the attacker has to enumerate a set of 2^132 seeds. I understand, but I am talking about the theoretical implications not the practical ones. The fact of the matter is that the minimum entropy is 124 bits, and probably lower due to collisions. According to the cryptographers that I have asked, 1 bit is lost at every layer, especially if the "glass is full" as that is when the collisions start to appear. So the RIPEMD is the weak link here, and possibly the ECDSA if spent. There is 1 bit lost assuming that the attacker has 50% probability of guessing a bit, and possibly more if he is more lucky. So let's assume 120 bit of security, and that is only if no new attack vectors appear, that make the cracking of these algos faster.
Now 120 bits is not quantum secure. And maybe if the RNG of the users is weak, probably less. It may still be unfeasible to crack it, but the danger is there. The private key becomes exposed to danger, and it will be a question of when, not if, the attacker finds it. By the way, the attacker doesn't have to target you specifically, there are already people going over all private key combinations as we speak. And this will only get worse, in the future. https://www.youtube.com/watch?v=foil0hzl4Pg |
|
|
|
|
Send it to a secure bitcoin address, as most addresses are not properly generated. We need to inspect every bit of source code we can in order to have full security.
After that, I might donate some to some privacy foundations, or free internet activism websites like EFF, and others.
|
|
|
|
Here is a visualization of Electrum's key/address system. Think of the hash functions as glasses, and think of the entropy as wine. If you pour 124 bits of wine into the system, you only get 124 bits of security, even though some glasses of wine have more capacity, if you only pour 124, you only get 124. The maximum security the glasses can handle is 160 bits, if you don't reveal the public key. So it's obvious that the hacker will try the 2^124 permutations, which is still unfeasible, however once quantum computers come out, every "drop of wine will count"  I hope now it's easier to understand.  Edit: sorry I confused 4 with 8, now it's fixed |
|
|
|
The problem is that you do not understand what entropy is. I think there is no point continuing this discussion.
Btw, raising the num_bits parameter to 132 would have no effect at all; math.ceil() already ensures that n is a multiple of 11 bits.
Let me explain it another way if I may, because it seems that you are the one who is confused here. SHA512 hash function =/= 512 bits of security by defaultIt only means a maximum of 512 bits of security, if the input entropy is 512 bits. So if you feed 1 bit of entropy into a 512bit hash function, it will only have 1 bit of security. There are 3 ways the attacker can proceed cracking it: 1) By brute forcing the hash function 2^512 permutations 2) By finding a shortcut/vulnerability in the hash function 3) By looking at the input function and brute forcing that. -Now for this example we will ignore point 2). -The attacker will also not try to brute force 2^512 permutations. -So what he will do is just run the input permutations.
WITH A DICESo if you have an entropy of a dice, and the attacker knows it's a dice, then you have 6 values with 2.58 bits of entropy If you hash a random number from 1-6, the hash won't have 512 bit of security, only 2.58 bit of security. The attacker will obviously not go through 2^512 bits, it will only go through 2^2.58 bits, which is 6 values.
WITH ELECTRUMIn electrum you have an is_new_seed function, that steals away 8 bits of entropy, so it doesn't matter if you wrap it around a SHA512 function, because the BTC protocol and the electrum source code is public just as with the dice above, that function will only have as much security as the entropy. Just as in the analogy above, the attacker knows that it's a dice, so here the attacker knows that it's a is_new_seed function. So according to my calculations, we have a 124bit entropy, therefore, at all layers, the maximum security is only 124bits, even if it's packaged into a RIPEMD-160 and the public key is not known. So the easiest path to crack an Electrum private key is to just run through the 2^124 permutations, that is the shortest route. While people who use minimum 160 bit input entropy can enjoy 2^160 permutations of security with an unspent BTC address.
Do you understand now my analogy? I don't try to be cocky or insulting, I just believe that this is a security issue in Electrum that needs to be resolved. |
|
|
|
I perfectly understand your argument.
Yes, the number of valid seeds is shrunk.
But that does not matter, because an attacker still needs to enumerate all seeds, in order to know if they are valid.
So, we are not reducing the size of the haystack.
It is as if you were claiming that the number of possible combinations is one because in the end there is only one seed that matches the private keys.
With that kind of reasoning, the entropy of anything is zero.
The problem is that you do not understand what entropy is. I think there is no point continuing this discussion.
Btw, raising the num_bits parameter to 132 would have no effect at all; math.ceil() already ensures that n is a multiple of 11 bits.
It's a hard mental excersize, and this does matter, maybe the missing bits are not as much, but it's still not good to misrepresent it. For me security is important, hence my name, so let me explain it in a simple way.
THREAT MODELINGThere are 5 layers in the Electrum Wallet: - 1. Attacking the Bitcoin Address
- 2. Attacking the Public Key
- 3. Attacking the bip32_private_derivation output
- 4. Attacking the bip32_root output
- 5. Attacking the is_new_seed output
- 6. Attacking the seed
6. If the attacker has the seed, then it's already over.5. The is_new_seed output has 512bit security, so even if it's made public, which it has no reason too, it's theoretically safe. 4. The bip32_root output has 512 bit security, so it's the same as above 3. bip32_private_derivation is just an encoding mechanism so, there is no entropy change here, and it's as vulnerable as the seed2. The public key has a maximum security of 128 bits if made public 1. The bitcoin address has a maximum security of 160 bits if made public/ or is already public Now as you have seen, the 6. and 4. points have 0 security, but they are not made public anyway, it's just handled internally, or on an offline machine if done so. So the only thing that goes public is the public key and the bitcoin address. In case of a bitcoin address, if it's unspent it remains 160 bit, if it's spent, then 128 bit.
So far so good. But my point was that the input entropy is too low, due to flawed generation. Think of it like a car engine, if you feed only 124 bits of entropy into it, the output will only be maximum 124bits (and possibly lower due to collisions). So it doesn't matter that we have 512bits shield at point 5) and point 4), those values are private anyway, because it's handled in the memory. What I am saying is that the is_new_seed function is lowering our entropy by 8 bits regardless of what we feed into the make_seed function. I don't know how else to explain it to you, just test out my code and see for yourself: https://bitcointalk.org/index.php?topic=1761663.msg17802165#msg17802165
Btw, raising the num_bits parameter to 132 would have no effect at all; math.ceil() already ensures that n is a multiple of 11 bits.
You still don't understand what I am saying to you. Please read my post carefully. |
|
|
|
Again, you are wrong.
Just imagine for a second that the prefix passed to is_new_seed() is no longer 8 bits long, but 132 bits long.
Imagine, for the sake of the argument, that I have a seed that passes this test; its hashes starts with the 132 bits prefix required by is_new_seed().
That seed, by the way, was generated by 12 words randomly chosen from a 2048 dictionary.
Your misunderstanding refers to the hash function, but I was not referring to that. The hash function's output is 512 bits in the seed checking phase, but that is meaningless, because that hash string remain confidential, and even if it's exposed it doesn't matter, because thr 512 bit function masks the input entropy. The entropy loss is due to the fixation of the 2 bits, and it has nothing to do with the hash function. The hash function could be a SHA1 for that matter. But if we restrict the first 2 bits to be a fixed value '01' , then that loses us 8 bits of entropy that I have proven experimentally above. And it is an issue, since a brute force attacker has 319014718988380000000000000000000000000 less permutations to go through. So it does matter how you encode the seed version, because by shrinking the haystack to find combatible strings that start with '01', we are losing entropy, as the haystack is smaller, and the attacker can find the needle faster. |
|
|
|
I suggest raising the num_bits=128 to 132 def make_seed(self, seed_type='standard', num_bits=132, custom_entropy=1):
So the bwp and num_bits line further increases it to 136, bpw = math.log(len(self.wordlist), 2)
num_bits = int(math.ceil(num_bits/bpw)) * bpw
And by losing 8 bits entropy, we will have 128 bits as de facto entropy if that is the goal. Because currently the defaultly generated seed has only 124 bits of entropy instead of 128. |
|
|
|
Again, you are wrong.
I am sorry to say this, but I have to say it bluntly, that it's you who is wrong. No disrespect, I like your work, and support it 100%, it's just that I think you misunderstood my argument. I can, and have proven this experimentally, there are 2 ways to prove it: 1) TEST HEX CHAR BITS
#!/usr/bin/env python
import hashlib
import binascii
import math
filter_bit=0
total_bit=0
def byte_to_binary(n):
return ''.join(str((n & (1 << i)) and 1) for i in reversed(range(8)))
def hex_to_binary(h):
return ''.join(byte_to_binary(ord(b)) for b in binascii.unhexlify(h))
#### total permutation = 2 ^ nestsize
for a in range(2): #1bit
for b in range(2): #2bit
for c in range(2): #3bit
for d in range(2): #4bit
for e in range(2): #5bit
for f in range(2): #6bit
for g in range(2): #7bit
for h in range(2): #8bit
tupstr = str(a)+str(b)+str(c)+str(d)+str(e)+str(f)+str(g)+str(h)
hashed = hashlib.sha512(tupstr).hexdigest()
hashed = hex_to_binary(hashed)
total_bit+=1
if hashed[0] == "0" and hashed[1] =="1":
filter_bit+=1
#####################################
print "Filtered: "+str(filter_bit)
print "Filtered Entropy: "+str(math.log(filter_bit,2))
print "Total: "+str(total_bit)
print "Total Entropy: "+str(math.log(total_bit,2))
It can be easily proven that 1 hex char = 4 bits, and the experiment result always in 2 hex bit loss if we fix the first 2 characters. Therefore that is 2*4 =8 bit entropy loss. (because 1 hex character is 4 bits long) This is exactly how Electrum fixed the first 2 hex bits which is equivalent to 8 bit entropy loss in Electrum. 2) SEED TEST - MONTE CARLO SIMULATION# ADD these to mnemonic.py
container = []
def test_make_seed(self, num_bits=128, prefix=version.SEED_PREFIX):
# increase num_bits in order to obtain a uniform distibution for the last word
# bpw = math.log(len(self.wordlist), 2) # 11.0
# n = int(math.ceil(num_bits/bpw)) * bpw # 132.0
# print_error("make_seed", prefix, "adding %d bits"%n)
n = 11
my_entropy = ecdsa.util.randrange(pow(2, n))
nonce = 0
while True:
nonce += 1
i = my_entropy + nonce
seed = self.mnemonic_encode(i)
assert i == self.mnemonic_decode(seed)
if is_new_seed(seed, prefix):
break
print_error('%d words'%len(seed.split()))
return seed
def searchf(self):
seed=self.test_make_seed()
container.append(seed)
for nonce in range(0,500):
seed=self.test_make_seed()
n = len(container)
test="T"
for pp in range(0,n):
if container[pp]==seed:
test="F"
break
if test == "T":
container.append(seed)
Mnemonic().searchf()
print container
We fix the bits to 11 bits (so the seed is 1 word wrong for simplicity) And the container loops through all seed variations for 11 bits total, and hopefully in 500 iterations it goes through all of them like a monte carlo simulation (it does). And we will only get 8 seeds, which means that 2^11 input only yields 2^3 output, because 11-3 = 8. We are missing 8 bits of entropy
So either way we are losing 8 bits of entropy, that DOES matter, because the possible combinations are shrunk. In the 2nd testing method, we ought to get 2^11 combinations but we only get 2^3. That is obvious security loss, and the 8 bits of entropy loss is real. |
|
|
|
...
Is that a correct assesment?
No that is not correct. First, we are not talking about 2 but 8 bits. I do not know why you made that statement about 2 bits. I think you misunderstood me, please re-read my post. Let me explain it better I have tested that in hex mode, every input loss = output loss ( +/- some variance at certain bits, but it converges to this). Which means that for N fixed output characters, you have N fixed input characters. The code fixes 2 hex characters "01", and we know that 1 hex character is 4 bits. So that is 2*4 = 8 bits of entropy lost. Second, we are not fixing the bits passed to bip32_root. The seed passed to bip32_root is not hashed with "Seed version", but with a different string. That assumption seems to be present in the last part of your reasoning.
Of course ,I havent said that it's like this, that was just a side tangent. I actually said that the bit32_root has nothing to do with this. Third, and this is the most important point, there is no 'loss' of entropy.
Yes there is, because if you fix the output, you fix the input. If SHA-512 is bijective, which it isnt entirely, but that is another issue. So if we suppose it is. Then if we have 2^512 combinations a hacker has to solve to get the key. If we fix 8 bits of entropy, that means only 504 bits of entropy for the SHA512, and only 124 bits of entropy for the input, since the input must conform to that criteria. Because only 2^124 number of seeds translate to 2^504 bits of entropy of the SHA512, and the remaining 8 bits have 0 entropy.
Now here is the conclusion: So you are saying that computationally this doesn't make a difference, but I disagree. Because entropy is just information, and it get's carried forward. Because you have a -8 bit deficiency, and only 124 bits get passed on to the bip32_root to generate the xpriv and the child priv keys from there on. It's not that the 2 SHA outputs collide, don't misinterpret my word, that is not what it is. It's that the is_new_seed function is limiting the possible inputs by 2^8 combinations, which result in a 8 bit entropy loss by definition.
So a default wallet creation goes like this: 1) 132 bits of initial entropy pool 2) limited to 124 bits to create seed words at is_new_seed 3) 124 bits to master private key at bip32_root 4) then 124 into bip32_private_derivation or whatever that creates child priv keys 5) then 124 bit into ECDSA 6) then 124 bit into RIPEMD-160 7) Then Base58 encoding and you have a 124 bit address. Furthermore, every hashing leaks about 0.5 bits of entropy if the input is smaller than the capacity of the hash, because the hashing functions are not bijective. Who knows maybe RIPEMD could leak up to 1 bits because the input almost depletes it's capacity. Not to mention that the BTC address also has an encoding scheme (they start with 1 or 3), so add that to it as well. So you could easily end up with a 120 bit Bitcoin adress (in both spent and unspent state) despite the original entropy pool being 132 bits.Whereas if we compensate for the lost 8 bits (in electrum), we could create a seed that is 168 bits, so that an unspent BTC address could be a maximum 156 bits strong. And a spent BTC address 124 bits.Unfortunately the RIPEMD-160 is a very weak algorithm, that is where most of the entropy is lost. It should be replaced with something bigger of 256bit. |
|
|
|
The seed has 132 bits and the length of the prefix is 8 bits. Therefore, 8 bits are "lost" by imposing the 0x01 prefix.
However, there is no way to enumerate seeds that hash with the desired prefix, other than brute force. Therefore, from a security point of view, these bits are not "lost"; an attacker still needs to use brute force in order to find valid seeds, just like they need to use brute force in order to attack the remaining bits.
There is still a weakening of the seed that results from the imposed prefix, because no key stretching is required in order to generate the prefix.
But it is wrong to express it in terms of "bits lost"; all you can say is that these 8 bits are easier to enumerate than the remaining 124 bits.
I am just an amateur, but I have analyzed the code. There are 2 use cases of the SHA512, where the the HMAC is encoding it with: - "Seed version" in is_new_seed in the Mnemonic.py
- And with "Bitcoin seed" in the Bitcoin.py in bip32_root function to generate the xpriv key
Now I assume that signing with different messages doesnt leak information, after all this is the point of the hash function. So we are left with the Mnemonic.py is_new_seed function, where 2 bits of the prefix is fixed: (via version.py)Now I have experimentally tested, the relationship with the input and output of the SHA512 function, and asked some cryptographers about it as well. And it looks to me that by fixing 2 output bits, you lose 2 input bits (on average, it converges towards 2 bits +/- some variance at certain inputs). Or in general terms the input loss = the output loss, on average And since the test is happening in hex s = hmac_sha_512("Seed version", x.encode('utf8')).encode('hex')
return s.startswith(str(prefix))
1 hex char is 4 bits, therefore you have 2 bits * 4 bits = 8 bits. - So if the seed is <520 bits long, then its easier to crack the seed, than the SHA512
- If the seed is 520 bits, then it's the same as SHA512
- If the seed is >520 bits, then it's easier to crack SHA512
Is that a correct assesment? |
|
|
|
I partially disagree, because I don't think they are the same language.
Yes. They are. They are both just numbers. Wow, amazing. A very interesting view on information. So you are saying basically that every number or text that physically exists in the world as an object has minimum as much entropy as the computational representation of it? So if we have the number 2384923482983, and this number in Chinese characters painted on a wall. Then if we take a picture of that wall, then that picture will have minimum as much entropy as the number itself? Or if I say out the number 2384923482983 in German and record it in an MP3 file, then that MP3 file will also have minimum as much entropy as the number itself? A very interesting theory, do you know any scientific papers on it, I would like to read more? |
|
|
|
The lesson:
Private keys are called private keys for a reason, and hackers are willing to go through a lot of work to get them.
I may not be an expert on cryptography but I am an expert in computer security. Alright but is there a way to actually quantify the amount of entropy an image has, to just make sure it's safe?
Because at least a dice roll can be quantified, because even a slightly deformed dice has 90% entropy, thats 2.3264662506 bits.
So any casino quality dice should be much better than that.
Well, if you take a picture of the 62 dice (and the photo has enough detail and clarity to make out the values of all the dice) then the photo would have to have more entropy than the the dice rolls themselves. Each die value contributes its entropy to the photo, but additionally the exact orientations and exact positions of the dice relative to each other within the photo are random as well which increases the entropy. Furthermore, the background behind whatever you roll the dice on is likely to have some variations to its color and brightness which contributes additional entropy. I partially disagree, because I don't think they are the same language. The values of the dice, is just raw information, which can be let's say "61235" after roll with 5 dices, which in it's basic binary form is: 110110 110001 110010 110011 110101I highly doubt this sequence of information must inside the binary form of the picture of the dice, because it's not the same language. It may be inside it, but that is only due to coincidence, but it doesnt necessarly have to be. We just interpreted the output of the dice as being 6 but the computer only sees the pixel values of the dice, but not the "6" itself. So humans and computers think in different language, and that is why the picture itself is only as good randomness, as random the pixels are inside it, but have probably nothing to do with the informational content that it carries for humans. Now maybe the picture has a higher entropy value than the roll information itself, but that is another issue. |
|
|
|
Electrum uses a verification system for seeds, I am interested in the standard wallet only now. It has: def is_new_seed(x, prefix=version.SEED_PREFIX):
import mnemonic
x = mnemonic.normalize_text(x)
s = hmac_sha_512("Seed version", x.encode('utf8')).encode('hex')
return s.startswith(prefix)
Which basically after generating a random number of N entropy, check the seed for the new version seed, which is a SHA512 encoded seed with the phrase "Seed version", and which must start with "01" For example: 015a2cb3e1eb920445455c380f4fdd026f17bd18e3ab06ecd7fda65e5340cebf955c228eaa88ff997a70a6172cd3960c3e237b462e6d2a61f259b5955a5cf510 It generates the following seed: shaft dizzy alarm core deposit mandate off mixed cover size refuse protect
Now this procedure probably means an entropy loss, since we are shrinking down the haystack in order to find an output that starts with 01, which means that the first character of that string is fixed not random. How much entropy does the seed lose by performing this versioning system on it? |
|
|
|
Indeed, but then I guess the string must be "Seed version" in our electrum, otherwise the whole verification system won't work.
So if I were to change that string, then the whole verification system would be pointless.
Yep, you also would have to use that same "Seed version" string for the verification as that is what they choose to use. I'm guessing they used that string as the key since the point of that is_new_seed function is to determine which version of the seed is being used. Yep, thanks, i will just use it that way. |
|
|
|
For the hash_encode, it looks like it is simply taking x reversing it and encoding it in hex. [::-1] is the notation to reverse a string.
For the hash_decode, it looks like it is taking a hex input and decoding/reversing it back to the original.
I don't actually see the hash_encode/hash_decode variables being anywhere in the code snippets provided.
Yes thank you, that is actually being used elsewhere. It was just weird being coupled with the rest of the code.
The "Seed version" string is the key for the hmac.new function which could really be any phrase, they just chose to use that one. An HMAC is a cryptographic hash that uses a key to sign a message. A receiver could verifiy the hash by recomputing it using the same key.
So it looks like it is hashing the seed mnemonic encoded into hex and checking which prefix it starts with to determine if it is a new or old version of the seed format.
Indeed, but then I guess the string must be "Seed version" in our electrum, otherwise the whole verification system won't work. So if I were to change that string, then the whole verification system would be pointless. |
|
|
|
Say you have two ways to get a random seed, one way gives this, with "x" representing an independently chosen perfectly random bit, and zero representing a certain zero:
(1)
000xx00x00000xx00xx0000000000000x000x0x0x0x00x0000000xx0000000000x000x
xx0x0xxx00000000x00000x0x00000x0000000x0x0xx000000x00xx0xx0xxx00000000
00x0xx0000000x0xx000000xx00xx0x00000000x0000x00000x0x0x000x0x0x00xx000
0000x0000000x000000x00x000x0xx00x000x0xx0000x0000x000000x00x00xx000000
0000000x0x0000000x0x0000000000x00x0x00000xx00000x00xx0000000000x000000
00000000x00000xx00x00000x000x0000x00xx000000000x000000x00xx0000000x0xx
xx0xx00x000x0000x0x0000000x0x00000000x0x00x00xx00xx0000x00000000000000
0000000x0xxx0000000000
(2)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The first way provides very low-quality randomness (about 7/8 of the bits are zero), but provides much more security than the second way, because the second way has 64 random bits, and the first has 128 (count the number of "x").
The camera image is like the first, it has low quality randomness, but far more total randomness than the dice numbers.
The hash converts large volumes of low-quality randomness into a smaller amount (256 bits) of high quality randomness for your keys.
Alright but is there a way to actually quantify the amount of entropy an image has, to just make sure it's safe? Because at least a dice roll can be quantified, because even a slightly deformed dice has 90% entropy, thats 2.3264662506 bits. So any casino quality dice should be much better than that. Don't use those particular images because you just published them
Of course not. |
|
|
|
I am trying to understand Electrum and working on a project that will use Electrum, but I have a problem understandint it's key generation. I have figured out that the SHA-512 hash of the normalized mnemonic starts with 1 as an encoding for normal wallets. I will only work with normal wallets though. So the version.py has a constant: SEED_PREFIX = '01' # Electrum standard wallet That is called almost every time to check the version of the seed. So far so good. But then you have in bitcoin.py a code snippet like this: hash_encode = lambda x: x[::-1].encode('hex')
hash_decode = lambda x: x.decode('hex')[::-1]
hmac_sha_512 = lambda x,y: hmac.new(x, y, hashlib.sha512).digest()
def is_new_seed(x, prefix=version.SEED_PREFIX):
import mnemonic
x = mnemonic.normalize_text(x)
s = hmac_sha_512("Seed version", x.encode('utf8')).encode('hex')
return s.startswith(prefix)
I am trying to figure out what this does, step by step. 1) For example the "hash_decode and hash_encode" structure which is never used again. Is that what "x.encode" calls? What is the function of these 2 lines?: hash_encode = lambda x: x[::-1].encode('hex')
hash_decode = lambda x: x.decode('hex')[::-1]2) I also don't understand what the "Seed version" phrase does exactly, does it append that to the encoded mnemonic? 3) Then it also checks for the start character of "s", but then what is the point of adding the "Seed version" into the hash itself? It's a pretty complicated structure, somebody could please explain. |
|
|
|
I am sorry but that just makes no sense, the information entropy of a number is raw entropy with 0% noise/signal ratio.
I am sorry but that just makes no sense. When you consider a picture, which has bits of repeating colors all over the place, that is just not raw entropy anymore, because the bits of the colors are repeating. I highly doubt that is high quality randomness.
...
But just the dice itself, which is not even in the same language, I doubt it. It's the bits that are the language, and repeating bits are not a good quality.
The photo as is is not high quality randomness, but it has much more total entropy than the dice roll values. Think about it, if you roll ten dice and record the values, they have 60466176 possibilities, how many possible images of the dice do you think there are? Definitely many more, and entropy is just a measure of the amount of possibilities (adjusted by probability, so that equal probabilities have more entropy than different probabilities). Also, high quality randomness is not very important for the seed value, a ten bit seed is inadequate no matter how high-quality they are are, but 65536 bits are enough even if each bit is biased 10% to 90%. Alright I have to concede, cryptography is not my field, I'm an IT guy. However I imagined that the seed is good if it's truly random. For example an image is a highly repetitive cluster of bits. When you have a blue dice on a white background, that is pretty easy to reconstruct and find similarities. Random in the entropy sense means something that doesn't repeat, otherwise what is the point on generating a key from that. If you have a picture of something where the bits are highly repetitive, doesn't that automatically mean low quality randomness? It would be the equivalent of flipping coins where 1 side has an enormously bias. If you think of a picture as a bitmap, if the background is white,then that is already a huge bias. Then you have some blue, and the signs on the dice are also white. I doubt that is a high source of entropy. So maybe a photography could be a source of entropy, but it should be a more diverse photo, like taking random photos of a town, and mixing it together as a composite, so that the colors and the patterns are more uniformly distributed. I have also read that using a microphone to gather background nosie from an empty room is also a decent source. It all depends on the quality too, I believe. |
|
|
|
Since the photo is of the dice, and the dice are random, then the values and arrangement of the dice in the photo would be random. Therefore, the entropy in the photo should be significantly higher than the entropy of the dice values themselves (since values of the photo would also take into consideration the location and orientation of the dice as well as the background).
Of course that assumes that the photo has enough detail and clarity to make out the values of all the dice.
I am sorry but that just makes no sense, the information entropy of a number is raw entropy with 0% noise/signal ratio. When you consider a picture, which has bits of repeating colors all over the place, that is just not raw entropy anymore, because the bits of the colors are repeating. I highly doubt that is high quality randomness.  Maybe if it's just a black/white binary image of random 0 and 1, but then that image is already 100% descriptive of the information contained in itself. But just the dice itself, which is not even in the same language, I doubt it. It's the bits that are the language, and repeating bits are not a good quality. |
|
|
|
|
