On Wed, Jan 15, 2014 at 04:29:44PM +0400, Yuriy Kaminskiy wrote:
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).
We're not talking about RSA, do we?
(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).
As I alredy said, it's no problem to have separate keyspairs for signing and encrypting, just a couple of lines to change.
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").
Ok, let me formulate it better: I can use a single-use keypair on the sender's side and include the public part in the message. Cool. But the sender would nevertheless need a public key from the recipient. This one has to be from a long-term key, since we're operating in a store-and-forward environment. But it doesn't make sense to use a single-use key only on one side of the communication, does it? As a sidenote, in pcp it's possible to generate a keypair for one recipient (it's derived from the long-term keypair), so you'd at least have one keypair per peer. But it's unclear to me, how to use single-use keys on both sides of a communication in a store-and-forward environment. Any hints?
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*).
Really? I'll try it, but if this is the case, then it's bad indeed.
With openpgp (and with my suggested change), sender does not retain secret key used for message encryption, and thus cannot decipher his own message.
Yea, I see.
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).
ok, got it.
DJB has nothing to do with your self-invented protocol. DJB invented bending tool. *You* decided to use it to make square wheels.
Come on, have a heart. The only thing I "invented", was how to store keys and encrypted files. It's just a fun project in it's early stages and everything can be changed. And I'm really glad when someone points out some errors I made.
P.S. there were thing that openpgp did horrible wrong: keyids (they are harmful and useless crap). Funnily, you repeated their misdesign.
ok, really got it. - Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.