Hi Arno,
I use a NVIDIA Nano, this device is comparable to Raspberry, but it has
128 CUDA cores on it. Hashcat uses those CUDA cores. I know that is not
much mostly all modern graphics boards to have much more that 128 cores,
it was only a project for me, the data on the device is no longer import
to me. Hashcat in running and has calculated, the process to take around
30 days. I know a part of my password. I ran a benchmark before I
started the process, unfortunately I don't noted down the numbers.
Even if the data plays no major role for me, it itches my fingers.
Perhaps I should rent better hardware at AWS or something else.
Best Regards,
Volker
On 2/18/21 10:49 AM, Arno Wagner wrote:
Hi Volker,
when you get this running, could you post some performance
numbers and what hardware you use? It is the old LUKS with
PBKDF2, but would still be interesting.
Regards,
Arno
On Wed, Feb 17, 2021 at 21:27:50 CET, Milan Broz wrote:
On 17/02/2021 21:14, Volker Dormeyer wrote:
Hi Milan,
thank you for your explanation. See, my comments below.
On 2/17/21 8:09 PM, Milan Broz wrote:
On 17/02/2021 19:12, Volker Dormeyer wrote:
Hi all,
I have a question. I have a detached header for a drive I created years
ago, where I lost the password for. So, I plan to find the password with
a brute-force attack. For this I have to attached the header again. I
thought, this would result in problems - and it did. I build for testing
purposes the whole situation in a VM. It seems I have to align the data
offset somehow.
Why do you want to attach it to device for brute-force check?
Header should be enough to run it.
Hashcat for example requires a bit more then simply the header. If you
are interrested, you can read it here:
https://hashcat.net/forum/thread-6225.html
I proof it, it does not work by feeding it with the header file alone.
Ah, ok, if it uses known signature from the decrypted data disk to
check for the correct key, then yes, you need data there.
(And yes, it IS the correct way how to speed up brute-force, LUKS header key
digest is intentionally slow to exactly not allow easy brute-force just
with the header.)
You can use cryptsetup for it:
cryptsetup luksHeaderRestore <data device> --header-backup-file <luks header>
Or did I miss anything here?
It does work in my VM. I never thougth it would be that simple. That is
the base to start my real brute-force work.
Why it should be more complicated than needed? :-)
It is simple, unless you are using some non-standard parameters.
(But even then it is quite easy to manually hack it.)
Thanks,
Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
