Compute identical BIP38 Keys with different Private Keys and Passwords?

[zappylappy]

Let's say you have a given Private key (PrivKeyOne). Is there a computational way, so that you can choose or compute a Password (PassOne) to get a BIP38 Private key (Bip38PrivKey) that is identical to a BIP38 Private key that is derived from an other private Key you can choose or compute (PrivKeyTwo) and an other Password (PassTwo) you can choose or compute?

PrivKeyOne + PassOne = Bip38PrivKey

PrivKeyTwo + PassTwo = Bip38PrivKey

Or to put it in other words:
Can you compute two identical BIP38 Keys with two different Private Key and Password pairs of your choice?

[NotATether]

A BIP38 encrypted key is a prefix followed by some flags, a salt, and two encrypted payloads obtained from AES256(1st_half_of_scrypt_result, salt) and AES256(second_half, salt) where our salt is the first four bytes of SHA256d(bitcoin address).

Scrypt is some other hashing algorithm which takes among other things the password and salt as input, so I'm inclined to say no, it's not possible unless you somehow manage to find a collision in SHA256 for two different addresses. Even then a collision in SHA256d is extraordinarily rare, and a collision one which also passes through scrypt and two AES256 encryptions is practically non-existent even if you allow the private key to change.

[pooya87]

Even then a collision in SHA256d is extraordinarily rare, and a collision one which also passes through scrypt and two AES256 encryptions is practically non-existent even if you allow the private key to change.

Algorithm doesn't make a different, the size of the result does. We have the same chance of finding a collision in a 256-bit hash as we have in finding a collision in a 256-bit key derived from scrypt as we have in 256-bit encrypted result returned from AES256.

So technically the answer is yes, generally whenever there is a cryptography function that produces a fixed length result (ie. AES256 here producing a 256 bit result) there is always a chance of collision but practically since the size is huge, chance of collision is so small that it is ignored.

[NotATether]

Algorithm doesn't make a different, the size of the result does. We have the same chance of finding a collision in a 256-bit hash as we have in finding a collision in a 256-bit key derived from scrypt as we have in 256-bit encrypted result returned from AES256.

What if the result length is variable, such as Scrypt's length parameter that dictates the length of the result?

Scrypt takes (password, salt, N, p, r, outLength, digestLength, MixFunctionLength) as parameters. Only outLength matters here since it is the length of the resulting hash, and OP can only change the first two params (password and salt).

[pooya87]

Algorithm doesn't make a different, the size of the result does. We have the same chance of finding a collision in a 256-bit hash as we have in finding a collision in a 256-bit key derived from scrypt as we have in 256-bit encrypted result returned from AES256.

What if the result length is variable, such as Scrypt's length parameter that dictates the length of the result?

Scrypt takes (password, salt, N, p, r, outLength, digestLength, MixFunctionLength) as parameters. Only outLength matters here since it is the length of the resulting hash, and OP can only change the first two params (password and salt).

When we are talking about chance of collision only the length of the final result (which is the result of AES256) will determine the chance, it doesn't matter what one of the steps were like what the KDF produced. Besides your password length is already variable (user can select anything from empty string to a very long one).
If you change AES256 with a bigger version like AES512 then yes the chance rises.

The algorithm itself (such as using scrypt, cost factor of it,etc) determine the cost of finding a collision although that's not their purpose but a byproduct of making brute forcing harder. (The cost of finding a collision is already high due to the size being 256 bit.)