I'm trying to implement X25519 for a little game I'm working on. I knew nothing about this stuff a week ago so it's been a bit of a learning curve (that was really funny).
Most of the resources I found online were easy to follow, so I have a seemingly working implementation. While looking around I saw that apparently you only need to send the x-coord over as a public value, and this kinda made sense to me since the order of the field is only 255 bits, and any given x-value can be solved for its positive and negative Y values since the field order is prime. So I assumed that the 255 bit modulus must be intentional and I should use that left-most bit for the sign of the y-value.
My issue is that my encoded points now look so different from standard implementation examples. This is what my program produced using the same private constants as what I linked before:
Alice Private: 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
Bob Private: 5dab087e624a8a4b79e17f8b83800ee66f3bb1292618b6fd1c2f8b27ff88e0eb
Alice Public: 6608e5b4605f127df80669441a55b0c4b626a7939000855b15b1c95a6e629a9c
Bob Public: 8b64bae6625caec5c268b45c3a825dc8e652eebb696d2c656eafb1fa58c0baf8
Alice Shared: 91970c98ef12885c88183ffb0dadfac3b5c2393d9bd6b9c47731a397bb41cbe9
Bob Shared: 91970c98ef12885c88183ffb0dadfac3b5c2393d9bd6b9c47731a397bb41cbe9
Now I know they're encoding theirs in little-endian, while I'm encoding mine in big-endian. However, even when you flip my bytes in the public/shared points, they are still very different. If it helps diagnose my issue, I'll write the coordinates of the public keys in decimal form here:
$ P_a = (46151630694864304263960154846901714359828178739062117159025277647732615584412, 13070594169239478115446582128550067480452326318343516314474879361527799519490) $
$ P_b = (5153415976860737231489140981670764582417246538397187051112043112911247293176, 25483510201555755930319734503743573632884549243572659667161192979128153937544) $