Something Odd? Thinking caps on guys.

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: HCP on December 03, 2019, 06:27:05 PM

The term "collision" is being used very loosely here...

as i said, it is a "partial collision" not a "collision". a partial collision is when only a smaller portion of the digests are equal. it is a topic that becomes important if you are using truncated hashes, like using SHA256 to hash but only using first 32 bits. and it seems to me that this is what OP is doing.

HCP

legendary

Activity: 2086

Merit: 4361

The term "collision" is being used very loosely here... you don't have any collisions at all... you have what are effectively hashes of some very large numbers that have a few of the most significant bytes that are the same... surprising? Not really... assuming the hash function has results that are evenly spread amongst the total hash space, you'd expect some results to be "somewhat near each other".

Its like saying... I was generating hashes from random numbers and got this "collision":

12583497236598327780860956843764674908093582309
and
12583403334565765756676575672389472394242152634

They're obviously not a "collision"... Roll Eyes

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

i honestly don't see anything strange going on here. you take an input, pass it though a pseudo random function and get a final result. then change that input, pass it through the same function and get a different result. then you repeat this final step a lot of times in a loop until you find a partial collision.
that is not strange, that is expected.
if you do this with any cryptography function you will find the same results; here is an example with MD5 (since it is a fast hash function!):

Code:

1st data: 9D27E7F051FE2A5054108C5277D33E95F93713FACE1287EF58C876FAC9F71DDC
2nd data: 27125476F051C952E7581DC82A3E958CF7FAFAEF13CEFE7750D31037879DF9DC

1st hash: DC33E57B0A1102F9E34220FF5CE0189B
2st hash: DCA941D7FF18B6C1CFEF5230C7738F40

here the 256 bit data is like the mnemonic you have and MD5 is like the same scrypt and hmac-sha that you have. i get the first data, shuffle the bytes around and hash it again.
the result hashes are also the same as the "addresses" or entropies you find.
you can see that the jumble of the "data" gives similar hashes. it took me a nanosecond to find this collision.

here is a bigger one that tool half a second:

Code:

1st data: 4143C76B1A8866283ED66BF5FFA8645B65732162E684E573363B2A15868E508B
2nd data: 662865E6FF36E53E3B8EC74321A8506B41626B5B64F5D62A73867384151A888B

1st hash: 4556FE9D3DD928AD6A7710054D51D595
2st hash: 4556FE2AEB7D1E3DFD479B20C405FFBC

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Sorry for the late reply to this,
It seems around 1 in 3 that comes out has this strange matching pattern.

I will post some more in the coming weeks about this.

tromp

legendary

Activity: 990

Merit: 1108

Quote from: DaCryptoRaccoon on September 21, 2019, 10:33:25 AM

They are coming out in sequential order.

Its not like i have a list and they are being found by searching they are being spat out in this sequential ordering.

Then it's exceedingly odd. I would expect such close hashes to require some form of sorting or search.
How are successive permutations generated?

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Quote from: tromp on September 19, 2019, 12:55:24 PM

Quote from: DaCryptoRaccoon on September 19, 2019, 06:27:58 AM

How can the 2 hashes at the start both have 0142aa16 then 0142aa17

That's not odd?

For any list of 12 words, there are 12! = 479001600 > 16^7 possible permutations,
so you expect some pair to match in the first 7 hex digits.

They are coming out in sequential order.

Its not like i have a list and they are being found by searching they are being spat out in this sequential ordering.

If I sit and tail -f the output I can see some that have no relation then there is suddenly pairs that come out one after the other.

I could understand if I had a list and I did every possible combination then yes I could search and probably find some matches but they seems to come out in this order which is strange considering the process being used should in theory not have all these results come out in a ordered way like this?

tromp

legendary

Activity: 990

Merit: 1108

Quote from: DaCryptoRaccoon on September 19, 2019, 06:27:58 AM

How can the 2 hashes at the start both have 0142aa16 then 0142aa17

That's not odd?

For any list of 12 words, there are 12! = 479001600 > 16^7 possible permutations,
so you expect some pair to match in the first 7 hex digits.

NeuroticFish

legendary

Activity: 3668

Merit: 6382

Looking for campaign manager? Contact icopress!

Hmmm... I've been looking into the code a little and one thing that bothers me is that in mm_decode there are groups of 3 and in each group the distances between the indexes seem to matter more than the actual indexes, which could be a problem. But I don't know more, I understand python just as much as it resembles with C/C++ and I didn't look too deep.

Maybe you could ask directly them? https://github.com/spesmilo/electrum/issues
I expect that they have more expertise in this and could answer.

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Quote from: NeuroticFish on September 19, 2019, 06:22:22 AM

Imho there's nothing odd.
Keep in mind that those words are a seed. A seed like the Random needs.
Then one or more operations are done. The results can be really in any range, which cannot (and imho should not!) be related to the words and their order.

So if you take a string of words then jumble them up but still are left with the same leading characters that's not odd?

Words Used :
['ensure', 'alter', 'segment', 'spawn', 'cupboard', 'idle', 'horn', 'enrich', 'vendor', 'smooth', 'fruit', 'stone']
0142aa16fea967b90142aa1700f20785 = 1BC5kyKk4Cp8BQQnCGUrGyALKVRAFv8ZbC

Words Used:
['horn', 'enrich', 'vendor', 'segment', 'smooth', 'idle', 'alter', 'fruit', 'stone', 'cupboard', 'ensure', 'spawn']
0142aa17ff4a937e00c9d5f71003c8196 = 13XYF15nGbyTZCSAF1dzaGhmES4kdcqE3U

How can the 2 hashes at the start both have 0142aa16 then 0142aa17

That's not odd?

the words are in completely separate order meaning there should be no relation at all to the last hash but there is..
Unless there is something in the way the words are being used to cause this effect.

NeuroticFish

legendary

Activity: 3668

Merit: 6382

Looking for campaign manager? Contact icopress!

Imho there's nothing odd.
Keep in mind that those words are a seed. A seed like the Random needs.
Then one or more operations are done. The results can be really in any range, which cannot (and imho should not!) be related to the words and their order.

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

After some more testing the results are the same 10000's of hashes all starting the same way which is strange as said above a single position change of just 1 word would alter the hash dramatically yet there are consistently coming out with the same leading result even with the words being changed to positions completely different from the last.

I think there may have been a weakness in the "old" electrum style wallets or the process used to create them has some issue with it.

Can anyone think of a logical reason why hex combinations would seem to appear at the start of the hashes on more than one occasion, At first I thought it was a fluke hash but then more and more of them started to show up I ended up with a sequence of co lours that relate to colors used in the word list of electrum.

Code:

black
white
red
blue
green
grey
pink
orange
purple
crimson
peach
cream

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Quote from: buwaytress on September 12, 2019, 05:47:56 AM

Interesting but I can't tell myself if there's a logical explanation other than the (Wrong) logic that those set of words for sure spit out those parts of the hash.

It's not a one off with the same set of words in different positions, but do you also get the same findings with other sets of words? Or if you progressively replace 1 word in the same set with new words from dictionary?

Which v electrum?

I was running this specific set of words from the word list.
I believe most of this code is from either v1 or 2 of electrum it's like creating the "old style" wallet format.

From what I am seeing come back are far to close to say there is not something there. be it the way the words are being calculated into integer or otherwise.

If I take the entire word list and use them the results do not come back like such only when exactly 12 words are selected you get this same start to them.

It also works if you take any 12 words and do this function which to me seems very odd.

j2002ba2

full member

Activity: 206

Merit: 447

Quote from: DaCryptoRaccoon on September 11, 2019, 11:16:52 AM

['fruit', 'stone', 'enrich', 'cupboard', 'vendor', 'idle', 'alter', 'ensure', 'horn', 'segment', 'spawn', 'smooth']
0: 1HX5wVovCUMmJCFuZ5PQ3JRFSvr1jeud6h: fed1b2acfef9e43800286ab300c9967a: ee4875dd10630520647378f69b0974be59b076d9443ff5b999645411bb156a6cc3934d67cfb9ab3 c7d97f5b933930d3f837b21000c91bf726fdc0d580ac6ef3d

['smooth', 'vendor', 'idle', 'enrich', 'segment', 'horn', 'alter', 'spawn', 'ensure', 'stone', 'fruit', 'cupboard']
0: 13WJoAWkqftY9DPxBEDDkk3xCTdK6PM1Yg: fed19f9fffc3c6da0028645900c9967d: d2e3b54a56868fa4d201c72aedb6e9d99a55cad5a1215d0d87e0399cc70663e8194cdba5dbedd99 250b5110941d5e326ae32bb0a14c84a1847fc5a51cc8d174f

Both mnemonics have invalid checksum. For 12 words the chance to get a valid checksum is 1/16. So if you don't check it, in 15 of 16 cases you'd get garbage.

buwaytress

legendary

Activity: 2968

Merit: 3684

Join the world-leading crypto sportsbook NOW!

Interesting but I can't tell myself if there's a logical explanation other than the (Wrong) logic that those set of words for sure spit out those parts of the hash.

It's not a one off with the same set of words in different positions, but do you also get the same findings with other sets of words? Or if you progressively replace 1 word in the same set with new words from dictionary?

Which v electrum?

TalkStar

copper member

Activity: 1204

Merit: 737

✅ Need Campaign Manager? TG > @TalkStar675

Quote from: DaCryptoRaccoon on September 11, 2019, 02:58:46 PM

I am wondering if there may be some kind of flaw with the old electrum wallets that people missed I cannot understand how 2 words sets with the same words but in very different positions can produce a hash with the same leading characters unless there is a problem along the road somewhere.

Basically we haven't observe much incidents which actually relates with this but i think that those seed would not be detected with so ease but seed generating process is obviously backdated.

Quote from: DaCryptoRaccoon on September 11, 2019, 02:58:46 PM

I may be wrong but when you have 20k of these all very very very close it tells you something is wrong very wrong.

Yeah its kinda unexpected to see common words on different combination which actually increase the chances of being too much similar on some pairs.

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Quote from: TalkStar on September 11, 2019, 12:46:07 PM

You have got something interesting but in my opinion its not so easy to detect those combination by using single partial match only. If you look deeply on those set of words then you can see there that in every single combination multiple words organised in different position. Its not like that same words are using on similar place or in a common combination each time. Every single time those words are making their pairs by changing previous combination. For those pairs of words easily more thousands of combination could be generated which is kinda tough to detect AFAIK.

Yes if you look at the words they are not in the same positions so why or how could the produce a hash with the same leading start as the previous one?

thats my point.

unless there something in the code I am not seeing that's causing it but from what I can see its all electrum code from a old wallet.
I am wondering if there may be some kind of flaw with the old electrum wallets that people missed I cannot understand how 2 words sets with the same words but in very different positions can produce a hash with the same leading characters unless there is a problem along the road somewhere.

I may be wrong but when you have 20k of these all very very very close it tells you something is wrong very wrong.

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Quote from: ?? on ??

I can understand why you'd say it's strange, but normally hash would be totally different even if only 1 bit of the input is changed.

I wonder if you could try it again, but using cryptographic random function instead.

here is the entire script that produces them.

Do you not find it strange that the words are all jumbled up but still you are getting hashes that show the same leading characters are matching.

even though the words are not in the same place or even next to each other.

as far as I am aware this is the old electrum code for "old style" wallets.

Code:

def mn_encode( message ):
out = []
for i in range(len(message)/8):
word = message[8*i:8*i+8]
x = int(word, 16)
w1 = (x%n)
w2 = ((x/n) + w1)%n
w3 = ((x/n/n) + w2)%n
out += [ words[w1], words[w2], words[w3] ]
return out

def mn_decode( wlist ):
out = ''
for i in range(len(wlist)/3):
word1, word2, word3 = wlist[3*i:3*i+3]
w1 = words.index(word1)
w2 = (words.index(word2))%n
w3 = (words.index(word3))%n
x = w1 +n*((w2-w1)%n) +n*n*((w3-w2)%n)
out += '%08x'%x
return out

def stretch_key(seed):
oldseed = seed
for i in range(100000):
seed = hashlib.sha256(seed + oldseed).digest()
return string_to_number( seed )

def mpk_from_seed(seed):
curve = SECP256k1
secexp = stretch_key(seed)
master_private_key = ecdsa.SigningKey.from_secret_exponent( secexp, curve = SECP256k1 )
master_public_key = master_private_key.get_verifying_key().to_string().encode('hex')
return master_public_key

class Account(object):
def __init__(self, v):
self.addresses = v.get('0', [])
self.change = v.get('1', [])

def dump(self):
return {'0':self.addresses, '1':self.change}

def get_addresses(self, for_change):
return self.change[:] if for_change else self.addresses[:]

def create_new_address(self, for_change):
addresses = self.change if for_change else self.addresses
n = len(addresses)
address = self.get_address( for_change, n)
addresses.append(address)
return address

def get_address(self, for_change, n):
pass

def get_pubkeys(self, sequence):
return [ self.get_pubkey( *sequence )]
class OldAccount(Account):
""" Privatekey(type,n) = Master_private_key + H(n|S|type) """

def __init__(self, v):
self.addresses = v.get(0, [])
self.change = v.get(1, [])
self.mpk = v['mpk'].decode('hex')

def dump(self):
return {0:self.addresses, 1:self.change}

@classmethod
def mpk_from_seed(klass, seed):
curve = SECP256k1
secexp = klass.stretch_key(seed)
master_private_key = ecdsa.SigningKey.from_secret_exponent( secexp, curve = SECP256k1 )
master_public_key = master_private_key.get_verifying_key().to_string().encode('hex')
return master_public_key

@classmethod
def stretch_key(self,seed):
oldseed = seed
for i in range(100000):
seed = hashlib.sha256(seed + oldseed).digest()
return string_to_number( seed )

def get_sequence(self, for_change, n):
return string_to_number( Hash( "%d:%d:"%(n,for_change) + self.mpk ) )

def get_address(self, for_change, n):
pubkey = self.get_pubkey(for_change, n)
address = public_key_to_bc_address( pubkey.decode('hex') )
return address

def get_pubkey(self, for_change, n):
curve = SECP256k1
mpk = self.mpk
z = self.get_sequence(for_change, n)
master_public_key = ecdsa.VerifyingKey.from_string( mpk, curve = SECP256k1 )
pubkey_point = master_public_key.pubkey.point + z*curve.generator
public_key2 = ecdsa.VerifyingKey.from_public_point( pubkey_point, curve = SECP256k1 )
return '04' + public_key2.to_string().encode('hex')

def get_private_key_from_stretched_exponent(self, for_change, n, secexp):
order = generator_secp256k1.order()
secexp = ( secexp + self.get_sequence(for_change, n) ) % order
pk = number_to_string( secexp, generator_secp256k1.order() )
compressed = False
return SecretToASecret( pk, compressed )

def get_private_key(self, seed, sequence):
for_change, n = sequence
secexp = self.stretch_key(seed)
return self.get_private_key_from_stretched_exponent(for_change, n, secexp)

def check_seed(self, seed):
curve = SECP256k1
secexp = self.stretch_key(seed)
master_private_key = ecdsa.SigningKey.from_secret_exponent( secexp, curve = SECP256k1 )
master_public_key = master_private_key.get_verifying_key().to_string().encode('hex')
if master_public_key != self.mpk:
print_error('invalid password (mpk)')
raise BaseException('Invalid password')
return True

def redeem_script(self, sequence):
return None

def b58encode(v):
""" encode v, which is a string of bytes, to base58."""

long_value = 0L
for (i, c) in enumerate(v[::-1]):
long_value += (256**i) * ord(c)

result = ''
while long_value >= __b58base:
div, mod = divmod(long_value, __b58base)
result = __b58chars[mod] + result
long_value = div
result = __b58chars[long_value] + result

# Bitcoin does a little leading-zero-compression:
# leading 0-bytes in the input become leading-1s
nPad = 0
for c in v:
if c == '\0': nPad += 1
else: break

return (__b58chars[0]*nPad) + result

def b58decode(v, length):
""" decode v into a string of len bytes."""
long_value = 0L
for (i, c) in enumerate(v[::-1]):
long_value += __b58chars.find(c) * (__b58base**i)

result = ''
while long_value >= 256:
div, mod = divmod(long_value, 256)
result = chr(mod) + result
long_value = div
result = chr(long_value) + result

nPad = 0
for c in v:
if c == __b58chars[0]: nPad += 1
else: break

result = chr(0)*nPad + result
if length is not None and len(result) != length:
return None

return result

__b58chars = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
__b58base = len(__b58chars)

def EncodeBase58Check(vchIn):
hash = Hash(vchIn)
return b58encode(vchIn + hash[0:4])

def DecodeBase58Check(psz):
vchRet = b58decode(psz, None)
key = vchRet[0:-4]
csum = vchRet[-4:]
hash = Hash(key)
cs32 = hash[0:4]
if cs32 != csum:
return None
else:
return key
def public_key_to_bc_address(public_key):
h160 = hash_160(public_key)
return hash_160_to_bc_address(h160)
def hash_160(public_key):
try:
md = hashlib.new('ripemd160')
md.update(hashlib.sha256(public_key).digest())
return md.digest()
except:
import ripemd
md = ripemd.new(hashlib.sha256(public_key).digest())
return md.digest()
def hash_160_to_bc_address(h160, addrtype = 0):
vh160 = chr(addrtype) + h160
h = Hash(vh160)
addr = vh160 + h[0:4]
return b58encode(addr)
mnemonic_hash = lambda x: hmac_sha_512("Bitcoin mnemonic", x).encode('hex')
hmac_sha_512 = lambda x,y: hmac.new(x, y, hashlib.sha512).digest()
Hash = lambda x: hashlib.sha256(hashlib.sha256(x).digest()).digest()

def hack(t, d):
while True:
seed = mn_decode(guess)
mpk = OldAccount.mpk_from_seed(seed)
acc = OldAccount({'mpk':mpk, 0:[], 1:[]})
#pk = number_to_string( secexp, generator_secp256k1.order() )
#compressed = False
# SecretToASecret( pk, compressed )
addy = acc.create_new_address(False)
with open("addresses.txt", "a+") as myfile:
myfile.write(mpk + ": " + addy + "\t" + seed + "\n")

for example lets look at number 7

['fruit', 'stone', 'enrich', 'cupboard', 'vendor', 'idle', 'alter', 'ensure', 'horn', 'segment', 'spawn', 'smooth']
0: 1HX5wVovCUMmJCFuZ5PQ3JRFSvr1jeud6h: fed1b2acfef9e43800286ab300c9967a: ee4875dd10630520647378f69b0974be59b076d9443ff5b999645411bb156a6cc3934d67cfb9ab3 c7d97f5b933930d3f837b21000c91bf726fdc0d580ac6ef3d

['smooth', 'vendor', 'idle', 'enrich', 'segment', 'horn', 'alter', 'spawn', 'ensure', 'stone', 'fruit', 'cupboard']
0: 13WJoAWkqftY9DPxBEDDkk3xCTdK6PM1Yg: fed19f9fffc3c6da0028645900c9967d: d2e3b54a56868fa4d201c72aedb6e9d99a55cad5a1215d0d87e0399cc70663e8194cdba5dbedd99 250b5110941d5e326ae32bb0a14c84a1847fc5a51cc8d174f

why would it return the 2 values that are so close at the start this is not a one off by the way.
if i let this run for hours 95% of them have a relation like this even with the words being used at very different parts of the seed.

I think there is something more here that I am missing but those hashes should not be so close considering the functions used to create them?

Thanks guys.

Magic

TalkStar

copper member

Activity: 1204

Merit: 737

✅ Need Campaign Manager? TG > @TalkStar675

You have got something interesting but in my opinion its not so easy to detect those combination by using single partial match only. If you look deeply on those set of words then you can see there that in every single combination multiple words organised in different position. Its not like that same words are using on similar place or in a common combination each time. Every single time those words are making their pairs by changing previous combination. For those pairs of words easily more thousands of combination could be generated which is kinda tough to detect AFAIK.

DaCryptoRaccoon

hero member

Activity: 1220

Merit: 612

OGRaccoon

Hello everyone.

I have a strange topic I want to ask about, I have been doing some testing with seed words and have found something interesting that I cannot explain and I am looking for some advice or possibly the answer to why this is happening.

So I have a small python script that is used the old electrum code to generate the MPK seed and PK and PubK.
After running it with a specific set of words I started to notice many similarity in some of the hashes being returned to me.

far too many to be a coincidence.

the word set being used is

['ensure', 'alter', 'segment', 'spawn', 'cupboard', 'idle', 'horn', 'enrich', 'vendor', 'smooth', 'fruit', 'stone']

Here are some of the results that came back.

Partial Match 1

Code:

['ensure', 'alter', 'segment', 'spawn', 'cupboard', 'idle', 'horn', 'enrich', 'vendor', 'smooth', 'fruit', 'stone']
0: 1BC5kyKk4Cp8BQQnCGUrGyALKVRAFv8ZbC: [b]0142aa16fea967b90142aa1700f20785[/b]: 47acd3ff230114489bd8843f5844e30b918dbf9d1959c4005555bb7a1ff5c51811259339652327cfb0faa221cb64d2726daa105901eeea6a66cc7503258da122

['horn', 'enrich', 'vendor', 'segment', 'smooth', 'idle', 'alter', 'fruit', 'stone', 'cupboard', 'ensure', 'spawn']
0: 13XYF15nGbyTZCSAF1dzaGhmES4kdcqE3U: [b]0142aa17ff4a937e00c9d5f71003c8196[/b]: 62ea4c8b70b138180a5bae9516490f577d613a9988ac085267598d24f820c594ead48fcc09ed804222760b877927bd6acaf1900943d79a5adffdac42b41bd16b

P2

Code:

['idle', 'smooth', 'enrich', 'segment', 'fruit', 'cupboard', 'horn', 'vendor', 'ensure', 'alter', 'stone', 'spawn']
0: 13MdNvvebwPoADLqh8nMip7tgtHyBCe8rf: [b]ff731dea00c9a988ff730ae1fefa2a0d[/b]: 12a8d7a5d021a0b55f31c08877ee468a6f95c01a9f391e85a29d4d0cd4bb71c482e741f5a73b43c6fbd0f9a1cc3e4ef3b72dd493ee0d27ac3b6fd061d4c0474f

['smooth', 'cupboard', 'horn', 'idle', 'ensure', 'spawn', 'enrich', 'vendor', 'segment', 'alter', 'stone', 'fruit']
0: 14aB3QzdqrZYWJ8ctoPbzcuukzEuVLTn7N:[b] ff73048910014696c100147c7cff7330f9[/b]: d7a5be995e9e0aade40bbd41f0b418597f912c79dfbcc8b14b3247ea52b09a8b9a632c90d8a388cafdc147e6595f9c76a4b530e99f46a25abe420b039d51aae6

P3

Code:

['segment', 'horn', 'enrich', 'smooth', 'cupboard', 'idle', 'ensure', 'alter', 'fruit', 'vendor', 'stone', 'spawn']
0: 1BYyy7W4SxTV18vtX343AvDVnpg9WSsw5S: [b]ffebe55afea94e5500f1facefef9f745[/b]: 0184be21c8607345ea934384bfce9b00b6b0c99d40910b43944946d071306705ab603b6f9f7e8ae30cd7b6a59f2a926a38af711ef68fdaa41d4532fc4640921a

['spawn', 'ensure', 'enrich', 'cupboard', 'horn', 'smooth', 'alter', 'idle', 'fruit', 'stone', 'segment', 'vendor']
0: 1QHzzhLEYb1jmmerkDBeasfcpHNoq4dNVX: [b]ffebfebd0078e734011a5f2300509c45[/b]: c799a5f28bce411ff19c445c2ccce8ff310fdd04ee76cbc36e86be451cbebb5176b14604461ab9d6eeee38741635092b3d46da772e1d1a0ca6981e25c5b9f148

P4

Code:

['smooth', 'spawn', 'cupboard', 'idle', 'horn', 'ensure', 'alter', 'fruit', 'segment', 'enrich', 'vendor', 'stone']
0: 18mKvV94QZa78GvQAM39LBNLMbaoHhqL3: [b]0142a3bf100146fc60050cf0b0050dbc0[/b]: 8f71f7cfdfd400c6313cbfa99ef3b8964dfc6d3022d797e84e7b5e1a3d177d7837ff3976c7c588b163aa433127c000cf2d850c6b321688dbfdaa63ca8c67b67a

['fruit', 'ensure', 'stone', 'cupboard', 'horn', 'spawn', 'smooth', 'vendor', 'enrich', 'alter', 'segment', 'idle']
0: 1AsFMbNHudUAit1748jaPxL2E45nLRKou5: [b]0142b07210014304cff224ee7fefa16ff:[/b] a3cdb77d9971ee5f72d93859b051cd7ed67e104f05ab83d92eb00561aa2baf1b1af8ad61f799bb169d473e753c537f7166d5698ead59f198ae8565f325bdea4f

P5

Code:

['segment', 'ensure', 'horn', 'fruit', 'enrich', 'alter', 'idle', 'vendor', 'spawn', 'smooth', 'stone', 'cupboard']
0: 1DYNQRdnELPQNpc8z483TfS6JthT7GEjjz: [b]005095e81003c8e46ff4ad2fa100146973[/b]: 05e35ce254f82deaa6b5ca9a1d1cef64c5242f4281a948b430385e6d7c67157285f92025dd16a82e4fb98033f553e6e4b8b9c85dd404b71d0ef6d57f11f4b870

['fruit', 'spawn', 'ensure', 'cupboard', 'stone', 'enrich', 'idle', 'alter', 'horn', 'segment', 'smooth', 'vendor']
0: 14QqCQiTkJVyHc5KgsuJj3dvVQiZM6pWWT: [b]00509c40fed1994800a164ea0079009a[/b]: 685e32aae2053931b1a06ca39d9e2ae0c26b112ceb831f433ac231f6146f06e98ee985f02548fa31735e84c892f2310da346be48d0b627e79cd13f0c2193d27a

P6

Code:

['ensure', 'stone', 'fruit', 'horn', 'cupboard', 'spawn', 'idle', 'alter', 'segment', 'smooth', 'vendor', 'enrich']
0: 1AoCMiZEiuUwdCCyf2bbg9HBbBYqqivd7: [b]ff731deeff2261f3011a6bd6ff224ee7:[/b] 5ec064a83f2a19d3736e1a96f1eaa3cd54cd8e75fe5351d0e986a2dba5e27b437e36855bb3368c28c21a36f76a3c2844d5ce1acf071a0daa4d0207d3da54b042

['horn', 'vendor', 'smooth', 'alter', 'segment', 'ensure', 'spawn', 'idle', 'stone', 'fruit', 'enrich', 'cupboard']
0: 1Yq6kidaUtpzdprSRGKePBNHXjU2GrcBM:[b] ffec11cdff9b758f01e408a5016afb62[/b]: b5dc00ff63b649abd61be60d58b1909f25c45e5f08900d59507ff39f06a2013aa6c626eb56112efa8bae2acaaa19fc2dfc9f361f373c981c8ec4619d489fca63

P7

Code:

['fruit', 'stone', 'enrich', 'cupboard', 'vendor', 'idle', 'alter', 'ensure', 'horn', 'segment', 'spawn', 'smooth']
0: 1HX5wVovCUMmJCFuZ5PQ3JRFSvr1jeud6h: [b]fed1b2acfef9e43800286ab300c9967a:[/b] ee4875dd10630520647378f69b0974be59b076d9443ff5b999645411bb156a6cc3934d67cfb9ab3c7d97f5b933930d3f837b21000c91bf726fdc0d580ac6ef3d

['smooth', 'vendor', 'idle', 'enrich', 'segment', 'horn', 'alter', 'spawn', 'ensure', 'stone', 'fruit', 'cupboard']
0: 13WJoAWkqftY9DPxBEDDkk3xCTdK6PM1Yg:[b] fed19f9fffc3c6da0028645900c9967d[/b]: d2e3b54a56868fa4d201c72aedb6e9d99a55cad5a1215d0d87e0399cc70663e8194cdba5dbedd99250b5110941d5e326ae32bb0a14c84a1847fc5a51cc8d174f

Further Breakdown

Code:

Words Used :
['ensure', 'alter', 'segment', 'spawn', 'cupboard', 'idle', 'horn', 'enrich', 'vendor', 'smooth', 'fruit', 'stone']
0142aa16fea967b90142aa1700f20785 = 1BC5kyKk4Cp8BQQnCGUrGyALKVRAFv8ZbC

Words Used:
['horn', 'enrich', 'vendor', 'segment', 'smooth', 'idle', 'alter', 'fruit', 'stone', 'cupboard', 'ensure', 'spawn']
0142aa17ff4a937e00c9d5f71003c8196 = 13XYF15nGbyTZCSAF1dzaGhmES4kdcqE3U

Words Used:
['idle', 'smooth', 'enrich', 'segment', 'fruit', 'cupboard', 'horn', 'vendor', 'ensure', 'alter', 'stone', 'spawn']
ff731dea00c9a988ff730ae1fefa2a0d = 13MdNvvebwPoADLqh8nMip7tgtHyBCe8rf

Words Used:
['smooth', 'cupboard', 'horn', 'idle', 'ensure', 'spawn', 'enrich', 'vendor', 'segment', 'alter', 'stone', 'fruit']
ff73048910014696c100147c7cff7330f9 = 14aB3QzdqrZYWJ8ctoPbzcuukzEuVLTn7N

Words Used:
['smooth', 'spawn', 'cupboard', 'idle', 'horn', 'ensure', 'alter', 'fruit', 'segment', 'enrich', 'vendor', 'stone']
0142a3bf100146fc60050cf0b0050dbc0 = 18mKvV94QZa78GvQAM39LBNLMbaoHhqL3

Words Used:
['fruit', 'ensure', 'stone', 'cupboard', 'horn', 'spawn', 'smooth', 'vendor', 'enrich', 'alter', 'segment', 'idle']
0142b07210014304cff224ee7fefa16ff = 1AsFMbNHudUAit1748jaPxL2E45nLRKou5

Words Used:
['segment', 'ensure', 'horn', 'fruit', 'enrich', 'alter', 'idle', 'vendor', 'spawn', 'smooth', 'stone', 'cupboard']
005095e81003c8e46ff4ad2fa100146973 = 1DYNQRdnELPQNpc8z483TfS6JthT7GEjjz

Words Used:
['fruit', 'spawn', 'ensure', 'cupboard', 'stone', 'enrich', 'idle', 'alter', 'horn', 'segment', 'smooth', 'vendor']
00509c40fed1994800a164ea0079009a = 14QqCQiTkJVyHc5KgsuJj3dvVQiZM6pWWT

For reference here is parts of the code used to generate them..

Code:

def mpk_from_seed(seed):
   curve = SECP256k1
   secexp = stretch_key(seed)
   master_private_key = ecdsa.SigningKey.from_secret_exponent( secexp, curve = SECP256k1 )
   master_public_key = master_private_key.get_verifying_key().to_string().encode('hex')
   return master_public_key

while True:
   guess = random.sample(words,12)
   #guess = "sensure alter segment spawn cupboard idle horn enrich vendor smooth fruit stone".split()
   print guess
   seed = mn_decode(guess)
   mpk = OldAccount.mpk_from_seed(seed)
   acc = OldAccount({'mpk':mpk, 0:[], 1:[]})
   secexp = number_to_string(secexp, generator_secp256k1.order())
   compressed = False
   SecretToASecret( pk, compressed )

My thoughts were that the old electrum way of doing things each digit represented by a word is variable, it depends on the previous word. if this is the case the returned hashes make no logical explanation for there matching pairs for example if you look at the first two being

Code:

0142aa16fea967b90142aa1700f20785
['ensure', 'alter', 'segment', 'spawn', 'cupboard', 'idle', 'horn', 'enrich', 'vendor', 'smooth', 'fruit', 'stone']

and

Code:

0142aa17ff4a937e00c9d5f71003c8196
['horn', 'enrich', 'vendor', 'segment', 'smooth', 'idle', 'alter', 'fruit', 'stone', 'cupboard', 'ensure', 'spawn']

if the were to follow this rule then the hashes should be much much different as the words used are in a totally different order.

I also noticed many HEX values showing up during this for color values.

Code:

00509c40fed1994800a164ea0079009a = 14QqCQiTkJVyHc5KgsuJj3dvVQiZM6pWWT

#00509c = Royal Blue | RGBA 90, 80, 156, 1)

Dose the old electrum style wallet use color hex codes as part of the number process because from what I am seeing there seems to be some kind of detectable issue with the hashing of the same words in different orders ?

I hope someone can shed some light on this matter more as I am now rather stumped on where to look into this further.

Magic

Topic: Something Odd? Thinking caps on guys. (Read 462 times)