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

[Yuriy Kaminskiy]

Thomas von Dein wrote:
> 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.
>> Unlike pcp, it does not include sender identification in message, receiver must
>> try all public keys in her keyring.
> 
> Nope, the sender's public key is included by pbp with the encrypted

Hmm?
=== cut pbp-git/doc/fileformats.txt ===
public key encrypted files have the following structure:
  5[1]|nonce|len(recipients)[4]|[(recipients...)|c(packet key, nonce, msg)
where recipients is a concatenated list of
  random_nonce|c(recipient crypto pk, random_nonce, packet key)
==== cut ===
Public key where?

Well, if you look at code, actual format is a bit different:
=== according to pbp-git/pbp/pbp.py ===
  5[1]|len(recipients)[4]|(recipients...)|(secretboxes...)
where recipients is a concatenated list of
  random_nonce|box(our identity privkey, recipient crypto pk, random_nonce,
packet key)
and secretboxes is a list of
  nonce|secretbox(packet key, nonce, msg[i:i+BLOCK_SIZE]); i+=BLOCK_SIZE;
=== cut ===

(Too lazy to dig in "chaining-dh" carefully; but it uses "normal pubkey
encryption" for bootstrap anyway).

Correct format should be:
  6[1]|temp_keypair.pubkey|len(recipients)[4]|(recipients...)|(secretboxes...)
where recipients is a concatenated list of
  random_nonce|box(temp_keypair.privkey, recipient crypto pk, random_nonce,
packet key)

> message. Since yesterday pcp does the same. However, I use a dynamic
> keypair on the sender site now. I'm currently in the process to change
> the encrypted output format of pcp to match the one of pbp.
> 
>> 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 :-)
> 
> Absolutely. Speaking of mistakes: I had even a note in the manpage where
> I mentioned that it might be a bad idea to include the key-id with
> encrypted messages, though I totally forgot it :) Oh - and I didn't
> really include the key-ids, but a hash from it instead. However, this

(Well, this is already fixed and does not matter anymore, but...)
For eavesdropper, it does not matter if you use keyid or hash(keyid), or
hash(hash(hash(hash(keyid))))).
If keyids are same, their hashes are same (this can be fixed by salting). If
eavesdropper knows keyid, he can calculate hash(keyid) as well, and thus map
messages to keyids (this *cannot* be fixed by salting).

> has already been changed.