[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F77D8186-21BA-4681-A14F-758EE354EF9B@patpro.net>
Date: Sat, 4 Sep 2021 17:54:43 +0200
From: Patrick Proniewski <patpro@...pro.net>
To: john-users@...ts.openwall.com
Subject: Re: brute forcing AES key
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.
thanks,
patpro
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.
