Why would a person generating seeds to be used in standardized elliptic curves derive it from such a simple sentence or phrase?
1. People used
nothing-up-my-sleeve numbers to generate elliptic curves.
2. There was some FUD, that those curves are unsafe, because they are "not random enough".
3. People created some random curves, to address this FUD.
4. Then, people started questioning that "randomness" being not explained enough, creating another FUD.
This challenge was made to clean up the FUD. But because the whole process is not fully documented, the task is to recover the full algorithm, to clear all of that FUD. Why it was not fully documented in the first place? Because people are lazy, and they focus on writing code, rather than documentation, then some of that is lost in the history, and then you have things that are officially used in production, but are not fully explained.
Considering how brainwallets have been broken into (and those used SHA256), isn't that a bit unsafe?
Not really, because it is very unlikely that creators of those curves had any special knowledge, that was not publicly revealed by independent researchers. You can read
A riddle wrapped in an enigma if you want to know, why elliptic curves are safe, even if they are generated from simple phrases like "Hello world".
It would be far more secure to generate them from a sequence of - given enough entropy - random bytes.
3045AE6F C8422F64 ED579528 D38120EA E12196D5 secp192r1, P-192 (challenge)
BD713447 99D5C7FC DC45B59F A3B9AB8F 6A948BC5 secp224r1, P-224 (challenge)
C49D3608 86E70493 6A6678E1 139D26B7 819F7E90 secp256r1, P-256 (challenge)
A335926A A319A27A 1D00896A 6773A482 7ACDAC73 secp384r1, P-384 (challenge)
D09E8800 291CB853 96CC6717 393284AA A0DA64BA secp521r1, P-521 (challenge)
Here you have some bytes that looks randomly. Guess what: now people ask about that randomness, and they want to know, how exactly that "randomness" was created in the first place.
In 1970s - 80s it would not be so difficult to calculate SHA1 of any bytes input given suitable hardware.
Who knows, maybe that was the case. Maybe one of those seeds is just a result of something like SHA-1("Hello world 123456"). But the problem is, that nobody exactly knows, how those bytes were generated, so the whole challenge is about finding that out.
Edit:
ha. I never looked at them laid out that way before.
I found a pattern, but I don't know, how to continue that.
u1= 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62 (160-bit)
u2=0554123b78ce563f89a0ed9414f5aa28ad0d96d6795f9c66 (192-bit)
u3= 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63 (224-bit)
u4= 3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63 (256-bit)
Subtract u1 from all other values, to make it more clear:
u1= 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62 (160-bit)
u2=0554123b3000000000000000000000000000000000000004 (192-bit)
u3= 3b3000000000000000000000000000000000000001 (224-bit)
u4= 3b3000000000000000000000000000000000000001 (256-bit)
And then, split it:
u2=05 54 12 3b 30000000000000000000000000000000000000 04 (192-bit)
u3= 3b 30000000000000000000000000000000000000 01 (224-bit)
u4= 3b 30000000000000000000000000000000000000 01 (256-bit)
Then, treat the last byte as your counter, and observe values going beyond 160-bit value:
+---------+-------------------------------------------+
| counter | values |
+---------+-------------------------------------------+
| 00 | nothing (or truncated, because of modulo) |
| 01 | 3b |
| 02 | 3b 12 |
| 03 | 3b 12 54 |
| 04 | 3b 12 54 05 |
+---------+-------------------------------------------+
But then, the big question is: why the first value does not begin with "30"? I don't know, maybe the counter also increments some bits at the beginning? I will try to check some other valid points around that, to confirm, why they could be skipped.
Edit: Do you know any other magic value than 76439, that was used to produce "random, but not quite" numbers? I know how it was used in secp112r1, and I can even expand it, but still, I cannot find anything useful:
db7c2abf 62e35e66 8076bead 208b
00029274 803e28aa 1b338164 3c07
61a10007 b75d80ba 79fe519a 842c
b41624e3 00172618 822f6dfa f4cf
8c861c42 6ea90045 7249868e 49f0
de6ea592 54c74bfb 00d056dc 93aa
ddd29b4b f0b6fe55 e3f10271 0495
bb009977 d1e3d224 fb01abd3 0753
You can concatenate all of that, and multiply again by 76439, then you will see just a huge number, close to 2^N.
Edit: In
sect113r1, when we calculate half of the base point, then we can find very small x-value:
F. = GF(2)[]
K = GF(2^113, name="x", modulus= x^113 + x^9 + 1)
E = EllipticCurve(K, (1, K.from_integer(0x003088250ca6e7c7fe649ce85820f7), 0, 0, K.from_integer(0x00e8bee4d3e2260744188be0e9c723)))
E.set_order(0x0100000000000000d9ccec8a39e56f * 0x2)
G = E(K.from_integer(0x009d73616f35f4ab1407d73562c10f), K.from_integer(0x00a52830277958ee84d1315ed31886))
private_key = 0x800000000000006ce676451cf2b8
P = private_key*G
print(hex(P[0].to_integer()),hex(P[1].to_integer()))
This
Sage code can give us this point:
0x3 0x1a7078c5d29ee7ea6e8ff326518f5
Which means, my idea of starting from x=1, and incrementing that, is closer to the reality, than I thought.
Edit: I found a new hint: each of those hashes is a valid x-value on a curve, where p=0xfffffffffffffffffffffffffffffffeffffac73, that is used in secp160k1. I reached those points:
02 3045ae6fc8422f64ed579528d38120eae12196d5 33f505091031a9f3fedf0de27523b755af69cd72
03 3045ae6fc8422f64ed579528d38120eae12196d5 cc0afaf6efce560c0120f21d8adc48a95095df01
02 bd71344799d5c7fcdc45b59fa3b9ab8f6a948bc5 6441e8714d66ae3077e617136353a8d0bdc56318
03 bd71344799d5c7fcdc45b59fa3b9ab8f6a948bc5 9bbe178eb29951cf8819e8ec9cac572e423a495b
02 c49d360886e704936a6678e1139d26b7819f7e90 d40dfa96a30216857f8d0a768e1bfb7e7efbca98
03 c49d360886e704936a6678e1139d26b7819f7e90 2bf205695cfde97a8072f58971e404808103e1db
02 a335926aa319a27a1d00896a6773a4827acdac73 7a8d7a04b47ca665132a5a98fbd950c69a328a90
03 a335926aa319a27a1d00896a6773a4827acdac73 857285fb4b83599aecd5a5670426af3865cd21e3
02 d09e8800291cb85396cc6717393284aaa0da64ba d8b87c1b9c2eb455f3804ce0689368de2c43028c
03 d09e8800291cb85396cc6717393284aaa0da64ba 274783e463d14baa0c7fb31f976c9720d3bca9e7
Edit:
I found a pattern, but I don't know, how to continue that.
There is a better pattern: all values can be taken modulo p=0xfffffffffffffffffffffffffffffffeffffac73 (used in secp160k1), and then, it is a valid x-value on that curve:
0x48ce563f89a0ed9414f5aa28ad0d96d6795f9c62 0x432562b5328ba8c0aafef5109384b4e43b2503a9
0x78ce563f89a0ed9414f5aa28b261aaceaa96c7e5 0x6a6fa7d9499c6d862b24baf53a2b96f32c0ba1be
0x78ce563f89a0ed9414f5aa28ad0d97117972dde2 0x66392754d8b777e0414311d3eae3863189951c23
Which means, the only values that we can pick from, is when p-value from secp160k1 can be intersected with p-value from another curve, and form a valid x-value on both.