Thomas von Dein wrote: > On Wed, Jan 15, 2014 at 02:46:08AM +0400, Yuriy Kaminskiy wrote: >>> When the user generates a new key, the ed25519 secret key will be >>> generated first. The curve25519 secret will be derived from that, since >> In general, reusing keys for different purposes (signing and encryption) >> considered bad idea, even through it is possible (RSA signing and RSA >> encryption, DSA signing and ElGamal/DH encryption [fwiw, this one considered >> *very* bad idea]). > > Well, the libsodium developers not only told me how to do it, it was > their idea. However, it's of course very simple to generate them > separate.
It is *possible* to use same RSA keypair for encryption and signing (and earlier pgp versions used to that). Does not mean it is *good idea* (and newer openpgp/gnupg switched to use separate keys for signing/encryption/certificate signing purposes, by subkeys mechanism). (For DH/DSA it is even worse, you *can* reuse same keypair, but this leads to leak of secret key material. I'm not sure if same leak scenario apply to ECDH[curve25519]/EdDSA[ed25519], but better safe than sorry. And keypair reuse is bad from operational security pov anyway). >> 1) Recipient needs to know sender public key. Bad. [clarification: sender *long-term* public key; of course, receiver needs to know public key that was used for message encryption; but this key need not be same with sender *long-term* key] > That's the way curve25519 works. It would be possible to use one time > keys but for this there has to be some kind of key exchange process > before. But since pcp runs in offline mode, I'm not sure how to do this > in a user friendly way. I explained: include (single-use) public key in message, in place of "hash of sender key id"). >> 2) Message remains decipherable by sender. Very bad. > > No, it doesn't. In order to decrypt a message one needs the recipient > secret key and the sender public key. Yes, it does. With your protocol, message can be alternatively deciphered with crypto_open_box(c, n, sender_public_key, receiver_secret_key); (by receiver, good) or, alternatively, with crypto_open_box(c, n, receiver_public_key, sender_secret_key); (by sender, *BAD*). With openpgp (and with my suggested change), sender does not retain secret key used for message encryption, and thus cannot decipher his own message. >> 3) Sender public key/identity leaks with each message. Very bad. > > Because? > > While I don't know how stef does it in pbp, I only add the key id to the > cipher so that the recipient knows which key has to be used to decrypt. > I'm not sure how it is bad to publish a key id. That's daily business > with pgp as well. Incorrect. This is NOT daily business with pgp. Openpgp does not use long-term sender keypair when it encrypt message (otherwise, how could you encrypt message without using passphrase?) and does not leak sender keyid (/by default/ gnupg leaks /recipient/ keyid, but it can be disabled with --hidden-recipient). >> 4) Sender needs access to her secret key. Bad. > > Again, this is how curve25519 is designed. This has NOTHING to do with either curve25519 (or nacl) design. It is only how *YOU* are using it. >> Just generate single-use keypair, send public part with message, throw away >> secret part right after encryption. > > The sender needs a public key from the recipient anyways. And to be able > to decrypt the message, the recipient has to retain her secret key. I said nothing about *recipient* secret key. Recipient, of course, need to access to her secret key to decipher message. And sender, of course, needs to know recipient long-term public key. >> Oh, well, NIH-NIH-NIH, let's invent our own square-wheel bycicle. > > Funny, but neither I nor stef invented anything. DJB did. DJB has nothing to do with your self-invented protocol. DJB invented bending tool. *You* decided to use it to make square wheels. P.S. there were thing that openpgp did horrible wrong: keyids (they are harmful and useless crap). Funnily, you repeated their misdesign.
