The clients that offer type-2 deterministic wallets (like electrum and armory) should advise their users that sharing any private key from the derived chain (not the master private key, of course) MUST be avoided. Such a sharing of a private key could happen for example by funding your MtGox account with the "Redeem private key" option.
Recall the suggested computation of the key chains was this:
Privatekey(type,n) = Master_private_key + H(n|S|type)
Publickey(type,n) = Master_public_key + H(n|S|type)*point
where S is a random seed.
The use scenario is that a "hot" machine (connected to the internet and potentially vulnerable) generates a chain of public keys, and for that purpose stores Master_public_key as well as S. In a reasonable threat model both values become available to an attacker because the "hot" machine is vulnerable. Since the serial numbers n and the type can be guessed, a single leaked private key will leak Master_private_key as well by a simple substraction in the finite field underlying secp256k1.
Conclusion: Users should be advised that ANY private key from the generated key chain is to be secured with the same security level as the master private key.
This seems to affect not only the implementation of deterministic wallets in electrum and armory but also the hierarchical deterministic wallets suggested in BIP 032:
We define the child key derivation function CKD((kpar,cpar),n), which takes a parent extended secret key (kpar,cpar) and a 32-bit integer n, to produce a child extended secret key (kn,cn).
To define (kn,cn) = CKD((kpar,cpar),n):
call I = HMAC-SHA512(Key=cpar, Data=kpar*G || n), where kpar*G is the public key corresponding to kpar, || is concatenation, and n is encoded as a 32 bits unsigned integer, most significant byte first.
Split I into two 32-byte sequences, IL and IR.
kn is equal to IL*kpar.
cn is equal to IR.
We also define a version that operates on extended public keys instead of private ones: (Kn,cn) = CKD'((Kpar,cpar),n):
call I = HMAC-SHA512(Key=cpar, Data=Kpar || n), where n is encoded a 32 bits unsigned integer, most significant byte first.
Split I into two 32-byte sequences, IL and IR.
Kn is equal to IL*Kpar.
cn is equal to IR.
Suppose the "hot" machine of some main business wants to be able to automatically generate extended public keys (Kn,cn). It needs to store (Kpar,cpar) to do that. Suppose it computes the corresponding extended secret key (kn,cn) on a "cold" machine and hands it to the business' subbranch numbered n, so that the subbranch can work independently. Now, if the information (Kpar,cpar) stored on the main business' "hot" machine leaks then the subbranch can obtatin the main business master private key kpar by these computations:
- I = HMAC-SHA512(Key=cpar, Data=Kpar || n)
- Split I into two 32-byte sequences, IL and IR
- kpar = IL^(-1)*kn (arithmetic in the finite field underlying secp256k1)
Conclusion: In a scenario where derived secret keys are handed over to subbranches, the derived public keys MUST not be generated on the fly on "hot" machines. Instead, even Kpar must be stored "cold". To some extend this contradicts the original idea of hierarchical deterministic wallets.
