On Tue, 7 Nov 2017 12:20:15 -0500 David Goulet <dgoulet@xxxxxxxxx> 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
Attachment:
pgpC1KHOzBIMm.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev