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)
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)