+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: hash160(x) a.k.a. ripemd160(sha256(x)) (/thread-6069.html)
hash160(x) a.k.a. ripemd160(sha256(x)) - hashmisch - 11-24-2016
HowTo?
I'm new to hashcat, so forgive my ignorance as I have not yet been able to find out if/how you could combine the raw hashes offered.
Hash Misch
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - royce - 11-24-2016
I'm not sure what you mean by this. Could you rephrase?
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - hashmisch - 11-24-2016
Hmm...
Well - I see hashcat has SHA-256 raw hash and I see hashcat has also the RipeMD160 raw hash.
So my question was if I can somehow combine this to a ripemd160(sha256(x)) and basically for a large list of different x's check for a known result.
Hash Misch
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - royce - 11-24-2016
There is no way to combine hashes that I know of. It would be a very interesting and useful feature, but it might be difficult to implement.
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - hashmisch - 11-25-2016
(11-24-2016, 11:39 PM)royce Wrote: There is no way to combine hashes that I know of.
Oh...
The aforementioned hash160 is part of the Bitcoin (and probably others) address generation process.
I was under the impression hashcat would offer some formalism of how to construct hashes from the "primitives" (raw hashes) it offers. Ideally it could be template given via CLI, like --pipeline "f1(f2(x) . f3(x))" or something like that.
I have no experience with OpenCL, so I cannot estimate how hard this would be to implement, but the combinatorial power of this is beyond doubt - so it might be worth it.
A pitty, I thought hashcat has this already. OK. Thanks for your clarification.
Hash Misch
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - atom - 11-27-2016
Such an implementation wouldn't be hard to write, but slow in execution. But there's no reason to implement a slow solution, because if there's a faster alternative everyone would use the faster alternative.
If you think having a slow solution is better than no solution, then why not write it in you favourite language running on CPU. I think the answer is because it wouldn't run on GPU. So it turns out it's the performance you're looking for. Now you're in a loop my first argument.
A simple way to get out of this loop is by writing a specialized version of your hash. That's what we do in hashcat. Read this: https://hashcat.net/wiki/doku.php?id=frequently_asked_questions#i_want_to_request_some_new_algorithms_or_features_how_can_i_accomplish_this
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - hashmisch - 12-07-2016
(11-27-2016, 02:21 PM)atom Wrote: Such an implementation wouldn't be hard to write, but slow in execution.
...
Now you're in a loop my first argument.
Only if I accepted the claim about slow execution.
In a world, where OpenCL programs are compiled at runtime, I fail to see why an assembled processing pipeline in the source code should be slow in execution.
But never mind, I started to write my specialized code anyway.
Hash Misch
RE: hash160(x) a.k.a. ripemd160(sha256(x)) - atom - 12-09-2016
Cool, please do not forget to contribute afterwards