[C++] Another Hashing Method. Ugh, I know.

[Joe]

Code: [Select]

/*
 * This
 * is
 * an
 * incredibly
 * ambiguous
 * comment
 */

/*
 * C++ Hashing Method
 * Author: Joe LaFrance
 */

#include <iostream>
using namespace std;

unsigned long hashdata(string);

int main(int argc, char *argv[]) {
  if(argc == 1) {
    cout << "Error: No data to be hashed." << endl;
  } else {
    string toHash;
    for(int i = 0; i < argc - 1; i++) {
      toHash = toHash + argv[i+1] + " ";
    }
    cout << hex << "0x" << hashdata(toHash) << endl;
  }
  return EXIT_SUCCESS;
}

unsigned long hashdata(string passed) {
  unsigned long ret = 0x12345678;
  string hashcode = "\x56\x24";
  for(int i = 1; i < passed.size(); i++) {
    ret = ret * passed[i];
    ret = ret * passed[i-1];
    ret = ret ^ hashcode[i % 2];
  }
  ret = ret * (passed.size() ^ hashcode[0]);
  ret = ret ^ hashcode[1];
  return ret;
}
Problems:
- Hashcodes aren't very diverse. Change them if you feel the need.
- There's an incredibly ambiguous comment and I can't quite figure it out.
- It's not xor'd the last time. More specificially, its xored by 00000000b, because anything * 0 = 0, and the i+1 = NULL.
- It passes an extra 0x20 to the end of the string. You'll live.
- Incredibly unrandom.

Another thing, where does this go now? General programming? Network security (here)? General security? Trash can (<3 newby)?

Anyone see any security vulnerabilities?

PS: If anyone cares (I know you don't, but still) why I used a long, its so this could easily be cast to a DWORD and sent over a network. =)

EDIT -
Bugfix: Fixed a last second modification (which killed it) where I passed both a variable and a const char[2] to the + operator. Ugh, VB allows it. =)
Added: Outputs in hex.

EDIT -
joe@JoeMomma:~/dev/cpp/hash $ ./hash.o SMILE FOR THE POST.
0xb7e360fc

EDIT -
I found a SERIOUS security exploit in this. The data to be hashed isn't passed. It's always the same. Damn C++.
Warrior's methods of passing arrays suck. =p

[Newby]

Uhh.... isn't hashed data supposed to be unreturnable?

[iago]

Some problems:
- Newlines, tabs, spaces, and any other whitespace will hash the same. That can introduce collisions.
- Multiple spaces beside each other won't affect it.  So that's another way to introduct a collision. 
- Your ending data is only 4 bytes, so it's extremely easy to bruteforce the entire keyspace.  2³² possibilities, at say 15000 tries/second (not unrealistic, especially with such a simple algorithm), means you can force a collision in about 3 days.  That makes it useless for verification. 
- It's being xor'd by predictable values, so the xor'ing is completely useless.
- If it's a short string (so it doesn't overflow), you could probably get the original string back by finding out which letter evenly divides into the resulting number.  You could easily work backwards like that. 
- The last characters in the string have more effect than the first characters.
- NULL characters or \x01 characters won't hash properly, so ths is pretty useless for hashing binary data. 

Why do you try to invent your own hashing/encryption algorithms, anyway?  You realize that the current ones used were derived by mathematical geniuses, and tested for a significant amount of time with every known attack before becoming a standard?  I'm pretty sure you don't know a lot about math, or about cryptographic theory, so there really isn't a point in trying to invent your own.  Why don't you find the outline of the SHA1 or MD5 (or even MD2) standard and try to implement that on your own?  One of our assignments in school was to implement MD2.

Oh, and by the way, .o is for object files, not for the final output.  If you really feel like you need an extension, use .bin or .out. But you shouldn't need an extnesion at all. 

[Warrior]

Warrior's methods of passing arrays suck. =p

You suck at implementing it.

[Sidoh]

Maybe it's a little of both!

[Warrior]

Or maybe he sucks at implementing it.

[Sidoh]

Or maybe he sucks at implementing it.

I doubt it!

[Warrior]

It's Joe.

[iago]

Arrays should never be passed as parameters.  Pointers to arrays can be, but actual arrays shouldn't be.

[Warrior]

Don't look at me. I didn't suggest that.

[Sidoh]

But you implied that!

Buahaha, I love being a bastard.

[Warrior]

You're misinterpretation, not my fault.

[Sidoh]

You're misinterpretation, not my fault.

Your **!

It was a joke anyway, silly goose.  ^_^

[Warrior]

's what I get for typing when I am tired. Speaking of tired, going to bed.

[RoMi]

iago what grade would you give joe's code?

[Joe]

The only reason I try to create methods of my own are just for the experience. I learned quite a few things by doing this (about C++).

[iago]

I just noticed, in a string with a length divisible by 4, the xor'ing will cancel itself out. 

Sidoh -- It depends on what the assignment was.  I usually mark the code itself, which would do well (except for the fact that he's using a string where a char[] would do .  The actual algorithm is rather flawed. 

And Joe -- there's better ways to learn, but as long as you're having fun, oh well

[Joe]

A little laugh for you all, Warrior had me looping through argv using WHILE, so I didn't know the UBound. I just waited for it to be null.

Code: [Select]

string toHash;
int i = 1;
while(argv[i] != NULL) {
  toHash =+ argv[i];
}
When argc holds the UBound.

Code: [Select]

char ignorantProgramming[] = "Lots of headache\x0";

[Warrior]

That was of course assuming you had tried the previous (more practical) methods and failed.

Also nice job not incrementing 'i', retard.

[iago]

A little laugh for you all, Warrior had me looping through argv using WHILE, so I didn't know the UBound. I just waited for it to be null.

Code: [Select]

string toHash;
int i = 1;
while(argv[i] != NULL) {
  toHash =+ argv[i];
}
When argc holds the UBound.

Code: [Select]

char ignorantProgramming[] = "Lots of headache\x0";

You don't need a \x0 at the end of a string.  " and " imply that the string ends with a \0.

[Sidoh]

RoMi asked that, not me.  Silly.