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

[Yuriy Kaminskiy]

Thomas von Dein wrote:
>> consistent key formats are critical
> 
> more than fine with me.
> 
>> need to converge on:
>> - endianness
> 
> I'm currently using big endian for multibyte values whereever they
> appear. It's already verified to work on little and big endian platforms
> (e.g. tested on aix/ppc)
> 
>> - coordinate representation x, x&y, x and sign ...
>> or bits to show which of these ... perhaps borrow ANSI method
> 
> Could you please explain this further?
> 
>> - hint / indication of cipher suite / curve 
> 
> In pcp there's already such a hint included in exported keys, however
> I'm not using it, since there's no choice of different curves in
> libsodium so far. But it's on the list.
> 
>> - text encoding of binary format (ascii)
> 
> As already stated in the other subthread, I use Z85, while stef is using
> base85. Since Z85 is a subset of base85, I'm pretty sure we can agree on
> something.
> 
>> - human readable format
> 
> There's a human readable version of keys in pcp, but the tool itself
> doesn't use it (example attached). It uses the z85 encoded binary part
> of such a file.
> 
> pcp has some more fields stored in a key than pbp:
> 
> - a key id (e.g. 0x54E9C62E1852EBC5) which is required to identify a key
> - some text fields (owner, mail)
> - a serial number
> - key format version number
> 
> I'm not sure, how stef solved the ed25519 issue (you can't use a
> curve25519 secret key to create an ed25519 signature directly). After
> some discussion on the libsodium mailinglist we came up with this:
> 
> When the user generates a new key, the ed25519 secret key will be
> generated first. The curve25519 secret will be derived from that, since

In general, reusing keys for different purposes (signing and encryption)
considered bad idea, even through it is possible (RSA signing and RSA
encryption, DSA signing and ElGamal/DH encryption [fwiw, this one considered
*very* bad idea]).

> the ed25519 already contains a usable curve25519 key. In pcp I store
> both of them for easier access, so the ed25519 and curve25519 secret and
> public keys are stored, the secret keys are encrypted and I store the
> nonce as well (see include/pcp/key.h).
> 
> Speaking of key encryption: @stef: according to your docs you're already
> using scrypt() for key derivation. I'd like to use that as well, but
> it's not part of libsodium (afaik), so I use my own method for this til
> scrypt() is implemented in libsodium. That's because I want to avoid
> writing crypto code myself.

> Maybe we should iron out the details off-list?

PS If I'm not mistaken, pcp is using longtime curve25519 secret key for message
encryption.
1) Recipient needs to know sender public key. Bad.
2) Message remains decipherable by sender. Very bad.
3) Sender public key/identity leaks with each message. Very bad.
4) Sender needs access to her secret key. Bad.
5)6)7)...
Wut? WTF? WHY?????
Just generate single-use keypair, send public part with message, throw away
secret part right after encryption.

PPS gnupg devs are currently working on adding support for curve25519/​ed25519;
though, it's on very early development stage. Oh, well, NIH-NIH-NIH, let's
invent our own square-wheel bycicle.