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 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? bes, Tom -- PGP Key: https://www.daemon.de/txt/tom-pgp-pubkey.txt S/Mime Cert: https://www.daemon.de/txt/tom-smime-cert.pem Bitmessage: BM-2DAcYUx3xByfwbx2bYYxeXgq3zDscez8wC -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.