Quote
And second, the message length of SHA256 is 512 bits, this means that SHA256 actually hashes blocks of 512 bits at once - but of course spits out a 256-bit result - so if you just start from "0" and someone breaks a couple rounds of SHA256 for one of these inputs, then theoretically that can be used to break those rounds for all other [M N] combinations with different nonces as well, and that's because if an input isn't a multiple of 512 bits it's extended by a one bit followed by a bunch of zero bits to extend it to a multiple of 512. So from SHA256's point of view, the first couple child keys are dangerously close to M with no nonce at all!
Why? Any hashed message is always 512-bits aligned, you have 256-bit public key and 256-bit nonce. Then, the second block in SHA-256 always looks like this:80000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000200
But as you don't know the offset of the master public key if you received only derived public key, you have no idea what SHA-256 output you should start with when trying to reverse it.
I guess you can disregard that part of my quote because I wrongly assumed the nonce is also getting hashes along with the master private key (right? I still don't think I fully get this. I reason we take the hash of the master private key concatenated with the nonce, and adding (arithmetic) it to the MPK itself
)How are we getting FirstAddedValue and SecondAddedValue for example? FirstAddedValue doesn't look like it's the sum of Master Public Key and FirstHashedData, assuming that the line of zeros below it is not part of the hash.