If one leak can be tolerated, why not just specify that the final branch should only use 0 as it's index. This way no two keys of the same direct parent are ever generated.
Short answer: Every key, no matter where in the hierarchy, is ultimately a linear combination of the
m master keys. Thus, a total of
m keys gathered from anywhere in the hierarchy is enough to break the wallet.
Less-short answer: We didn't even bother to explicitly define how one generates descendant keys beyond the first level. One straightforward way to do it is as follows. (
m is overloaded; let
n be the number of master keys.) The first
n child keys
m/0 through
m/n-1 are designated as the "master" keys for m/"0", the subsequent
n child keys
m/n through
m/2n-1 are "master" keys for m/"1" and so on recursively. So, for example, m/"0"/0 and m/"1"/0 are both linear combinations of the original
n master keys d
1,...,d
n.
tl;dr
you give the Auditor A and R, but and you give only one key per branch to each department.
m/0/0/0 goes to dept A
m/0/1/0 goes to dept B
m/0/2/0 goes to dept C
so no one else on their branches knows the private keys, as m/0/x/y is not known where x is in the range [0, 2] and y is greater than 0.
If I'm the Auditor and I want to audit dept C:
Step1: Derive first level
s0 = H(0,A)
t0 = H(0,R)
A0 = s0*A
R0 = t0*R
X0 = A0 + R0
Step2: Derive second level
s0,2 = H(2,A0)
t0,2 = H(2,R0)
A0,2 = s0,2*A0
R0,2 = t0,2*R0
X0,2 = A0,2 + R0,2
Step3: Derive third level
s0,2,0 = H(0,A0,2)
t0,2,0 = H(0,R0,2)
A0,2,0 = s0,2,0*A0,2
R0,2,0 = t0,2,0*R0,2
X0,2,0 = A0,2,0 + R0,2,0
So A0,2,0 with R0,2,0 would be dept C's MPK used to generate keys below it. Also, Auditor can generate too... but knowing A, R, A0,2,0, R0,2,0, a0,2,0, and r0,2,0 should not allow the colluders to solve for r0,2, a0,2, a or r... at least I think so...
That is what I am wondering...
As long as direct parents with multiple (actually used) children never occur, it should be fine... I think.