On 10 Nov (04:06:55), teor wrote: > > > On 10 Nov 2017, at 03:17, Yawning Angel <yawning@xxxxxxxxxxxxxxx> wrote: > > > > 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? > > > > Show Quoted Content > >>>> 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. > > Do we accept base64 with padding? Without padding? > (We should accept both - we know how long the key is.) > > Do we generate it with or without padding? > (We should follow whatever we do with RSA.) It follows the tor base64 API so basically padding is added when encoding and padding or not when decoding is working. Because we know the size of the keys, tor expects a specific byte size (padding or not). This is what the RSA base64 encoding/decoding does. David > > T > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev