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

[Yawning Angel]

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.)

> 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).

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171109/9af5be06/attachment.sig>