[kosasbest]

I regularly go to Dark.fail[0] to get the latest .onions some sites are using, like the BBC:

    https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion

Just be careful out there. All I have to do is alter one letter for the BBC .onion and I can get phished/scammed/duped. For example, this is an altered .onion for BBC:

    https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7746uqd.onion

Can you spot the alteration?

[0] https://dark.fail/

> Accurate URLs verified by PGP. No direct linking in order to protect against DNS leaks from accidental clicking in a clearnet browser.

How does the PGP verif work? I'm not used to it. There exists a tool here[1] but how does it all work?

[1] https://dark.fail/pgp

[LeoPanthera]

This is spectacularly misleading. That second address isn't real, and doesn't work.

It is computationally infeasible to generate an onion address similar to an existing one. Yes you could make another one that starts with "bbcnews", but all/most of the other characters would be different. Additionally, since the BBC is using https, the cert would be different, or missing.

This is scaremongering.

[3np]

Indeed. For anyone unfamiliar with the nature of cryptographic hashes, each character increases the difficulty to get a collision exponentially.

~10 characters are easy enough to generate on a single machine so don't rely on a vanity-prefix and the trailing couple of characters only, but getting a new .onion address matching even half of an existing one within the lifetime of civilization is unrealistic even with state-actor resources.

You'd be better off trying to brute-force Satoshi's bitcoin private keys if you're feeling that lucky...

https://github.com/cathugger/mkp224o/issues/27

[schoen]

If I'm following my intuitions about the math in the right direction, the probability of getting a single-character-or-less edit distance from a given target hash is (56×32)/32⁵⁶ per attempt.

The expected number of attempts to get one success at this would then be about 2²⁶⁹. Even so, a typosquatting victim would be very unlikely to make the exact right typo for the attack to work!

I think my reasoning is wrong somehow because I think there are only 2²⁵⁶ different onionsite public keys, so it doesn't quite make sense that you would have to do 2¹³ more work than trying all of them. But I'm still pretty convinced that it's going to be infeasible without a strong break of the hash function.

In terms of attacks that merely try to generate onion addresses that are merely somewhat visually similar to target ones (e.g. by matching at the very beginning and very end?), these are possible, and it would be interesting to see research about how likely people are to fall for various attacks like that. Maybe that research has already been done?

[Jerrrry]

>If I'm following my intuitions about the math in the right direction

you are, except our theoretical familiarity with math and the antecedent nature of life can easily lead us to intuitions that mature to fallacies quickly.

https://en.wikipedia.org/wiki/Birthday_problem

>e.g. by matching at the very beginning and very end?)

Thankfully those smarter than us have solved this problem too - the "hashing" algorithm is so fundamentally lossy (but not too lossy to fall into the pidgen-hole paradox) 1-way, that it is mathematically impossible to have any knowledge of the end of the hash before you get it.

You can "brute-force" it backwards, sure (for some old hashes obviously) - give me a string that's MD5 starts with "Jerry" and ends with "loves math", and I will congratulate you on your waste of computational resources.

[schoen]

Sure, but targeting similarity with a previously-chosen hash is a scenario where the birthday paradox doesn't come in. The case where it does would be "can we produce two arbitrary new hashes that are similar in this way?", in which case the amount of work required might be about the square root of what our intuition might suggest.

(although I think there's an explosion in the required space in that case because you need to store information about all of the values that you've already been able to produce, in order to learn whether new values collide with them!)

[Jerrrry]

>"can we produce two arbitrary new hashes that are similar in this way?"

arbitrary may be the heavy lifter here, we can certainly birthday-paradox two address that look similar (square root, yes)

>(although I think there's an explosion in the required space in that case because you need to store information about all of the values that you've already been able to produce, in order to learn whether new values collide with them!)

bloom hash table a bloom hash table with some nerdy optimizations for backtracking, depending on whether your IO/CPU/GPU or network were the bottleneck. If you got a double-positive, skip the integer/nonce/etc.

Although, realistically, I'd be very surprised if in a quintilion PETAFLOPS you found a single 128bit number that, after being hashed twice, starts with "face" and ends with "book"

[n2d4]

Arbitrary means: It's "easy" (square root) to find two numbers that resemble each other in a sufficiently large set, but neither of them will resemble anything meaningful. It's still "hard" to find a number that resembles a previously given different number, such as the bbcnews hash above. (The chance that any two kids in a room share a birthday is fairly high; the chance that a kid has their birthday on January 1st is much lower.)

> Although, realistically, I'd be very surprised if in a quintilion PETAFLOPS you found a single 128bit number that, after being hashed twice, starts with "face" and ends with "book"

We can just calculate it. "face" + "book" is 8 characters in base 64, for a total of 8*6=48 bits that need to be set a certain way. 2^48 is roughly 10^15. Hashing once or twice barely matters at this point (2*10^15 ~=~ 10^15). A quintillion petaflops is 10^33 flops, so unless your hashing algorithm takes 10^18 floating point operations, you have an incredibly high probability of finding such a number within a second.

[Jerrrry]

Blatantly incorrect, and nearly dis-intelligently so....unless you know something we don't?

.onion domain address are like cryptographic collisions - you must try trillons of nonces (random numbers, ya nasty brits) to even approach the chance of a collision that is recognizable in a literary sense.

Now, RAT's waiting patiently for you to copy/paste transferred funds have plenty of time - especially when they know (and so do many wallets noawadays) that most people check the first and last characters.

[Retr0id]

How the heck does this work? I thought .onions were essentially a hash of a public key, making finding collisions (or even 1-char near collisions like your example) infeasible. Do both of your example links resolve? If so, how?

I have no doubt that you can find one with similar prefix and/or suffix, but not to the degree of similarity of your example.

[michaelt]

> How the heck does this work?

It doesn't.

But you could use brute force to produce something like https://www.bbcnewsd7xlp77nkq76byazcldy2hlmovfu2egnv7t2rccij... and at least some people will be inattentive enough to fall for it.

[Tenoke]

I haven't done it recently but I prefer to go to dreddit for finding the currently respected markets and links.

dark.fail has been comrpomised in the past

https://www.reddit.com/r/onions/comments/n1byhj/has_darkfail...

https://www.reddit.com/r/onions/comments/12axsiz/is_darkfail...

[SuperGlueDoctor]

>How does the PGP verif work? I'm not used to it.

I will try to give a simplified explanation as best I can. PGP verification is a vital process to learn. Once learned it is easy to verify yourself. You need to know PGP if you are visiting .onion sites, it is not optional if you want any certainty.

The information in a PGP signed message is encrypted using a password (the private key) in such a way that only a different password (the public key) could unlock it. Once you have a trustworthy public key from a site/individual, you can check to see if a message was signed using the correct password in the matching private key.

If truly kept private, you can trust it is a message from the same person who gave you the the public key to begin with. That is how we know .onion urls are from the owners of the sites.

If the address ever needs to change, they will sign a new message that you can know for certain came from someone in possession of the SAME private key as the first time. Same if there is a new key pair, they sign it with the old one too, so you can trust the new one equally as the old. Well, you can trust it as much as you trust the owner to not have shared it or been hacked, bribed, or arrested.

Dark.fail tries to be someone you can trust. If you did trust them, you could trust all the addresses on their site, and thereby the public keys listed on those sites to be trustworthy as well. Dark.fail gives their seal of approval that everything belongs to whom it should on their site.

Their tool is just checking to make sure the keys match up correctly.

You cannot trust Dark.fail's seal of approval. They have proven you cannot trust them. Do not visit their site anymore. You always need to verify for yourself. Learn how.

[aborsy]

Where do you get the public keys?

Also, depends how the owner of the site protects their public key, and monitors the website.

I wonder if a significant of the links (if not most) are scam or honeypots.

[cqqxo4zV46cp]

I’m sorry (kind of), but this comment rubs me completely the wrong way. This is at best highly ignorant and at worst misleading. I’m willing to bet the former given how trendy it is now for people that know barely anything about a subject to turn around and teach others about it. You’ve just taken “lookalike domain name phishing exists”, explained it to an audience that almost certainly knows it, but also applied it to .onion domains, which are about the only context in which it’s wayyyy closer to impossible to actually pull this off.

[yieldcrv]

I use daunt.link now

dark.fail has been full of fail for about 3 years straight now. you would think tor is basically dead if you use dark.fail

[ClassyJacket]

How on earth did anyone have the computing power to generate the altered address? Wouldn't that have taken trillions of years? Isn't that the whole point of these long random addresses?

[verisimi]

> Can you spot the alteration?

yes!

5uqd.onion

vs

6uqd.onion