Cryptohaze.com

My previous message seems to have been erased so I repost.

Hello,
I wanted to first congratulate you on your project which I attach great importance. Indeed the contribution of the GPU for this type of task seems to be really vital.

I would now like to submit a question, Cryptohaze is it in beta?

We tried for days to make a table MD5 FullCharset 6-6 which would have a success rate of 100% success ...

Different combinations have been tested on a wordlist generated for the occasion.

This generator allows us just to check the efficiency of the algorithm used.

Hashes in 1000 we have not been able to crack more than 700 hash whatever the method used for any type of table / configuration tested.

The system was used backtrack R1 & R2 64bit.

After discusion on forums and some specialist this feature does not seem to be an isolated case ...

Maybe we have not properly configured the software.

This brings us then to ask if it would be possible to have an example to generate an MD5 Fullcharset table 6-6 that would have a 100% success ratio

cordially

vances1

Can I get some details on what you ended up creating? If this forum is not suitable, you can email me at <[email protected]> to discuss.

If you created a single, perfect table, you will likely see what you're seeing. Rainbow tables are probabilistic, and you generally won't see beyond about 70% on a single table. This is why most sets have multiple tables with different index values (-i parameter). With 3 or 4 large tables, you do get crack rates in the mid to upper 99% range.

The tools are not in beta, but are subject to the general limitations of rainbow tables.

It is possible to build a "perfect set" for a rainbow table that will crack 100% of passwords, but it involves additional data with the tables, and I do not (yet) have this developed. I plan to add it at some point, but I have a lot of other development tasks going on right now. If it's a significant priority, I would be happy to discuss prioritizing it.

Thank you for taking the time Bitweasil answer, at first I was afraid to create some discomfort or it is misunderstood.
I do not know if the forum is suitable or not will be at your discretion.

That type of thing that has always been tried for a length of 6 (GTX580/GTX460):

numchains = 46750000
-chainlength of 5000, 10 000, 20 000 to 2 000 000 on a table.
-same setting by multiplying the tables 1 to 10.

Creation of table length 5000/1 table + 5000/2 table + 5000/3 ..... in the mergant at the end.

Various test on the quantity of bits for use with GRTIndex. Not knowing exactly how much to allocate, we are left on the basis of 32 bit. A default to be optimal for disk space, no key could be rejected.
I probably forgot a lot but approximately ~ 50 tables had to be created with 650 to 740 crack succeeded. It did not negligible but if we seek the best side they have to be 100%
I'm just being tested now-i option which I believe I also tried ...

Would it be delicate or even impossible to ensure that GRTGen-cuda can create a Rainbow Table in logical sequence to the style of a pure bruteforce?

Another thing I wanted to share. We integrate Cryptohaze in a version of Backtrack 5 R2 Custom Special cuda available here:

http://www.crack-wifi.com/forum/topic-7 ... -Cuda.html

We make a lot of hope for your work and have your site cryptohaze.com linker directly before promoting somehow, now we can remove it upon request.

I do not lie to you telling you that you have to gain directly, but it is possible to improve the knowledge Cryptohaze.

The point I put into evidence (RT 100%) could be one of the things that slows down your expansion

Cordially vances1


EDIT

I look How is the order via the webtable. If I understand the tables (4 here) are executed sequenciellement. This is a technical constraint? there is there no way to create an index for several small table? or the merged them?.

Another thing, if any is there possibility to shorten the commands in this way * .6 to select all table six?

As you can see I am very interrested and my way of looking at it, is more oriented "user"

vances1 wrote:Thank you for taking the time Bitweasil answer, at first I was afraid to create some discomfort or it is misunderstood.
I do not know if the forum is suitable or not will be at your discretion.

If you're happy discussing it on the forum, I'm happy with discussing it on the forum!

I *think* the fundamental issue is that you are attempting to generate one table - not 3 or 4, as is suggested.

I'm just being tested now-i option which I believe I also tried ...

If you are creating all the tables with the same index, you will only generate "one table" effectively, and this will give the results you see.

Would it be delicate or even impossible to ensure that GRTGen-cuda can create a Rainbow Table in logical sequence to the style of a pure bruteforce?

Actually, yes. It is impossible to generate a rainbow table in a logical sequence identical to a brute force due to the nature of the tables. They are not simple "hash=pass" tables - they are much more complicated. There are ways to generate 100% tables which I wish to investigate, but I am limited in time and they are rather complex to write.

Another thing I wanted to share. We integrate Cryptohaze in a version of Backtrack 5 R2 Custom Special cuda available here:

http://www.crack-wifi.com/forum/topic-7 ... -Cuda.html

We make a lot of hope for your work and have your site cryptohaze.com linker directly before promoting somehow, now we can remove it upon request.

I'm happy with the tools being included and the site linked. I would generally like to know if my tools are being included in a distribution, but as they are open source GPLv2, I am happy that they are being used!

The point I put into evidence (RT 100%) could be one of the things that slows down your expansion

I cannot easily do 100%, but I can do upper 99%, which is much better than the 60-70% you are seeing now.

I will provide a writeup on how I generate length 6 tables soon - hopefully in the next few days.

However, to prove that my tools are capable of doing this, I invite you to use the free WebTables server I have up. This accesses rainbow tables remotely over the web, and has a set of MD5 length 6 tables I have generated up on it. I am planning to add more tables to the WebTables server with a subscription model, and if you are actively distributing my tools, I may wish to set this up sooner rather than later - it allows access to rainbow tables without having to download them!

To test using it, use GRTCrack as follows:

./GRTCrack-CUDA -h MD5 -f [md5 input file] -o [cracked output file] --tableurl=http://freetables.cryptohaze.com/webtables.php MD5-len6-idx0-chr95-cl50000-v2-perfect.grt MD5-len6-idx100000-chr95-cl50000-v2-perfect.grt MD5-len6-idx200000-chr95-cl50000-v2-perfect.grt MD5-len6-idx300000-chr95-cl50000-v2-perfect.grt

You may see significant slowdowns if you use 1000 hashes, but it will eventually complete. This is due to where I am hosting the server, and I will be fixing this soon.

Please try that command with your input and output file. You should achieve 950-990+ hashes cracked using those tables.

I can provide them for download as well later if you are interested - they are roughly 1GB total. I do not have direct access to that server from my current location.

It is a pleasure to discover a good tool and I am pleased that suit you too

The command you gave me is under execution

995/1000 ...

http://pastebin.com/eAyuW1RB

I just understand what you were talking about when speaking of a single table which m'à lead to reflection following ...

I tried to meditate on the way in which was generate / execute the tables.

Currently it can be difficult to generate / execute tables from 8 due to lack of ram graphics, or because of that string is too long.
Would it be unthinkable that the graphics card once completely filled, the discharge current work on the hard drive before continuing to generate and so on?
This would make big table with a fixed chain lengths'm the final size.

As for later use. Seen that the RT are indexed, the gpu would only have to go pick the segments that are interested in and treat them ram, is it a dream? ^ ^
This could offer much prospect for the future and probably gains at all levels (indexing, effectiveness, number of control ...), maybe not for each section but the total amount ...

Now I am not a programmer and if it is easy to run quick suggestion, it should not be the same for the one who works on the engine

I admit I see a strong penchant for high performance

EDIT

I look How is the order via the webtable. If I understand the tables (4 here) are executed sequenciellement. This is a technical constraint? there is there no way to create an index for several small table? or the merged them?.

Another thing, if any is there possibility to shorten the commands in this way *.6 to select all table six?

As you can see I am very interrested and my way of looking at it, is more oriented "user"

Now I realize that what I say may sound disrespectful towards the work already carried out ... I will wait your reply instead of throwing the thing in the wind that are surely am infesable, be asking too big code changes

vances1 wrote:The command you gave me is under execution

995/1000 ...

That's a bit more what you were expecting, yes?

Would it be unthinkable that the graphics card once completely filled, the discharge current work on the hard drive before continuing to generate and so on?
This would make big table with a fixed chain lengths'm the final size.

This is how the tools are designed to work... the documentation is poor because I mostly generate parts myself. But the idea is to generate a bunch of "table parts" on the GPU, flushing to disk after each part.

You then use the GRTMerge tool to merge them all together into one large table, create the index needed, and use them.

As for later use. Seen that the RT are indexed, the gpu would only have to go pick the segments that are interested in and treat them ram, is it a dream? ^ ^
This could offer much prospect for the future and probably gains at all levels (indexing, effectiveness, number of control ...), maybe not for each section but the total amount ...

Yes, this is done. When reading the tables off the disk for cracking, the index is used to only read the sections needed. This is how I deal with 300-400GB table files quickly.

I look How is the order via the webtable. If I understand the tables (4 here) are executed sequenciellement. This is a technical constraint? there is there no way to create an index for several small table? or the merged them?.

Another thing, if any is there possibility to shorten the commands in this way *.6 to select all table six?

As you can see I am very interrested and my way of looking at it, is more oriented "user"

The 4 tables are executed sequentially, yes. The reason is that they have different table index values (the -i param, or the idx* field in the filename). By using the separate tables like this, we get the 99.5% crack rate you are seeing. One table cannot do this alone. It is just not possible with rainbow tables. You are required to have multiple tables with different reduction functions (the -i param modifies the reduction function). However, it only runs the not-yet-found hashes on subsequent tables, so the later tables are faster.

I am planning to improve the interface for WebTables. The current version is mostly a proof of concept, and it will be enhanced before it is fully production ready. The current version and interface is mostly set up so that I can test things and prove that the WebTables concept works (which, as you can see, it works very well).

I need to create a sample for how to generate tables. I will try to put this on the wiki in the next few days. It will walk through generating length 6 tables, demonstrating how to use the tools to generate the parts, merge the parts, create the indexes needed, and use the tables.

Thank you very much for your time you spend

I think understand now ...

Something still seems fuzzy but I imagine you will discuss during the last days of the wiki

This option:

- numchain should she not used correctly offer the 100% rate on anywhere chain length?

for example

Length of 6, 50 000 chain length, chain count 46750000, on table 3 (numchain = 3) should offer 100%.

But obviously it is better to make 4 indexed differently ... it is this subtlety that remains obscure

vances1 wrote:Length of 6, 50 000 chain length, chain count 46750000, on table 3 (numchain = 3) should offer 100%.

But obviously it is better to make 4 indexed differently ... it is this subtlety that remains obscure

That is a general issue with rainbow tables as probabilistic tables and not deterministic hash/pass lookup sets. It's just the way they are. You can't get beyond about a 70% hit rate per table which is why you need multiple.

Ok I will meditate on that

Going back to your question, yes with 99.5% success it becomes even more interesting. I guess it is this type of result qu'attende people who come to use GRTGen silon because they must fall back on preferre Cryptohaze multiforcer

I am indeed interested in the history of deposit (side table) and I also think that this idea proves to be as revolutionary.

This reminds m'à a kind of streaming ....

Only good thing to come into perspective and of course we will closely monitor your new tool and integrate them with each new version, if you let us always

ps:

I have not managed to run a command in the same style of your but in local (to run multiple table):

./GRTCrack-CUDA -h MD5 -f [md5 input file] -o [cracked output file] MD5-len6-idx0-chr95-cl50000-v2-perfect.grt MD5-len6-idx100000-chr95-cl50000-v2-perfect.grt MD5-len6-idx200000-chr95-cl50000-v2-perfect.grt MD5-len6-idx300000-chr95-cl50000-v2-perfect.grt

EDIT

I confirm, after generating the perfect table full 7, idx0, idx100000, idx200000 ... GRTCrack does not seem to launch multiple tables in one command

It should... you may need to give it the full path to the table instead of just the table name. But I launch multiple tables all the time.

How big are your len7 tables? I'm not sure you've built properly large ones...

I will work on a tutorial and wiki page today & this weekend. I have some time.