0

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.

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
2
  • 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
    Commented Apr 30, 2014 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
    Commented Apr 30, 2014 at 13:38
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .