(04-20-2021, 10:47 AM)philsmd Wrote: Well, the full algorithm (I just researched this a little bit) is PBKDF2-HMAC-SHA256 + AES256-CCM .
Your example with an intermediary key (the key generated by the PBKDF2-HMAC-SHA256 key derivation) isn't very usual (I'm talking about https://github.com/7763sea/hashcat-ripple-cversion). This user seems to somehow got hold of the key that is normally generated on-the-fly and is not the actual "result" (e.g. the encrypted or decrypted data), but as I said just a key generated from the password that still needs to be used to decrypt the data. (the user probably got hold of this key somehow and now tries to recover the password, but even this doesn't make sense most of the time: whenever you have the PBKDF2 key you can just decrypt the data and you are done... it only makes sense to recover the password if you really need to KNOW the password for instance for forensic reason i.e. "we now have this users password and they might have reused this elsewhere").
The algorithm itself is similar to what I've research already here: https://github.com/hashcat/hashcat/issue...-712962171
It also uses this SJCL way (JSON and base64 encoded etc) of describing the algorithm details (key size, tag length, AES mode, etc etc etc).
Here again the code, similar to the github issue above, but modified to work with your examples.
[/code]
As you can see it's very similar to the SJCL hashcat github issue, the only major difference is that the password consist of the length of the password + "|" + the password (length ($pass) . "|" . $pass). This is a crucial difference (because it kind of changes the final password length), but it's a trivial change to make it work in perl/python (probably not so easy if you need to do this in OpenCL/CUDA, but still doable, because of the slow PBKDF2 algorithm which makes any such password length changes or similar a NOP, no-op, i.e. negligible).
It seems your example all have 1000 iterations, which isn't too much, but of course still makes it much slower than other (fast) hashcat modes.
This mode wouldn't be impossible to implement, but it would be interesting to discuss if we should rather implement the more generalized SJCL support... the problem with that approach is that (for your particular/special case !) you would need to create and provide to hashcat a new dict that already has the password length prepended to the password (not easy to do with rules ! except if you just prepend every length, but that would be quite a waste for a slow algorithm using PBKDF2).
As always, I would recommend to think a little bit more about if such an implementation would make sense in terms of feasibility: how much does the user know about the password, charset, length etc ? how many password candidates do they need/want to test ? How sure are they about the password pattern etc... because there could be 2 cases in which an implementation wouldn't make much sense: 1. the password candidates the user wants to try are just a few thousands which can easily be run with perl/python/nodejs etc, 2. the user doesn't have much clue about the password and the password is quite long and random (probably infeasible to crack).
So my recommendation is to read the above paragraphs and algo details carefully and try to understand if an implementation really would make sense for your specific case (it's needless to say, that this algo is not yet implemented, but it's not completely impossible to implement it with the help and similar to the aes_ccm_decrypt_tag () decryption function from above).
Good luck. thx
first , thank you for taking a look at it .
i have read your github comment and i tend to some what agree
most of the crypto holders are normal people that have no clue about hash cracking or password recovering or even crypto itself ^,^ .
also they are mostly not young folks , i've heard countless time of people that forgot their passwords for their wallet , this happen mostly because some one told them to put a really strong password , since those password are not their typical password they are tend to be forgot fun fact is if your not using the password daily or some what regularly the human brain will make it disappear unless you saved/wrote the password somewhere which tend to be lost aswell
now to the problem ,
if you noticed , in this github https://github.com/edward852/xrp-wallet-recovery the password is unknow and the length of the password is unknow .
i have sat with my friend and tried to go deep with what he remember and what type of password he used what it could be , he had a certain patern of a password.
i have tried to play with it with passowrds that he might remember so ive run around 500k password on a laptop cpu
, but that was tedious to change the config file each time to make all the small changes run it over and over to mimic a mask attack .it was not near as fast , or easy or intuitive as hashcat .
in my case (the case of the friend wallet) , the user know some what , what the password could be and more or less the patern however as explained before i did try to run multiple hundred of thousand passwords over all without any success .
i think that would've been a different story to run it in hashcat with a gpu or even cpu .
if you ask me if hashcat dev team should implement it my answer would be yes , abit hypocrite of me i know ^,^ because i try to help my friend
but if you look at it , i am sure they are lots of more or less cases with the same problem , hashcat do support some couple of wallet types such as electrum , bitcoin, blockchain..
if you ask me if this should be as top priority , the answer is no , i am sure you guys have alot on your plate and have far more usefull algorithm to implement , yet i think implementing soon this type of wallet would be a good idea .
also funny story and fun fact is , even if you have the right password for your wallet the desktop software will deny it
and tells you its a wrong password when its not ! , i know that because when i tried to check if the nodejs code on github works i created a wallet with a simple password , closed and reopen the ripple desktop wallet , put the right password and it didn't work i did that 3 times just to make sure i wasn't dreaming or anything . the nodejs code did work
, it recovery the password , and the private key/master key of the wallet .anywho thats my take on it.
i do wish to see it in hashcat soon tho .
i am sure alot of people needs it (also because their freaking software does not work or available anymore , so even if its the right password the software will say its wrong .)
and no my friend is not a millioners from what he remembers he think he has now 3~k$ , he dont even know what his public address xD