[tor-dev] Proposal 284: Hidden Service v3 Control Port

[David Goulet]

On 09 Nov (09:27:15), Yawning Angel wrote:
> On Tue, 7 Nov 2017 12:20:15 -0500
> David Goulet <dgoulet at ev0ke.net> wrote:
> > > This might need a couple more details; as-is ADD_ONION can take
> > > "NEW:BEST" (which should now return a v3 service?) or
> > > "NEW:ED25519-V3" for explicitly asking for a V3 key, or
> > > "ED25519-V3:<56 base32 chars>" for adding an already-existing v3
> > > service.  
> > 
> > Oh good point! I failed to notice that "RSA1024:<key>" was even
> > possible. Actually, it is not specified in the spec but the code
> > expects this:
> > 
> >     "RSA1024:<Base64 Blob>" - Loading a pre-existing RSA1024 key.
> 
> Huh?  It *is* specified, both as "intentionally opaque" and as a
> detailed explanation of what the code actually expects, like thus:
> 
>   (The KeyBlob format is left intentionally opaque, however for
>   "RSA1024" keys it is currently the Base64 encoded DER representation
>   of a PKCS#1 RSAPrivateKey, with all newlines removed.)

Oh I didn't spot that far away from the "KeyBlob" :).

> 
> > 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?

Cheers!
David

> 
> Regards,
> 
> -- 
> Yawning Angel



> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


-- 
jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171109/1d6a684c/attachment.sig>