Hash the string and split it up into 8 4-byte chunks, using those as your indexes.
Thanks I considered this option but didn't quite like it because of too many group operations to build such a long path.
Topic: BIP32 with string indexes (Read 708 times)
Thanks I considered this option but didn't quite like it because of too many group operations to build such a long path.
Hash the string and split it up into 8 4-byte chunks, using those as your indexes.
Code:
Seed : 41414141414141414141414141414141
Domain : bitcointalk.org
Hash : f245bd5620ee79314f48d9e9641a5406bd03745f6ac516e2801ef6ccbfe40ced
Path : 1917173078h/552499505/1330174441/1679447046/1023636575h/1791301346/2029260h/1071910125h
Address : 13viHo9wVRY8TyTW9YJfGKTaGiJSksPmCV
It should be ok but bear in mind that there is no way to know which path you have chosen. If you forget that you have coins at 'bitcointalk.org', they will be lost and so will be every coin deeper in that branch.
I'm developing an authentication scheme using bitcoin cryptography, and for best privacy I want to derive a unique key pair for each domain. It would be nice to have derivation paths like
m/44'/0'/0'/0/bitcointalk.org
However BIP32 spec allows only integer indexes in the derivation path. I could map domain names to 32-bit integers (e.g. take sha256 of domain name and then use only the first 32 bits) but then it would be too easy to find collisions. Another option I thought of is taking sha256 hash, splitting it into eight 32-bit integers, and then building a long derivation path like m/44'/0'/0'/0/int1/int2/int3/int4/int5/int6/int7/int8. I don't like it either because such a long path would require too many group operations.
How about using a string as derivation index? In BIP32, a 32-bit serialization of the integer index ser32(i) is used as input to HMAC, and as far as I can see there is nothing in the spec that depends on the index being exactly 32 bits. That makes me think that the derivation functions will still work if we feed into them all the bits of a string instead. For example, non-hardened derivation would look like this (in BIP32 notation):
I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || "bitcointalk.org")
The keys are still recoverable because they will be regenerated on demand when user tries to access the domain.
Are there any problems with this derivation?
m/44'/0'/0'/0/bitcointalk.org
However BIP32 spec allows only integer indexes in the derivation path. I could map domain names to 32-bit integers (e.g. take sha256 of domain name and then use only the first 32 bits) but then it would be too easy to find collisions. Another option I thought of is taking sha256 hash, splitting it into eight 32-bit integers, and then building a long derivation path like m/44'/0'/0'/0/int1/int2/int3/int4/int5/int6/int7/int8. I don't like it either because such a long path would require too many group operations.
How about using a string as derivation index? In BIP32, a 32-bit serialization of the integer index ser32(i) is used as input to HMAC, and as far as I can see there is nothing in the spec that depends on the index being exactly 32 bits. That makes me think that the derivation functions will still work if we feed into them all the bits of a string instead. For example, non-hardened derivation would look like this (in BIP32 notation):
I = HMAC-SHA512(Key = cpar, Data = serP(point(kpar)) || "bitcointalk.org")
The keys are still recoverable because they will be regenerated on demand when user tries to access the domain.
Are there any problems with this derivation?
Jump to: