Topic: Dlaczego mnożenie kluczy publicznych przez siebie jest niezdefiniowane w ECDSA? (Read 53 times)

Idąc śladami vjudeu i próbując pisać w podobnym stylu, wrzucam swoje tłumaczenie. Myślę, że to dobry początek, zanim w ogóle przejdziemy do sygnatur Schnorra.

Wielu ludzi zastanawia się, dlaczego nie możemy mnożyć kluczy publicznych przez siebie w ECDSA. Możemy dodawać punkty na krzywej eliptycznej, odejmować je, mnożyć punkt przez jakąś liczbę, czy też wykonywać analogiczne dzielenie (wykorzystując inwersję). Głównym powodem takiego stanu rzeczy jest ukryty argument, o którym często się zapomina: punkt bazowy.

Bardzo często ludzie myślą o takich rzeczach, jak "dzielenie punktu na pół" w podobny sposób, w jaki można to zrobić na liczbach całkowitych, w innych językach programowania: jeśli mamy 9/10, to nam daje zero jako wynik. W przypadku ECDSA, takie reguły nie działają.

Aby lepiej zrozumieć, jak mnożenie punktu przez punkt mogłoby być zdefiniowane, możemy wziąć krzywą eliptyczną, którą kiedyś miałem w swoim awatarze: "p=79,n=67,base=(1,18),bits=7". Całość wygląda dość prosto, każda współrzędna zajmuje tylko jeden bajt i możemy z łatwością w pełni prześledzić wszystko, co tam się dzieje, bez dodawania jakichkolwiek optymalizacji, zwyczajnie sprawdzając wszystko metodą brute-force.

Zatem, zaczynamy od naszego p=79. Możemy łatwo ustalić, że mamy do czynienia z liczbą pierwszą, a także znaleźć najbliższy punkt, spełniający słynne równanie: y^2=x^3+7. Wszystkie liczby są na tyle małe, że możemy łatwo utworzyć bitmapę o rozmiarach 79x79 z czarnym tłem, a następnie ustawić białe piksele w miejscach, w których pozycja (x,y) spełnia wcześniej podane równanie. Co więcej, możemy nawet spróbować zrobić to samo, używając nieco większych liczb, uzyskując piękną tapetę, przypominającą gwiazdy na nocnym niebie.

Ciekawostka od tłumacza: użytkownik vjudeu w międzyczasie opublikował na swoim GitHubie pliki PNG z wszystkimi takimi krzywymi eliptycznymi, gdzie p<1000: https://github.com/vjudeu/curves1000

W ten sposób, możemy łatwo znaleźć najbliższy punkt, wynoszący (1,18) w tym przypadku. Dodatkowo, możemy policzyc wszystkie kropki i zauważyć, że mamy 66 punktów, zaś 67. wartość wynosi po prostu (0,0) i jest punktem w nieskończoności (który możemy uzyskać później, gdy spróbujemy dodać do siebie pierwszy i ostatni punkt).

Zatem, zacznijmy od punktu bazowego i utwórzmy listę wszystkich punktów:
Po obsłużeniu skrajnych przypadków, możemy zamienić każdy klucz prywatny "d" na odpowiednią parę (x,y) i kręcić się tak w nieskończoność:
Jak łatwo zauważyć, zaczęliśmy od p=79 oraz równania y^2=x^3+7, nie mieliśmy żadnych innych danych wejściowych. Uzyskaliśmy n=67 i w tym momencie możemy mieć 100% pewności, że wartość "n" to nie jest coś, co wybieramy, tylko po prostu obliczamy. To jedyny prawidłowy wynik, dzięki czemu całość może działać prawidłowo i spełnia nasze kryteria bycia "tak podobnym do secp256k1, jak to tylko możliwe" używając mniejszych liczb w celu pokazania, jak to wszystko ze sobą współgra. Jeśli zwiększymy liczby, możemy nabrać jeszcze większej pewności, że wartość "n" nie została wybrana ręcznie: po prostu została wyliczona, używając świetnie zoptymalizowanego kodu.

Ciekawostka od tłumacza: przykłady większych krzywych eliptycznych są w jednym z anglojęzycznych tematów: https://bitcointalksearch.org/topic/smaller-elliptic-curves-y2-x37-based-on-secp256k1-5459153

Teraz już mamy wszystko, czego potrzebujemy, aby dowiedzieć się, dlaczego nie możemy mnożyć dwóch kluczy publicznych przez siebie. Zapiszmy parę mnożeń na kluczach prywatnych i zamieńmy je na odpowiednie klucze publiczne, zgodnie z tabelą wyżej:
W tym momencie, możemy spróbować założyć, że chcemy używać innego punktu bazowego, na przykład (75,41) zamiast (1,18). Utwórzmy pełną listę wszystkich punktów i zobaczmy, jak nagle wszystko zacznie się zmieniać:
Następnie, zapiszmy ponownie te same mnożenia:
Widzicie? Wszystko wygląda zupełnie inaczej. Wszystko się zmieniło. Możemy nawet wziąć nasze stare punkty i zobaczyć, jakie klucze prywatne się za nimi kryją, gdy weźmiemy pod uwagę nasz nowy punkt bazowy:
Widzicie? Mnożenie dwóch kluczy publicznych przez siebie prowadzi do kompletnie błędnych wyników, jeśli próbujemy robić to bezpośrednio, na podstawie dwóch punktów, bez obliczania wszystkiego względem punktu bazowego. Mam nadzieję, że ten temat pozwoli lepiej zrozumieć, dlaczego niektóre działania nie mogą być wykonane w ramach ECDSA, a także jak niejawne argumenty, takie jak punkt bazowy, mogą łatwo zmienić wszystko, jeśli zapomnimy ich uwzględnić w naszych obliczeniach.