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

[nymble]

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