How to get ENC(A) of Ed25519 using pycryptodome?

[kuolemaaa]

Reading about ssh-agent protocol about EdDSA in chapter 3.2.3 of this draft, it says:

[RFC8709] defines Ed25519 and Ed448 with key type names "ssh-ed25519" and "ssh-ed448" respectively. These may be added to the agent using the following message. The "key constraints" field is only present for the SSH_AGENTC_ADD_ID_CONSTRAINED message.

byte             SSH_AGENTC_ADD_IDENTITY or
                 SSH_AGENTC_ADD_ID_CONSTRAINED
string           "ssh-ed25519" or "ssh-ed448"
string           ENC(A)
string           k || ENC(A)
string           comment
constraint[]     constraints

The first value is the EDDSA public key ENC(A). The second value is a concatenation of the private key k and the public ENC(A) key. The contents and interpretation of the ENC(A) and k values are defined by [RFC8032].

---

Now, [RFC8032]. states in section 3.1 Encoding that :

An element (x,y) of E is encoded as a b-bit string called ENC(x,y),
which is the (b-1)-bit encoding of y concatenated with one bit that
is 1 if x is negative and 0 if x is not negative.

and since Ed25519 is a particular instantiation of EdDSA, in section 5.1.2 Encoding the RFC states:

All values are coded as octet strings, and integers are coded using
little-endian convention, i.e., a 32-octet string h h[0],...h[31]
represents the integer h[0] + 2^8 * h[1] + ... + 2^248 * h[31].

A curve point (x,y), with coordinates in the range 0 <= x,y < p, is
coded as follows. First, encode the y-coordinate as a little-endian
string of 32 octets. The most significant bit of the final octet is
always zero. To form the encoding of the point, copy the least
significant bit of the x-coordinate to the most significant bit of
the final octet.

In pycryptodome I can easily get EccKey object that contains (x,y) and seed as bytes.

Let mat be some EccKey object, is mat.pointQ.y.to_bytes(32,'little') a correct method to get ENC(A) ?

[Legrandin]

The simplest method is:

mat.public_key().export_key(format='raw')

See also: https://www.pycryptodome.org/src/public_key/ecc#Crypto.PublicKey.ECC.EccKey.export_key

[kuolemaaa]

That did the trick. But why? Mine (mat.pointQ.y.to_bytes(32,'little')), compared to your, messed up the most significant bit of the last byte. But I don't understand why.

Also, the RFC8032, section 5.1.2 Encoding says:

First, encode the y-coordinate as a little-endian
string of 32 octets. The most significant bit of the final octet is
always zero. To form the encoding of the point, copy the least
significant bit of the x-coordinate to the most significant bit of
the final octet.

That's very odd and I can't understand the reason behind this procedure.

And again, in RFC8032, section 3.1 Encoding:

An element (x,y) of E is encoded as a b-bit string called ENC(x,y),
which is the (b-1)-bit encoding of y concatenated with one bit that
is 1 if x is negative and 0 if x is not negative.

Weird.

Please, feel free to share any resource to understand this quirk,

Thank you for the answer