2
$\begingroup$

I asked this at bitcoin.stackexchange.com first, but it seems that this is more of a crypto-question anyway.

I'm interested in using a Hierarchical Deterministic Bitcoin wallet branch as a "shared secret" between two parties. Basically one party could send an index (in plain text) to the other party, along with some sensitive information encrypted (symmetrically!) with the public key along that HD branch.

The recipient could then derive the public key at the sent index, and decrypt (symmetrically!) the sensitive information with that public key. These keys would not be used as addresses or in any bitcoin transactions, nor would any addresses along that HD branch. The HD branch itself is not known outside of the two parties.

  • Is this (cryptographically) secure?
  • Would it be better to hash the public keys before using them as an encryption key?
  • Are there any resources about doing something similar I can use for research?
  • Anything blindingly obvious that I'm missing?

Thanks!

|improve this question
$\endgroup$
  • 3
    $\begingroup$ It is always a good idea to use a KBKDF (such as HKDF, which indeed uses a hash function) over any secret before you use it as a key. I won't put this as an answer as I don't know the BitCoin model. $\endgroup$ – Maarten Bodewes♦ Aug 28 '14 at 20:10
  • $\begingroup$ Thanks for replying. Excellent suggestion, I will definitely look into KDFs in addition to this model. $\endgroup$ – JohnDvorak Aug 28 '14 at 20:32
  • $\begingroup$ Let me see if I understand. You have two parties who have previously shared (part) of a wallet. You want to use that shared information to establish secure communications between the two. Is that correct? $\endgroup$ – mikeazo Sep 4 '14 at 19:37
  • $\begingroup$ Correct. They both know the public key of a Hierarchical Deterministic (HD) branch that can derive seemingly-random public keys using an index. My question is whether I can send the index along with the message (which is encrypted with the Bitcoin "public key" at the index). $\endgroup$ – JohnDvorak Sep 4 '14 at 20:03
5
$\begingroup$
  • Is this (cryptographically) secure?

That is hard to say without knowing the exact details of the bitcoin protocol (which I would like to understand better, but don't have the time at the moment). Looking at the document you linked to, the public child key is created as $\text{HMAC-SHA512}(Key = c_{par}, Data = ser_P(K_{par}) || ser_{32}(i))$. This value is split in half. One half is turned into a point. That point, plus $K_{par}$ is returned as the public key. The other half is returned as the chain node. Is this the index of which you speak?

The process looks good, but it is hard to say whether or not it is cryptographically secure without knowing details of how the input parameters are chosen. It all comes down to the entropy of those. If they are high entropy, then the output should be high entropy and so it should be "secure" (you haven't actually defined secure, but I'm assuming you mean that an outsider could not guess/figure out the key).

I would strongly recommend, once you have formally specified your protocol, that you work on a security proof. This will likely be done by reducing the security of your protocol to some other (related) protocol. This would be done by assuming an attacker breaks your protocol then showing some horrible impact this would have on the other protocol. The other protocol could be the HD wallet protocols. That would establish that breaking your protocol is at least as hard as breaking HD wallet.

  • Would it be better to hash the public keys before using them as an encryption key?

As the public key is a point on an elliptic curve, I would say yes. In particular, owlstead's recommendation of a key derivation function is on the right track.

  • Are there any resources about doing something similar I can use for research?

Not that I am aware of.

  • Anything blindingly obvious that I'm missing?

Well, if there is, I am missing it too. The best way to find out about this at this point would be to write up a short white paper on the idea and present it to people familiar with the areas (both bitcoin and cryptography). You could do this by sending it directly to researchers and getting their thoughts, publishing it in a workshop of some sort, etc. Also, make it available online somewhere (e.g., ePrint) and comment on here with a link (I'll definitely take a look). Your white paper should review enough of the basics of the bitcoin protocol and the HD wallet protocol so as to be self-sufficient. This should be a good exercise as I saw on your profile that you are a graduate student.

|improve this answer
$\endgroup$
  • $\begingroup$ First, thank you for answering! The index I was referring to was the i value that is appended to the key, to derive a child key. The biggest issue I see with it currently is that the i value (index) must be shared in plain text with the message, so the security of the entire system is dependent on whether an attacker, given i, can derive a key from previous (index, ciphertext) pairs. I guess it deserves some more research! Thanks for you help, I'll try and write something up soon! $\endgroup$ – JohnDvorak Sep 5 '14 at 13:15
  • $\begingroup$ @sylarmorgan If the keys are good, publishing i shouldn't matter. It is used in generating the public key, but there is (hopefully) enough additional entropy there that it wouldn't matter. For example, if I generated keys to encrypt messages to you as Hash(really_long_shared_secret || i) and sent to you i and a message encrypted with the key, the attacker knowing i doesn't help them very much. In the encryption, there are ways we could mess up (for example, this key generation is deterministic, so we would have to use good IV's as input to the block cipher, etc). $\endgroup$ – mikeazo Sep 5 '14 at 13:20
  • $\begingroup$ Gotcha, that makes sense. Does this seem analogous to a public salt (i value) with the resulting hash as a shared key? This is giving me good ideas for reducing this protocol to a known protocol. $\endgroup$ – JohnDvorak Sep 5 '14 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.