Raw curve25519 public key points I'm trying to understand curve25519, and ECC public points.

I'm playing with Minisign, to better understand the fundamentals of ECC.

Minisign uses curve25519 and outputs public keys as base64 encoded strings in the following format:

base64(&lt;signature_algorithm&gt; || &lt;key_id&gt; || &lt;public_key&gt;)



  signature_algorithm: Ed
  
  key_id: 8 random bytes
  
  public_key: Ed25519 public key


As an example, my public key is:

RWRxmbgCt+0wPvdZ0alM7J46oqsOBTtud4E8zRznnCT0q0u7X971eWUN


Decoding this Base64 to Hex we get:

45 64 71 99 b8 02 b7 ed 30 3e f7 59 d1 a9 4c ec 9e 3a a2 ab 0e 05 3b 6e 77 81 3c cd 1c e7 9c 24 f4 ab 4b bb 5f de f5 79 65 0d


This makes sense... 45 64 == Ed

Next eight random bytes... 71 99 b8 02 b7 ed 30 3e

Then, if I'm correct, the public key... f7 59 d1 a9 4c ec 9e 3a a2 ab 0e 05 3b 6e 77 81 3c cd 1c e7 9c 24 f4 ab 4b bb 5f de f5 79 65 0d

Now this is what I'm trying to understand!

The public key is the right size (32 bytes/256 bits), however isn't it supposed to start with 04?

Also is it possible to take the public key and break it into it's X,Y co-ordinates as integers?

Is 16 bytes enough to represent a curve25519 X or Y component? 

Thanks for the help.
(minisign author here)

As noted by corpsfini, keys encode the Y coordinate. The X coordinate is recovered using the curve equation: X = sqrt((Y^2 - 1) / (d Y^2 + 1)).

The square root has two solutions, so we need to encode the sign of x as well. Since coordinates only require 255 bits, we have a extra bit, used to encode the sign.

X and Y ∈ [0; 2^255-19[, so 16 bytes wouldn't be enough to encode them.