Sharing "mined" private keys (.onions) with others in a trustless way?

[xanoni]

The ones who ask the seemingly stupid questions—the questions that no one else dares to ask—can sometimes make the critical difference, so let's do this ;-)

Is there any way a "mined" private key (vanity .onion) can be shared with another person (for that person to use it to host some service), WITHOUT requiring full trust in the person who originally found the key?

Without further precautions, I assume the person receiving the key has no guarantees that the person who found the key didn't keep a copy to then take over the service (or to at least surveil it in some form).

I don't see how this could be made trustless, but maybe my superficial knowledge of ed25519 is not sufficient to see the relevant nuances.

[scribblemaniac]

In my non-expert opinion: yes it is likely possible. This is possible with ECDSA for sure as there are multiple programs out there that support this functionality already. See https://bitcoin.stackexchange.com/questions/3853/can-one-safely-buy-vanity-addresses-from-a-third-party-without-risking-ones-coi for an explanation of how this works. Since EdDSA also relies upon elliptic curves, it seems like it should have the same properties and would be able to generate vanity addresses trustlessly in the same way. Here someone is asking that very question and although there is no answer, it does have some relevant links: https://crypto.stackexchange.com/questions/75981/does-eddsa-share-schnorr-signature-secure-linearity-property.

Without further precautions, I assume the person receiving the key has no guarantees that the person who found the key didn't keep a copy to then take over the service (or to at least surveil it in some form).

Yes if someone you do not trust has a copy of your private key at any point, it's worthless from a security standpoint.

[xanoni]

That's pretty cool... nice. Now we just need to put the pieces together ...

[cathugger]

huh so basically, requester sends public keys to miner. miner performs certain amount of additions to that given public key and finds public key which matches given criteria. then miner returns amount of additions it performed to requester. quite nifty idea.

[cathugger]

and requester then easily adds that counter to its current secret key. not very difficult to implement logic wise but i wonder what best protocol would be for this.

[cathugger]

additionally, with that linearity property, one wouldn't need to re-send new public keys for eventual exhaustion case. one could just send offset public key. upon successful match, workserver would send private keys back, which would be added to local offset private key. in theory. there are some actual limitations to what ed25519 secret key components have to look like. so not 100% sure if this would be okay.

[cathugger]

was thinkin abt this a bit and even if we use scalar addition to make up secret keys, we would still need sending fresh ones upon every successful find because otherwise other keys would be too easy to compromise by leaking only single key of such set. attacker would know scalars it generated in set, and if one scalar with secret part added gets leaked, attacker could easily subtract whole key from their part and obtain secret part they could easily use to calculate rest of keys from the set by adding secret part to them. it's non-issue if user would only use single key of set but definitely a footgun. honestly it's probably going to be much easier to just think of proper way of feeding needed data to workserver which will make this problem go away regardless whether we only send deltas or do scalar addition magic.

[adapt-L]

I think this is a great idea, and I would like to offer a 0.8 monero bounty to anyone who can implement this properly.

I've been trying to generate a 10-char onion address, and at this rate it will take me a year or two. My attempts to make a GPU-accelerated vanity generator have been abysmal, with only ~0.2% performance of amd64-64-24k on the host CPU. With this feature, I could just have my buddy mine the vanity for me on his server.

I don't really know much about elliptic curve cryptography, but the impression I get from cathugger is that networking is only needed for generating multiple vanities that are independently secure from the miner if the SK is revealed.

My use case here is just generating a single vanity, but could a generic solution to this be something like the client generates 1000 random keypairs and puts all the public keys in a file and manually sends them to miner? I think It would remove the need for networking, so the user interface is basically just:

• a command-line flag for the client to generate N keypairs (where N is a big number like 1000 by default) and export the seckeys and pubkeys to separate files

Client sends the pubkey file to miner...

• a command-line flag for the miner to generate vanities using the file full of pubkeys, iterating through the list every time it finds one.

The miner does that and uses the first command-line flag to export the seckeys and pubkeys to separate files, and sends them back to the client...

• a command-line flag for the client to combine the keypair files

The client combines the keypairs and exports it as a normal onion service directory

I guess it isn't so great if you're generating like millions of vanities and doing some sort of dictionary search or something, but the filtering should really be done on the miner's side, no?

In any case, I think transferring the client's public keys manually in bulk through file transfer would be simpler for the client who may be behind all sorts of firewalls, NAT and other crap. For example, the miner could just be some automated (paid?) service that exposes a web server, and the client can upload their pubkey file through a web form.

[dzwdz]

I've implemented a basic PoC at https://github.com/dzwdz/mkp224o/tree/trustless. It seems to work, but I'm not sure if the math checks out. The code definitely could use some work too.

The host generates a set of base keys and sends the public part to the miner. I haven't implemented any sort of networking or native support for multiple keys, as I don't think it's necessary. If you wanted each generated vanity address to use a separate base key, you could just do something like this:

for base in keys/*
do
    mkp224o -n 1 --basekey $base -d out/$base/ neko
done

[preland]

Hey, I’ve been looking at this project for a few days, and it seems to be pretty promising.

I have a question regarding this issue in specific, or rather the solution currently being shown.

Would it be possible to use this “trust-less” solution to pre-generate keys for a ton of filters, building a “catalog” of sorts? IE: if someone goes to the catalog with a specific request that has already been generated in the catalog, it can retrieve the information required for the request to be fulfilled.

If this is the case, then there is an incredibly large amount of potential here.

[dzwdz]

Would it be possible to use this “trust-less” solution to pre-generate keys for a ton of filters, building a “catalog” of sorts? IE: if someone goes to the catalog with a specific request that has already been generated in the catalog, it can retrieve the information required for the request to be fulfilled.

No. The mined .onion is tied to your keypair - if you change the base key, the address changes too.

If I'm understanding you correctly - you're asking about creating a catalog where one could redeem a premined .onion such that they would be the only person with access to the private keys. What would stop someone else (e.g. the catalog's owner) from also "redeeming" it? This solution only works because you already know the base keypair in advance.

[adapt-L]

Here is a funny idea for @preland: you might be able to create a service that crawls Tor for onion addresses and mines vanities for them ahead of time, filtering for random dictionary words, or words that occur within the onion services' webpage, for example within the webpage's