On Jan 14, 2014, at 3:16 AM, Thomas von Dein <[email protected]> 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>
