consistent pcp/pbp formats (was: Curve p25519 Replacements for GnuPG?(x2 now) ..)

[Thomas von Dein]

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.