Support V3 Onion Addresses

[terrance1977]

You can identify a next-generation onion address by its length: they are 56 characters long, as in "4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion".

https://blog.torproject.org/tor-0321-alpha-released-support-next-gen-onion-services-and-kist-scheduler

[lachesis]

Interesting idea, but pretty challenging. At its core, this project is about doing lightweight iteration through valid RSA keys so that we can quickly compute and check their SHA-1. The new hidden services don't use SHA-1 or RSA anymore. Instead, they use SHA3 with ed25519/curve25519. It would probably be easier to adapt oclvanitygen to build these addresses than scallion.

[kolet]

hey, any update on this matter?

[Lcstyle]

here's your update : https://github.com/cathugger/mkp224o

[lachesis]

We don't have any immediate plans to work on this. As I said above, this is really a major architectural change for this project. Of course, we're willing to accept patches, but if I were going to implement this, I'd build it against oclvanitygen or oclhashcat. I'm going to leave the issue open in case we get bored some weekend, but don't expect anything soon.

[kolet]

@lachesis oh, thats to bad, why u so against ocl ? @Lcstyle does this project support gpu and multi gpu system? have u tried it?

[19h]

I'm very confident that ed25519 is far more efficient for brute-forcing using GPU kernels. The only issue is that I couldn't really pin down the generation algorithm fully (yet). I guess this is a moment in which the hyper-optimized RegExp engine of Rust comes in handy and would allow for testing a rewrite of scallion :thinking: I'll play with that idea a bit.

[Lcstyle]

view the propv224 spec, https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt

Appendix C. Recommendations for searching for vanity .onions [VANITY]

[19h]

Funnily enough, I find the code you have linked to before (https://github.com/cathugger/mkp224o) much more accessible than the specification.

The algorithm to fast-bruteforce a valid pk/sk pair seems smart, but I don't understand what B is (Add the scalar 8*B to pk). Is that the number of the thread or a random number?

Edit: A generator is even listed in the specification: https://github.com/Yawning/horse25519 - I guess that's a very good point to start off with.

[Lcstyle]

I don't see the point in any of this. The problem is that the addresses are now so long that, even if you bruteforce a 32 length addr, there's still =(56-32) random characters left in the string, majority will not check the rest of the string to make sure they are not tricked. New spec leads to new vulns and attack surface. Why tempt fate (and prove that address spoofing will be one of the newest attack vectors).

[19h]

Vanity hostnames have never provided additional safety beyond the computational effort required to obtain a certain prefix and never will. If a user does not notice the difference of a prefixed hostname, he will likely not notice the difference of a entirely random hostname either.

Practically, having i.e. a 14 character prefix and remembering the last 10 characters should suffice unless you are dealing with an adversary that has an ineffable capacity of computing power. And in that case, you likely have more serious issues to deal with.

Having a named prefix in the address of a hidden service is just that: it looks nice.

[kenkit]

hey, before we used to verify private keys using this method/procedure.

U=$(openssl rsa -in a.pem -pubout -outform DER | tail -c +23 | shasum | head -c 20 | python -c "import base64,sys; print base64.b32encode(sys.stdin.readline().strip('\n').decode('hex')).lower()"); echo "http://${U}.onion"

How do we verify V3 address. Even pseudo-code will do. I'm working on a project that demands I have a method of verifying the generated keys.

[kolet]

any update on this ?

[ioistired]

@kolet, as Lcstyle already told you, there is another project already that can generate v3 onion addresses. https://github.com/cathugger/mkp224o

[Cyclic3]

@bmintz @Lcstyle mkp224o does not support GPU, and therefore is orders of magnitude slower than scallion. The author is not able to easily provide opencl with their code, due to a lack of hardware and a lack of OpenCL experience. The codebase is also predominately in C, and therefore modifying the entire codebase to support GPUs would be rather difficult. Is there really no easy way to add v3 support to this code? If not, I will try forking your code, but since my experience with C# is minimal and I haven't used .NET for half a decade, I may not get very far.