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

[Yuriy Kaminskiy]

FWIW, I quickly looked at pbp [python? hate-hate-hate], it apparently has nearly
same design defect: it uses long-term curve25519 keypair for message encryption.
Unlike pcp, it does not include sender identification in message, receiver must
try all public keys in her keyring. Which have advantage of not leaking sender
identity to eavesdropper, but waste a lot of CPU on receiver side (as your
keyring grows), and receiver also cannot search sender identity by keyid on
[hypothetical] keyserver. NIH, NIH, NIH.

Thomas von Dein wrote:
> 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?

Nearly same consideration apply to both?

>> (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

Well, yes. If you want to send message to someone, you need to obtain her
(current/longterm) public key first, and you need verify it somehow (in-person
exchange, web-of-trust, CA signature, etc; in case ephemeral encryption key, it
should be signed by verified long-term identity key), otherwise you are
vulnerable to MITM. I don't see any way around it.

> 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?

Hmm?
You cannot fix (1), (2), (3), (4) without using single-use keypair by sender
side. So, of course, it makes sense.
Single-use keypair on receiver side would be nice (PFS!), but it is not possible
in store-and-forward.

> 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?

I'm not sure how are they useful? (Once you use per-message keypairs, that is.)

>>>> 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.

That's how (any) DH works? You generate common secret from one side public key
and other side private key?

>> 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.

Well, to be fair, openpgp standard had several edition, was reviewed by many
people, etc, and still managed to get it wrong.
Earlier versions of pgp also did a lot things wrong. Etc.
SSL/TLS history is also full of mistakes, some fixed by newer version, some
still remains (EtM), some even added by newer versions (cleartext SNI).

It is not easy to mess up with crypto - it is /extremely/ easy :-(

And that's why it is important to point out at mistakes early on, without any
mercy :-)

> ok, really got it.

PPS === cut platform.h ===
#ifndef HAVE_ARC4RANDOM_BUF
// shitty OS. we're using libsodium's implementation
=== cut ===
LOL, I'm glad I'm on "shitty OS"; well, not quite (e.g. openbsd recently
switched arc4random from rc4 to chacha); but I'd bet there are quite some "by-​
this-​definition-​non-​shitty-​OS" that 1) has arc4random_buf; 2) still uses RC4
under the hood. Then again, while rc4 is considered somewhat flaky, but it is
not completely broken (yet), and still in wide use, so it is not *terrible* big
deal. But DJB will frown on you, LOL.