Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Two peers already exchanged their ECDSA (curve secp256k1) public keys using a secure channel.

They want to establish an authenticated encrypted channel between them. They will use CCM mode and with the AES block cypher (as implemented in the SJCL crypto library).

Is it safe for them to use as a key for CCM the output of PBKDF2(iter=1000) of the other peer's pubkey? Is there a better solution without exchanging more data off channel?

(public keys are 33 bytes long).

EDITED: These pubkeys are not public, only shared between the two peers.

share|improve this question

2 Answers 2

up vote 2 down vote accepted

This seems... confused. PBKDF2 is a Password-Based Key Derivation Function. It is used to process a password, i.e. a secret piece of data that both parties share.

In your case, they don't share any secret piece of data. They know each other's public keys, which are public, so they are known to everybody. Putting them in PBKDF2 won't turn them secret.

share|improve this answer
    
Thanks for your comment. pubkeys in this case are no public..., are derived public keys from a extended public key (en.bitcoin.it/wiki/BIP_0032), what are shared between the peers but not to strangers. –  ematiu Apr 30 at 12:57
    
It is a strange notion, to keep a public key "private". In particular, a public key can be recomputed from a signature (if the signed message is known), so it tends to "leak". In any case, PBKDF2 is meant to strengthen low-entropy secrets which are amenable to exhaustive search; if you "discreet keys" are really private (I doubt it, but hey, let's assume that it happens that way), they don't need PBKDF2; and if they are not private, then PBKDF2 won't make them "more private". –  Tom Leek Apr 30 at 13:38
    
thanks a lot Tom! –  ematiu Apr 30 at 13:54

If the keys are actually secret, then this would work ok, but at that point, why not just pre-exchange a symmetric key for use on the communication channel? This is still a very, very odd and borderline inappropriate use of the algorithms since it is confusing and easily messed up due to using terms like "public key" for a shared secret.

If you are relying on a shared secret, there is no reason to incur the added expense of using a much longer asymmetric key with more complicated encrytion/decryption logic.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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