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.