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

[stef]

howdy,

On Mon, Jan 20, 2014 at 03:13:42PM +0400, Yuriy Kaminskiy wrote:
> 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.

does it? actually pbp generates a symmetric key, which is encrypted to the
recipients encryption public key. btw, pbp creates 3 keys for each id, one
long-term master for key-signing only, and two sub-keys one for encryption and
one for generic signing. the encryption subkey is only used for the encryption
of the message key. is that a problem? isn't that how pgp does it?

> Unlike pcp, it does not include sender identification in message, receiver must
> try all public keys in her keyring.

this is mostly a problem only for verifying signatures, in a keyring with lots
of public keys. but the operation is only on the hash of the message. for
encryption this is neither so much a problem as traditionally the number of
private keys one person holds is manageable. however even in these cases the
wrong key is detected after decoding the message key, which again is a 32 byte
ciphertext. so i don't expect this to be very slow. if this really becomes a
problem you can start pbp with different home directories using the --basedir
param.

> Which have advantage of not leaking sender identity to eavesdropper, but
> waste a lot of CPU on receiver side (as your keyring grows),

indeed. but that was one of the design goals, to fix the problem openpgp being
a strong selector and low hanging fruit in all forensic tools. i'm very happy
to spend some cpu cycles on locating the right key if it means the adversary
has a higher computational effort than me.

> and receiver also cannot search sender identity by keyid on [hypothetical]
> keyserver.

indeed, this need has not been addressed yet.

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

i would be delighted to hear your commentary on
https://raw.github.com/stef/pbp/master/doc/chaining-dh.txt

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

in the nacl implementation i believe something like this happens: P_a and S_b,
as well as on the other side S_a and P_b are used in a ECDH secret derivation,
which then is passed through hsalsa20 to derive the key, then this shared
secret is used as a key for a salsa20xpoly1305 authenticating stream algo,
that also needs a 32 byte nonce for encryption. so indeed both sides can
decrypt the message encrypted to the other in this scheme. all this of course
is overly simplified you can find the details on pp15
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf

cheers,s

-- 
pgp: https://www.ctrlc.hu/~stef/stef.gpg
pgp fp: FD52 DABD 5224 7F9C 63C6  3C12 FC97 D29F CA05 57EF
otr fp: https://www.ctrlc.hu/~stef/otr.txt