[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 Sep 2021 18:36:24 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: brute forcing AES key
On 2021-09-10 17:54, p+password@...atpro.net wrote:
> On 04 Sep 2021, at 17:54, Patrick Proniewski <patpro@...pro.net> wrote:
>>
>> On 04 Sep 2021, at 17:27, magnum <john.magnum@...hmail.com> wrote:
>>>
>>> On 2021-09-04 17:19, magnum wrote:
>>>> On 2021-09-03 17:41, p+password@...atpro.net wrote:
>>>>> I have a string, result of encryption by an App.
>>>>> The code for encryption of this App is visible here: <https://github.com/Anubis901/SafeCrypto/blob/main/lib/encryption.dart>
>>>>> It looks to me that the dev of this App is missing something important: he did not use a derivation fonction to create a secret key, he uses the user provided password directly as an encryption key.
>>>>> So I guess it would be feasible to use a password cracker software like JtR to brute force the password / key and decrypt the string I have.
>>>>>
>>>>> Is that possible with JtR, if at all?
>>>> A format for attacking this should be, potentially, very fast. I didn't look a lot into that link you gave but the tricky bit is likely to know when we made a correct guess. It goes like this: Try a candidate, decrypt some ciphertext, verify against some known plaintext (or plaintext-ish). If it's correct, we guessed the correct password.
>>>> So, if we can identify some plaintext (such as a file magic) or plaintext-ish (such as json or xml and/or 100% UTF-8 or ASCII) we can hopefully write a format for this.
>>>
>>> Oh and another possibility which is used in many formats is *if* that software use a padding scheme for the very last block that we can use either solely (if it turns out a correct hit *always* have at least, say, 6 bytes of padding) or at least as an early reject.
>>
>>
>> No padding in the input string. It's a cryptocurrency private key.
>> What I know is the input is probably a 64 characters long hex string, something like this, for example: "09e910621c2e908e9f7f6ffcd7024f54ec1461fa6e86a4b545e9f1fe21c28866". And maybe, it's prefixed with "0x" but I can't know for sure.
>>
>> In the mean time I've tested the encryption code of this app and discovered the IV is always "0000000000000000" (16x0) because the developer used the provided example of code without understanding it. But I guess it's quite irrelevant here as I have only one output sample to work on.
>
>
> Any idea how to write a format for that?
I told you how ;-)
But if you post a couple of sample vaults and the passwords for them,
I'll have a look at it sooner or later. One vault should be empty (just
create it, don't add any wallet) and one should be populated with some
mockup data.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
