Converting Ed25519, Ed448 keys fails if encoding has leading 0

[vanitasvitae]

Hey!
I noticed, that generating Ed448 keys is not totally reliable and fails in 0.5% of the time.

Apparently, in some cases, in this block, the type is identified as Ed448 by looking at enc[8], but the prefix array does not match the header bytes of the enc array, causing this check to fail.

An example:
The conversion fails for a key with the following encoding

rawData = 3042300506032b6571033900cc41697d47dd92200f746bded5cd456274cd5a879ed8e2ba3c46c943b532316b115a5173ba5fae196cdce5bcc716295f24b8acdfb7ea6280
prefix =  3043300506032b6571033a00

Note the mismatch in octets with index 1 and 10.

Contrary, a valid key:

rawData = 3043300506032b6571033a004ead091781d6ae7d7ad606aa6846e3e03d85b3b12d777e69e791d648cd7d2a16195e1f50a06f6d3600baa4460df216e83e5e256c443ee53880

[vanitasvitae]

Some more insights: Key conversion fails, if the encoding (publicPk.getKey().getEncoded()) has a leading 0.
In that case, BigIntegers.asUnsignedByteArray(...) removes that 0, causing the failure.

If I remove the BigIntegers call and instead pass publicPk.getKey().getEncoded() directly into implGetPublicKeyX509(), the test passes without any errors.

I suppose this method call is there for a reason though?

Edit: The bug also happens for Ed25519 btw.