Re: [dm-crypt] How to attached a detached header?

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
>> [email protected]
>> https://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt