Shouldn't reusing the intermediate_code be forbidden?
If intermediate_code is reused then the party generating the encrypted keys can conspire with someone who gets to see a lot of privkeys (some big exchange) and wait for one of its customer to reveal some privkey from one of these generated encrypted keys. Sooner or later this will happen. Then the conspirers can take over the whole series of coins based on the same intermediate_code. An issuer of physical coins should protect himself from such accusations by not accepting the same intermediate_code twice.
Thanks for asking. Let me break this down into an intermediate code's component parts.
An intermediate code consists of salt, and an EC point based on the passphrase plus that salt.
Whether or not someone should reuse the same passphrase is their prerogative and outside the scope of the spec, so I'll eliminate that for consideration. Thus, the problem boils down to whether someone should reuse the same salt.
If never reusing salt were infinitely practical, then the answer would always be no. In this application, in order to
not reuse salt, one must generate a separate intermediate code for every key they want created. That takes time. And the creation of the addresses themselves would take similar time. So, fair to say that it's inconvenient.
Salt prevents precomputation attacks. The main purpose of salt is to add a random element to the key derivation process and to prevent somebody from being able to precompute a large table that would accelerate the cracking of any passwords that fell into the set of passwords covered by the table. With unique salt per key, they have to attack keys one at a time instead of the whole world of keys at a time.
Using the same salt and passphrase broadens the exposure such that the entire batch of keys can be cracked with the same effort, rather than just one key at a time. A random element is still added, but it's random per intermediate code, rather than random per individual key.
In this application, that's not a useful acceleration to an attacker, considering an entire batch of keys already likely has the same password and can be cracked as a batch anyway, whether or not the salt was unique per key. Crack one, you've cracked them all. There is no reason why an attacker would want to go to the enormous effort of creating precomputation tables just to attack multiple keys belonging to a single user whose keys probably already have the same password. This would only be worthwhile if the table were a tool that could crack anybody's password when encountered; random salt per intermediate code puts an end to that.
My conclusion is there's no real benefit to burdening each user with a complicated process for what is probably an illusory measure of protection.