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