Topic: [DRAFT] ARS - Advanced Rating System (Read 3525 times)

The rating isn't just for merchants, but both sides. The logo above is a sample for merchant parts who would want to use it.
The hashing part is to prevent ID theft based on comparison.

Precisely... Merchants don't want anonymity, they want rep. Customers may want anonymity, but Bitcoin provides that admirably.

Just as we all display our wallet addresses in the hopes of getting a tip or such for doing good work, a merchant would display his to receive payment. This would be linked, through something like the image/code BCEmporium posted, above, to a database of merchant ratings. Combined with an escrow service, with the escrow holder doing the rating (a simple sucess/fail "voting" system would be sufficient), the system could be made relatively game-proof. Or, at least, more work to game than it would be to simply be honest.

I'm confused as to why you want ratings of a entity to be anonymous? Why bother with the hash part at all?

Perhaps we could use payment addresses, instead?

This does slightly compromise the anonymity aspect, but only for the merchant, who presumably isn't looking for anonymity, anyway.

Adding stuff to this draft, a sample of what can be used as seal of approval (not of this size obviously). The pair Key/URL would be generated and input there using GD.

Would work sort of:

Yes, are valid concerns and I'd them too. That's why secondary human-comprehensible authentication must kick in.

The system itself is meant to be designed to provide full anonymity at will, provide also some local apps Open Source to do the hashing on the user's local machine. Let's say John wants to be rated but doesn't want the site to know he's John, he just grabs one of the hashing apps for his OS, hash himself and register the hashes.

Then he can fill some info/hints he might think useful to whoever is checking; eg. I just use Freenode network. I just use Bitcoin Forum.
Or sign with his private key a «the fox jumps over the lazy dog» text file leaving there his public key.

When a user goes to check his ratings will have all this info available. Say someone on Undernet with the nick John asked Alice to look him up, but John says he just uses Freenode... something is wrong and Alice will not trust "that" John.

Alice can also check entering John or using a local app to do the math and entering the hash. The field for entering the hash must be under a tab Advanced with warnings to not do hash lookups if the user provides nothing but the hash, or so.

EDIT:

Also and obviously the site doesn't make decisions for the user, just intent to provide some "evidence" within web forensics about the ID and Rate of a user. We can also add the last 20 IP's from where the user accessed his rating account from for an instance, obfuscated after pass GeoIP Country. Say;

Last 20 IP's of the user:

25/02/2011 12.xxx.xxx.24 China <---OOOPS! Probably compromised... the user rather come with a good story why he's on China now
24/02/2011 200.xxx.xxx.234 USA
23/02/2011 200.xxx.xxx.123 USA

What if he uses TOR? Well that adds up for the mistrust level.
Bottom line, the site gives the tool not the advice nor closes any deal. Last saying must come from whoever is checking it.

Agree, to a certain extent with this. That said, I use some damn silly usernames from time to time, and the more money is involved the more likely it is that my username will use Base64 or Base95 characters... (it goes without saying that my passwords are always Base95). It's also possible (likely, even) that Mallory will wait until she finds a collision that only involves letters, or is Base32 ("shi93grl" seems like a plausible username, for example).

OK... this may simply be me not understanding your proposal. I thought that your system would do the hashing - the user won't need any tools at all. As I understood it, the user ("Alice") enters the username ("John") into your system, and your system hashes "John" and looks up the hash to return a score?

Right, but if Mallory compromises John's hash, she can then pretend to be John. John's username is obfuscated, but to Bob and Charlie it looks like Mallory could be John. Bob and Charlie both trust Mallory - based on Alice trusting John.

Here's the issue LM;

A guy with a nickname such as XyZ!2£ isn't already trustworthy, because you can't spell it, nor you will be able to remember it. Because who's checking it is human, is not a simple if(pass == H(storedpass)){ printf("OK %s is a good guy",nick); }
Some additional may be added, as something PGP signed or so, which adds sort of business oriented Facebook style to such rating system.

Bottom line however, one thing being good or bad also relies on simplicity and practicality. Come to an user and say, «to compute this hash you require lib-xpto, lib-xpto.so.2, lib-idonnowhat...» it's not a good thing. No matter how much security it may add to the equation, it creates more hassle to be used than the security it provides.

Also the idea of hashes being compromised isn't of concern, again, they're used to obfuscate the real username on a public space, not to authentication by their own. You can even publish and list it... still no issue whatsoever.

If my concern would be the hash to be seen, I would use a non-standard algorithm. XOR a string against a simple OpenSSL key or request or some other random non-pattern/repeated 1000 chars+ string and you got yourself the simplest of unbreakable algorithms, without the key. I intend however to grant that users can input their already hashed string instead of their nickname or email.

In the plot:

you can input John, but if you don't want to broadcast "john" or even let my system know or associate, you can input it already hashed.

My understanding of your original proposal - and apologies if I've misunderstood - is that we avoid using "John". Alice has a good experience with John, so she uses your rating system. This results in a hash, H("John"), and a "score", 1. Bob then wonders if John is trustworthy, enters "John" into the rating system, the system looks up H("John"), and returns "1".

Mallory, who is malicious, can see all the hashes (we don't believe in "security through obscurity", so we have to assume she's able to get at the hashes, either by hacking the database, by bribing the operator, by sniffing network traffic, whatever). Mallory can then attack the hashes at her leisure until she finds a collision. It turns out (hypothetically) that "XyZ!2£" has the same MD5 hash as "John". Mallory then registers at a different Bitcoin site using the username "XyZ!2£".

Charlie then comes along, wonders if "XyZ!2£" is trustworthy, enters "XyZ!2£" into the rating system, the system hashes "XyZ!2£", gets the same hash as H("John"), and returns "1". Charlie - incorrectly - believes that Mallory is trustworthy.

Every hash algorithm is prone to birthday attacks, so the system is always going to vulnerable in the long-term. However, we know that attacks against MD5 exist that are far more efficient that birthday attacks - Mallory can find a collision for "John" far quicker with MD5 than she can with a more-resistant algorithm.

Again, apologies if I've misunderstood your proposed system, but as I understand it it is vulnerable to collision attacks (and I can't think of an easy way to avoid that), so it's essential to use a strong hash algorithm.

Still collision attacks would hardly be an issue, even if MD5 is chosen, for a simple reason; it isn't used for anything computer-related decision but rather to human decision.

One thing would be the scammer to say:

Go check my nick, saying the nick is John, on rating site A
- or -
Go check «something totally fuzzy and impossible to read that renders the same hash as John» on rating site A

Whereas for a computer: John and aiyho23#4072S""u3989hruiohefu9034 can be the very same thing (as it doesn't really understand what either one means), for a person it isn't. (Note: for the example I didn't compute either hashes, I don't know if that string gives out the same hash as John, may check but no need, I guess you can understand what I mean)

No hash is irreversible; every hash algorithm is ultimately vulnerable to birthday attacks ("brute forcing"). The issue here is that MD5 is also vulnerable to far more efficient attacks (under a minute on a notebook, if I remember correctly). That said, I take your point that this is a technical detail that doesn't affect the overall goal.

Edit: didn't mean irreversible, meant no collisions. Oops...!

Sorry, this is going to accessory not to the essential. The essential is to create a way to protect and ensure raters and ratings ID.

If goes by hashing more to the left or more to the right, is a techincal/nerdness issue to be solved during the development itself. For guideline here it has to be a widely available, irreversible and fast algorithm. MD5, RIPE, SHA... doesn't quite matter much.

The issue isn't with brute-forcing or using rainbow tables; rather, the issue is with how resistant the hash is to collision attacks. MD5 was shown seven years ago to be non-collision resistant; RIPE-MD 160 is still regarded as collision resistant. Wikipedia has more details.

MD5 hasn't been "broken", it has been "brute-forced"/attacked by dictionaries and so on. But if I give you a MD5 hash not existing on those "cracking databases" you can't reverse calc it.
Doubling it is like salting a hash in itself. Yes, you come to know the salt is a 32-lower+numerical string, but good luck on decoding that. Possibilities are 35^32 ( 2.57 × 10^49 ) just for decoding the main hash.

But now, this is valid to all hashing, RIPEMD-160 included, none of them is brute-force immune, unless you would use variables binded to the hardwareID or something specific to the machine calculating the main hash; but it would mean that if that computer get broken your data goes with it.
MD5 has just been around for quite sometime, and some "sweet" Russian fellows even put up sites to lookup for hashes in their db, then Rainbow Tables... I'm well aware of that.
Anyway, isn't that "security related" like storing passwords at open air, it's for hide a uname/email. And you need a hashing algorithm easy and fast.


The scammer using a name that he knows to exist isn't the same as the scammer to have a list published somewhere where can even compare ratings and pick up the more suitable for his intentions. My draft isn't the "magical anti-scammer", because there's no such thing, but an attempt to make his life harder.

That doesn't solve it at all. The scammer will just use a name they know exists in the trust system.


Don't use MD5 for anything security-related. It's been broken. Doubling doesn't help much, if at all. If you need a 160-bit hash, use RIPEMD-160.

Open Ratings suffers from the very same issue as general Open Source does; the source isn't only open to "the right people". So it comes that misused they might be more a pro than a con to a potential scammer.
Let's say user ABC has a good rating on #bitcoin-otc, scammer X goes check the ratings and learns it. Goes to another network/forum and grabs the nick ABC, chooses the target and to gain his trust asks him to check "his" rating at #bitcoin-otc.

So my proposal is to avoid open exposure of good/bad rated users. How? By hashing their nicknames.
Instead of show a list like:

Abc +5
Cbe +4
Dec +1
etc...

not show any list at all, but an input field for a user to lookup somebody.

So let's say I want to know the rating of Abc, I enter Abc and the system double md5 it - to prevent md5 reversal/cracking. The system checks then for a user-key (and not a username, because the system itself must not record them) with value of: 2018fe1c88d674e910db7ca3fe77e04f
It may do a strtolower either on registering and searching for avoid case-sensitive username search and can be also used to email addresses; same method, doesn't record the address but its hash.

By displaying data, we need to show to the user who rated him. Somebody received + rating from the same user over and over is more than suspicious. So here we can display a CRC32 of the raters' username hashes.
Why CRC32 and not simply show the hash? Easy, CRC32 is a much smaller checksum, and much easier for visual comparison than MD5.

What do you think of this idea?