Support 'ed25519v1-secret' format onion v3 keys

[the-honeybadger]

Background

The TOR service will generate keys that start with == ed25519v1-secret: type0 == followed by code that isn't representable in ascii. LND generates a keyfile that starts with ED25519-V3 followed by base64. I wish for LND to support TOR's native v3 onion key format or offer a flag to remove the auto-generated onion address advertisement. It doesn't matter to me if the TOR service hosts the keys or not, I just don't want two onion URIs in LND.

Your environment

lnd 13.1
debian 10
bitcoind 0.21.1
tor 0.4.5.10

Expected behavior

I need LND to have tor.active=true and only advertise one URI which is derived from TOR style v3 keys.

Actual behavior

I end up with two onion addresses in lncli getinfo; one from LND and another from the tor service.

Notes

I'm really sorry to be so persistent about this. Thank you for your help.

[guggero]

Would be nice to support this.
Until then, the conversion could be as easy as:

cat v1_secret | cut -b 32-999 | base32 | xargs -I{} echo "ED25519-V3:{}" > v3_onion_private_key

Haven't tested this on a real key, but should work more or less.

[the-honeybadger]

That creates a file with ED25519-V3: at the beginning and also again towards the end. File size is 136 bytes (or smaller if I use base64) compared to the 99 byte key created by LND.

Also, TOR will create two files; hs_ed25519_public_key and hs_ed25519_secret_key; where is the public key stored for LND?

[gkrizek]

Good timing as I was just playful around with this too. Oli’s command didn’t work for me either. I’ve tried a bunch of different ways with no luck. I either get a failure trying to read the key or a strange error about Missing Port in Argument

[gkrizek]

Looking at the Tor spec, it seems like it expects base64 and not base32 for the key. Nonetheless, it still doesn't work when I use Oli's command with base64. I booted up Tor and I'm trying to use the ADD_ONION command directly with my output but no luck. I always get:

512 Failed to decode ED25519-V3 key

For a "ED25519-V3" key is the Base64 encoding of the concatenation of the 32-byte ed25519 secret scalar in little-endian and the 32-byte ed25519 PRF secret.

I wonder if there's more parsing that needs to be done with the hs_ed25519_secret_key file?

[lnd-routing]

To convert back and forth, you can

echo "ED25519-V3:$(dd if=hs_ed25519_secret_key bs=1 skip=32 | base64)" > v3_onion_private_key

and

echo 3d3d206564323535313976312d7365637265743a207479706530203d3d000000 | xxd -r -p > hs_ed25519_secret_key
dd if=v3_onion_private_key bs=1 skip=11 | base64 -d | dd of=hs_ed25519_secret_key bs=1 seek=32

You can drop the hs_ed25519_secret_key in the hidden service directory, and tor will create the hostname and hs_ed25519_public_key files automatically.

[lnd-routing]

You can also set up the service in torrc and remove the tor.v3 line on lnd.conf, leaving

listen=localhost
tor.active=true
tor.streamisolation=true
externalip=lndroutekytme3xds6cmbxaniretdgox2hk4cpu4k27jnub3gkfeuhqd.onion:9735

change the externalip to your own onion address.

This is our current setup and only advertises one onion. We converted the original v3_onion_private_key to a hs_ed25519_secret_key to keep our old address connectable for while until everyone's graph syncs.

[gkrizek]

Thanks for the help, @lnd-routing . That worked! I went with the conversion as it's easier for automation. I also figured out what my Missing 'Port' in argument error was because the file had a line break at the end of it. All working now 👍

[lnd-routing]

Note #5757 is why we use torrc instead of letting lnd manage the address.

[jrydval]

I had a problem with a \n at the end of the key and somewhere near to the middle when using the proposed echo " ... " command.

This small modification seems to solve both issues for me:

echo -n "ED25519-V3:$(dd if=hs_ed25519_secret_key bs=1 skip=32 | base64 -w 0)" > v3_onion_private_key

[xanoni]

FYI, on MacOS the -w 0 has to be removed ... see https://github.com/xanoni/tor-misc/blob/main/tor-privkey-to-base64.sh

Cupertino ships the BSD version of base64, which is a bit different.

Alternatively, you can use the GNU version (gbase64 if installed via Homebrew).

[gus4rs]

The last echo command apparently seems to generate the v3_onion_private_key, but when lnd starts it fails:

Apr 21 07:32:36 localhost.localdomain lnd[795811]: 2023-04-21 07:32:36.359 [ERR] LTND: Shutting down because error in main method: unable to start server: unexpected code
Apr 21 07:32:36 localhost.localdomain lnd[795811]: 2023-04-21 07:32:36.359 [ERR] TORC: DEL_ONION got error: invalid arguments: unexpected code

What is the current way of not letting lnd generate on onion and use an external onion generate from hs_ed25519_secret_key ?