+55 minutes in Generating Dictionary for 194GB

[philsmd]

You basically already answered your own question by explaining the algorithm details and linking to the algorithm description.

Furthermore, this question was already recently addressed within this forum: see https://hashcat.net/forum/thread-7218-po...l#pid38829

In short, encseed just means encrypted seed. It is the encrypted seed. just the encrypted seed, nothing else. There is no (private) key present in encseed directly... but the private key can be determined from the seed.

The pre-sale algorithm was designed that you need the encrypted seed to verify that the password is correct. You need to decrypt it with AES-128-CBC. The decryption key for the AES-128-CBC decryption of the encrypted seed (encseed) is directly determined by the user password (the password is used as $pass and $salt parameter to pbkdf2-hmac-sha256, 2000 iterations).
Therefore, the decryption key to convert encseed to seed is directly determined by the password.

The main problem now is that by having decrypted the encseed correctly to the (raw) seed, this also indirectly reveals the private and public key because the pre-sale algorithm generates the private key also directly from the seed (the raw seed, which as we saw above can only be determined with the correct password and the correct encseed) by applying the hashing algorithm keccak to it.
It is also not possible to use just parts of the encseed or something like this, because you need to apply a hashing function (keccak) to the decrypted data (to the seed + "\x02" if you verify that the password is correct by testing against the bkp "hash value"). Furthermore, the decryption algorithm is AES-128-CBC where each 16 byte block is important and the result of the previous block is mixed into the next block (see https://en.wikipedia.org/wiki/Block_ciph...ning_(CBC) ). If something like AES-128-ECB was being used (which is NOT the case), you could maybe just reveal/use the last 16 bytes of the encseed to try to come up with the correct padding (if PKCS padding was used like it is the case with the pre-sale algorithm). This padding-attack could also lead to other problems, like a lot of false positives.

Unfortunately, the block cipher mode is CBC and you need to decrypt the whole encseed to determine the padding and to hash it into the bkp (to be able to verify that the password is the correct one). This decrypted data (the seed) can be directly used to generate the private key.

Yeah, it is unfortunate how this algorithm is designed... you need to reveal the important data to verify the password, but this important data (in it's decrypted form) can also be used to generate the private key (and public key of course).

There is no way to test a password without the encseed and there is no way to not reveal (hide) the ethereum private key if you/someone has the decrypted data (the decrypted "encrypted seed" aka the seed)

[dindolo1979]

@Philsmd (as always) Thank You !!

I was aware that was not possible, but sometimes due I am a newbie, I need to have encouragement from whom is better than me in that field; so once again thank you.

I kindly ask to share my point of view that is not pretty much technical but I like (a lot) to talk and share with people that have a smart attitude in analyze context, semantic and meanings of this.

So please apologize if I slightly got a little bit outside technical aspects.

I have received a consultancy by which was asked to me to send just the first 80 bytes of the encseed because through that way their cracking system would be able to find the password but not able to move funds of the wallet due the lack of the entire seed. From my point of view I have two kind of analysis.

Social Analysis
1) The consultant is trying to start to gain information little-by-little for steal to me the entire encseed, the passwords and then he will take the whole wallet.
1) He will not be able to take more informations than I'll give him after 80 bytes and also with only 80 bytes he can not retrive the whole encseed, so would be a huge waste of time

2) He is aware of a method (unknown?) by which he can crack the password and then he trusts me that once he give me back the password I'll pay his fee
2) Ok, he has a unknown method for password cracking...and it is can be for sure. The good news is that the point relies only to me (and obviously I pay!)

So taking in consideration the point 1 and 2, logically I would have no reason to give him 80 bytes of the encseed.
Do you agree or my logic is completely wrong or (better) there are logical flaws in it that I can patch ?

Always thank you in advance.

[undeath]

unless there is a different way to check if the seed has been successfully decrypted other than the keccak hashing mentioned by philsmd above it's impossible to retrieve the password using the first 80 bytes only.

[philsmd]

The algorithm doesn't allow to recover the whole seed (if it was really generated in a cryptographically secure random way) by just knowing some bytes (let's say 80) of the encrypted seed (furthermore: if one could recover the seed, one could also generate the private key!). The algorithm also does not allow to 100% find the correct password without the whole encseed value, because you need to either have the whole raw seed to compare it with ... or the bkp hash value, which only could be compared with if you have the whole keccak-hash of the whole seed (decrypted encseed) .

Unfortunately, there are so many scammers out there that try to steal data from users and trick non-technical people, especially when it comes to cryptocurrency etc.

If I were in your position, I would at least request that s/he explains the technical details on how such an attack would be possible. We are speaking about hashing when it comes to the bkp value and therefore every single bit would be important, it's not enough to have an input truncated to just 80 bytes (you need each and every bit). Each and every bit does change the final hash value completely. There is no way that a shorter input reveals any data. You need the exact input.

Furthermore, I would request that s/he should proof for free (without *any* costs attached, because this is an easy step that doesn't cost much computation if the recovery which s/he claims to work does really work) that whenever you generate a new random pre-sale encrypted seed (encseed) for which you know the password, that s/he is able to recover the first 80 bytes of the raw seed (and the correct password) by just having 80 bytes of that encseed and the bkp, and a long list of password candidates (one of which is the correct one).

If s/he is able to do this (without additional information about the seed etc) for free and within a very short amount of time, you should come back here and explain what you provided and what s/he recovered and in which amount of time etc.

If s/he instead refuses to explain the technical details and refuses to perform such a test for free s/he is definitely a scammer.

I would not provide real data to anyone before s/he proofed that tests worked successfully... and even after somebody provided such a proof, you should ask several other people with technical and cryptographical background to attest that this "test" was conducted correctly and that the person who claims to have such an "unknown" technique is really able to do it without being able to come up with the private key. I wouldn't trust random/unknown people on the internet and always have somebody that you can 100% trust to re-think what is going on.

I'm almost 100% sure, that such a technique where somebody can always be able to tell what the correct password is by just having 80-bytes of the encrypted seed is currently infeasible.

Don't get tricked (even if it is worth a lot and you are eager to find the private key), do not pay a single cent for consultancy or a proof/test and do not provide any data before being 100% sure that such a technique is publicly proofen/known to work.

[undeath]

I'm almost 100% sure, that such a technique where somebody can recover a very long random seed by just having 80-bytes of the encrypted seed is currently infeasible.

It's not about recovering the full seed but the password that can be used to decrypt the full seed only. Recovering the full seed from only knowing the first 80 bytes does not make sense.

Other than that I fully agree with your post. Some very valuable advice.

[philsmd]

Yeah, thx undeath. When re-reading my post (after posting, hehe), I also discovered that this phrasing was not very clever and I should have added that whenever you reveal the whole seed, that the private key was also at risk.
I already correct my post, before I saw that you also found this discrepancy in my wordings. Very good that you corrected me too.

The only technique that would help (without revealing the seed and/or private key) would be a way to be 100% and always be able to find the correct password without being able to come up with the seed and private key. Unfortunately, the algorithm design doesn't allow this. I already mentioned the padding attack beforehand, which would be possible only if a different block cipher mode was used.

If such an attack would exist it would not involve bkp (because bkp is a hash over the whole decrypted encseed aka the seed and therefore this would mean that the person that compares something against bkp also has the whole raw seed, which "leaks" the private key).

Again, I am very sceptical that such a technique exists (I'm about 100% sure that this is not possible for the time being).

Also note, if you do not compare against bkp what is the value you are comparing against if you do not know the raw seed ? If the seed is really (cryptographically secure) random, then the decrypted bytes could be anything. You couldn't tell if the decrypted bytes are correct or not, because you are just seeing random bytes with each password candidate you try.

[philsmd]

Now, thinking about the padding attack... I think an alternative could work without revealing the whole encseed.

The thing is that the pre-sale algorithm uses padding (as already mentioned a couple of times above) and AES-128-CBC, see https://en.wikipedia.org/wiki/Block_ciph...ning_(CBC).

It might be possible to reveal only the last x blocks (each block is made up of 16 bytes) of encseed to test against certain bytes within the padding (the padding length for instance which is determined by the last bytes y and repeated for the last y bytes) even with CBC block cipher mode, but you need to xor the result of one block with the previous block (therefore at least 2+ blocks of encseed must be revealed). This could lead to some false positives, but it could nonetheless filter out a lot of "impossible passwords".

Fortunately the pre-sale algorithm uses pkcs7 padding (see https://github.com/ethereum/go-ethereum/...#L119-L138) which could be misused as a "test"/filter. As far as I know the padding length is kind of known (because we know the raw seed length).

I think this could be the only strategy to not reveal the whole encseed value, but still be able to filter out several unlikely/impossible passwords.

Attention: an attack like this would need the last 32 bytes (or slightly more) from the encseed, not the bytes at the very beginning

---

I didn't mention it above, but it is needless to say that this new algorithm also needs to be implemented in hashcat with a slightly different kernel function compared to the one currently in use.

It's also important to note that this type of padding attack is most efficient if you know exactly how long the padding is. For instance if you know that the seed length is always a multiple of 16, you know that you will have a padding of exactly 16 bytes, i.e. 0x10101010101010101010101010101010 (i.e. 16 times the value 16, 0x10 is 16 in decimal)
If the padding is just 1 byte (i.e. 0x01), the chance of false positives is very very high. If it is two bytes, i.e. 0x0202, there will be still a lot of false positives etc. The longer the padding (the range is from 1 to 16 bytes), the less false positives you need to expect.
This is why you would benefit if you know how long the raw seed length is; for instance you could only test for a single padding e.g 0x10101010101010101010101010101010 if you know that the raw (not encrypted) seed is always a multiple of 16.

---

update2: I just tried to investigate to see if there are known weaknesses in how the pre-sale algorithm generated the random seed.
I didn't really find answers by just searching for it, but I discovered this interesting change within the seed generation code commited a couple of years ago:
https://github.com/ethereum/pyethsaletoo...0913fee51e

If I'm interpreting this correctly, the seed was previously (before the patch) generated as a hex string and encrypted and again hex encoded (basically it was twice hex encoded, before and after the encryption). This would mean that all those long encseed values (for instance the ones with 1248 hex chars and therefore 624 bytes) have a very reduced charset (lower entropy per byte) if decrypted whenever the password is the correct one.
If this turns out to be true, one could attack this by decrypting the encseed and see if all the chars are within the range 0-9a-f (all hexadecimal values). This would actually be quite a scandal.

Unfortunately, I have no example to proof if this was really the case with the accounts with very long encseed. If someone could share a real world example (with password such that we can decrypt it) that would be very nice.

This attack of checking for low entropy could be accomplished (in contrast to the padding attack) by decrypting also the first (or last, before the padding... or any substring except padding) bytes.
This would also allow to not share the whole encseed and therefore without the risk of exposing the private key.

I'm not yet 100% convinced if an attack like this is possible because I have no examples, but the commit from above seems to indicate that this low-entropy-attack is possible for a small set of accounts with very long encseed values (which are twice hexed by accident).

---

update3: I've explained here https://github.com/ethereum/mist/issues/...-366007905 how I think the pre-sale website generated the wallet file and that it also used a reduced charset (!!! wtf?) which consists of the characters "abcdefghijklmnopqrstuvwxyz234567" see the app.min.js file linked on the issue. This could be used to filter out password candidates that decrypt the encseed to a seed that does not consist of those characters (like the method explained in the previous update 2).
It turns out that the web app was also on github and you can run the webserver locally and create your own wallet files with that code, I did some tests here: https://pastebin.com/raw/aXrn4t8d