<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Pardon the interruption.  I'm working on a social-media identity federation project involving zero-knowledge proofs where you post public-key/nonce/sig combinations to multiple places to prove the poster identities' shared ownership of a private key.  Details (not really relevant to the following): <a href="https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity" target="_blank">https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity</a></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The representation of the public key needs to be textual. The most straightforward way to do that is a one-liner like so: Base64.getEncoder().encodeToString(key.getEncoded()) which gives you Base64'ed PKIX.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Problem is, people are wondering why they need PKIX. They want to use EdDSA and they don't see the need for algorithm agility (there's a faction that thinks it's actively harmful) and  point out that ed25119 keys are just 32 bytes worth of bits and don't see why they need to use Eighties technologies to express them in ASCII and ask "why can't I just base64 those bytes?"  Which is straightforward in Go and JS and so on.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">It is however not straightforward in Java (unless I'm missing something obvious, wouldn't be surprising) because sun.security.x509.X509Key.getKey() is protected; see <a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131" target="_blank">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131</a></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have verified, via abuse of the reflection APIs, that the BitArray that call returns does indeed represent the appropriate 32 ed25519 bytes. So, I have an object that has the data that I need inside but for reasons of policy it is declining to reveal them.  BTW you can do this in BouncyCastle and friends.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rather than changing protection on a long-established method, maybe a new public byte[] getKeyBytes() would be the thing to do?  Or maybe it would be better to make this an EdDSA-specific operation?  Maybe the EdDSA classes already provide a way to do this that I couldn't find?<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, with an apology for possibly wasting your time, two questions:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1. Is there a principled Java 15 way to get the key bytes that I'm not smart enough to have found?</div><div class="gmail_default" style="font-size:small">2. Failing that, would a proposal to allow access to un-PKIX'ed EdDSA key bytes be ruled out in principle for some good reason that I don't know about?</div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div></div></div>