04-27-2021, 06:47 PM
I have some good news for you kiara... I've just managed to have a further glance at this algorithm and tried to completely implement the whole module/kernel/tests/extractor with this hashcat testing branch:
repo: https://github.com/philsmd/hashcat/tree/..._hash_algo
commit: https://github.com/philsmd/hashcat/commit/576b277
of course this is still very early code and we could think about some optimizations or checks/restrictions of the input etc etc etc
I've decided to create tools/rippex2hashcat.py for the wallet to hash conversion (the format is $rippex$*iter*salt*iv*ciphertext)
While developing the kernel code I've also noticed that there could be a theoretical reason to worry about collisions (the final check, AES-CCM tag, only has 8 bytes, 64 bits), but with 1000 iterations of PBKDF2-HMAC-SHA256 it's not "too bad" (but remember even a "md5" hash consists of 16 bytes). we might need to think about adding a --keep-guessing warning, or also check the plaintext for a low enough entropy/randomness.
it's needless to say that the hash number/selection -m 27100 might change in the future, it ("27100") is just one of the currently free / next hash modes available.
Please test everything, including the conversion tool rippex2hashcat.py (I have no wallet software or wallet files, I just assumed that the files just contain the base64 string, as the eyJp...example above)
Hope this helps and if it's working perfectly fine of course we shouldn't hesitate to open a github issue/pull request on the main hashcat repo
Thx
repo: https://github.com/philsmd/hashcat/tree/..._hash_algo
commit: https://github.com/philsmd/hashcat/commit/576b277
of course this is still very early code and we could think about some optimizations or checks/restrictions of the input etc etc etc
I've decided to create tools/rippex2hashcat.py for the wallet to hash conversion (the format is $rippex$*iter*salt*iv*ciphertext)
While developing the kernel code I've also noticed that there could be a theoretical reason to worry about collisions (the final check, AES-CCM tag, only has 8 bytes, 64 bits), but with 1000 iterations of PBKDF2-HMAC-SHA256 it's not "too bad" (but remember even a "md5" hash consists of 16 bytes). we might need to think about adding a --keep-guessing warning, or also check the plaintext for a low enough entropy/randomness.
it's needless to say that the hash number/selection -m 27100 might change in the future, it ("27100") is just one of the currently free / next hash modes available.
Please test everything, including the conversion tool rippex2hashcat.py (I have no wallet software or wallet files, I just assumed that the files just contain the base64 string, as the eyJp...example above)
Hope this helps and if it's working perfectly fine of course we shouldn't hesitate to open a github issue/pull request on the main hashcat repo
Thx