Cryptohaze.com

A single ':' is easy enough to split on with limit 1...

I'll see about making the delimiter adjustable, though. For all you weird people.

whatever you do just make it different from now

hash:password it is!

I've added sha1 support using Vampyr's SHA1 code from governmentsecurity (not his charset stepping code - *cringe* - but his SHA1 implementation).

I need to run it through my validation scripts later today to ensure everything is working properly. If that's the case (and I expect it to be), then I'll be releasing 0.7 today for Windows/Linux/Mac.

Notable new features:
- Per-position character set support
- FAR better multi-hash performance on both small & large lists, no upper limit on hash count except GPU memory
- FAST[hash] modes - the better multi-hash performance optimizations really hurt performance on small hash lists, so for shorter lists, I have a faster version. This also works well with short kernel invocation lengths (to not muck up the GUI), whereas the larger multihash mode doesn't do so hot there.
- Changed output file format to [hashtype]:[hash]:[password] for easier parsing. I'm keeping the [hashtype] entry, it's easy enough to trim off if needed.
- SHA1 support
- Code is still hideous, but I'll probably release it for those who are curious.

I think the next step is to refactor it to C++, as this is a problem set well suited to objects (not on the GPU, but for host code organization) - have a few base classes that can be expanded as needed, and it will clean up the code dramatically, as well as help make adding new hash types a LOT easier.

WOW!
going open source is a huge step and i hope for some positive results

Ran into a few snags, but I think it's working now.

It's 0115 local, so I'll do the compilation & release tomorrow when I'm awake. I need to confirm that everything works on different platforms, and rewrite my documentation (I think I may go to a wiki for documentation, it will be easier to keep updated).

The code... is ugly. Really, really ugly. I can clean it up a lot, so I may work on that tomorrow. I'd like to get it into C++ form before I release it, but I'll probably package up the C for those who are curious. I can't make any promises about it being able to be compiled, though - I suspect it's tuned to my local environment in some ways.

And more snags, like "32-bit fails miserably and doesn't actually do any work for some of the kernels" - I normally develop on a 64-bit system, and something's gone horribly wrong in the conversion to 32-bit Windows code. The big multi-hash functions work, but the faster ones for short kernel execution times and/or small numbers of hashes don't work.

Yes, I'm looking into that.

The problem right now is that I have a lot of framework suited to non-salted hashes, and it won't really work with salted hashes.

What I'm planning to do is redo the code in C++ with classes for the host code. The device code will still be straight C/CUDA, but the host code will be C++, and all the per-hash stuff (loading the hash files, outputting found hashes, etc) will be contained within the class for a hash type. This way, the framework can call the same methods/functions for each class, and it will be able to handle salted hashes/multi-pass hashes/etc without difficulty.

This will also making adding new hash types substantially easier. Instead of having to force the framework to do things it's not currently designed to, it will just involve making a new class with the needed functions, the new CUDA functions, and adding it in. This should make the project a lot easier to expand - add a class, add a hash type.

I'm also going to get a dedicated Windows dev system online, since it's clear that I should be testing things on the Windows hosts before final release. I have no idea of why things are failing right now. I'll try to resolve them tonight, but I can't make any promises. I may release a reduced version for Windows that just handles large hash lists efficiently - the failure right now is with the "small" kernels that handle low numbers of hashes quickly.

i like your plans... and tnx for the heads up, i think many that follow your development appreciate it

where is the source. i am interested.

while porting to c++ you can also port your kernels, cause nvcc supports
much of c++. classes, objects, templates, namespaces, up to recursive templates and simple metaprograms.
it is based on a gcc-3.x frontend.

I'd like to release working source, at least...

There's really nothing within the kernels that needs c++, and given how sensitive the code is to memory alignment, I'd prefer to retain the C-level control over all that. Also, more importantly, nVidia doesn't officially support C++ in the kernels - their stance is "It might work. And if it does, and we break it with a future release of CUDA, too bad."

It's mostly just the organization that needs the objects. There are so many different hash types that it's easier to have them encapsulated.

I will likely provide some default classes, though - so if one is doing unsalted hashes, you may not need to extend the base class much, as it will already have a usable function for reading hashes, outputting results, etc.