On Thu, 9 Nov 2017 10:13:45 -0500 David Goulet <dgoulet@xxxxxxxxx> wrote: > > > Ok fun! I'll add this. Good catch! And control-spec.txt should be > > > updated. > > > > > > To be consistent then we could ask for a <Base64 Blob> as well: > > > > > > "ED25519-V3:<Base64 Blob>" > > > > > > ... which contains the ed25519 private key. > > > > If it were up to me, I'd spec the blob as opaque, and then actually > > use something that's sensible and consistent with the torrc and on > > disk files for easy interoperability like Base64 of the private key > > (I haven't check to see what encoding is used for on disk EdDSA > > keys, I assume PEM). > > Unfortunately not, it is custom to tor I believe with this 32 bytes > header: > > "== ed25519v1-secret: type0 ==\0\0\0" > > ... followed by the private key (64 bytes). See > crypto_write_tagged_contents_to_file(). > > Not sure we can change that within the 032 freeze. So the approach > would be to Base64 the raw bytes of the key (excluding the header). > Using tor HS key file, it would be something like: > > $ tail -c+33 hs_ed25519_secret_key | base64 -w 0 > > Considering the current situation with the encoded file on disk of > the key, I think this is kind of the simplest approach? Yeah. Just the Base64ed private key (excluding that header and things) seems reasonable. -- Yawning Angel
Attachment:
pgp1KBjRIRAWV.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev