On Jan 14, 2014, at 3:16 AM, Thomas von Dein <tom@vondein.org> wrote:
- 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?
ANSI defined (and used by NIST and others) the use of the first byte of a elliptic curve point representation to indicate if it is: - both x&y coordinates - compressed with sign in the byte - ..just x (guessing on this need to go check) bit coin may use the same … easiest doc to find would be in RFCs However … if the key is solely for an initial DH exchange you may not need anything.
- 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.
OIDs suck. A simple registry would be nice. You need to know the key type when publicly introduced … but there are applications where you would want to be stealthier on indicating suite usage
- 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.
Not familiar with Z85 … pointer please ... base85 or Z85 are a decent balance of compression and robustness for applications like email signatures
- 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
base27 would be much better for a ‘id’ that humans read base16 is really old school
- 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: curve naming, test vectors, algorithm usage need work ...
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?
I’m interested … Paul
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.
<key-alicia-pub.txt>