06-09-2023, 05:36 PM
(06-09-2023, 05:04 PM)Chick3nman Wrote: I don't think you can make a safe AND collision resistant variant of the Ethereum presale hash format. We need the entire data field to decrypt and perform the SHA3() checksum wrap and verify at the end. Without that, you would indeed be reduced to padding checks at best I suspect. Perhaps an entropy check or something could work, but you'd still be decrypting more of encseed than I think you might want to expose. Unfortunately, the process for verifying a password is to decrypt the wallet data, which means you must ship at least some of that wallet data to any system doing the cracking, and all of it if you want any reasonable certainty of finding the "right" password and not just a random string that can decrypt the data into "well formed" gibberish.
First of all thank you for your quick response . Tell me if i'm wrong but I just realised I can expose 97% of the encseed which arounds 1200/1248 is SAFE. The time it will take thousands year if someone want to brute force the las 48 characters and having a few false positive is not a big issue. Even having a lot of them could be handled, if I automate a bit and make something that will return me everytime the positive password found.
Could you give some links or a quick description of I can implement padding checks and entropy checks or others tricks to try ? As I told you I'm really happy to learn about this .