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