Generating and validating a signature with ED25519 expanded private key

Question

I am building a encrypted messaging app over tor network and currently I'm struggling on using tor generated ed25519 private key to sign and verify any message.

Below piece of code works with a 32 bytes key however after skipping 32 header bytes of hs_ed25519_secret_key it fails to verify the signature on below cases:

1 - secret: left half of the remaining 64 bytes, public: right half
2 - secret: left half of the remaining 64 bytes, public: last 32 bytes of hs_ed25519_public_key after removing the header
3 - secret: all 64 bytes, public: last 32 bytes of hs_ed25519_public_key

I found a python library that seems to do this PyNaCl however i not familiar with py too much.

Is there something i am doing wrong or bouncycastle does not support expanded 64 bytes private keys

import org.bouncycastle.crypto.Signer;
import org.bouncycastle.crypto.params.Ed25519PrivateKeyParameters;
import org.bouncycastle.crypto.params.Ed25519PublicKeyParameters;
import org.bouncycastle.crypto.signers.Ed25519Signer;
import java.nio.charset.StandardCharsets;
public class ED25519 {
    public static void main(String[] args) throws Exception {
        byte[] message = "a msg to be signed".getBytes(StandardCharsets.UTF_8);
        Signer signer = new Ed25519Signer();
        signer.init(true,  new Ed25519PrivateKeyParameters(KeysUtil.myPrivKey, 0));
        signer.update(message, 0, message.length);
        Signer verifier = new Ed25519Signer();
        verifier.init(false, new Ed25519PublicKeyParameters(KeysUtil.myPubKey, 0));
        verifier.update(message, 0, message.length);
        boolean validSig = verifier.verifySignature(signer.generateSignature());
    }
}

Answer 1

BouncyCastle uses the RFC 8032 definition of the private key, which is basically a 32 byte seed. That seed is input to SHA512, which produces 64 bytes consisting of an 'internal' 32 byte secret ("s") and an additional 32 bytes pseudo-random value ("h"). It looks like Tor treats this latter 64 bytes (the output of SHA512) as the secret key, so this is incompatible.

Of course it would be relatively straightforward to provide a way to work with these keys (at least in low-level utilities), but it doesn't exist yet.