On 8 Nov 2017, at 04:20, David Goulet <dgou...@ev0ke.net> wrote:
>>> 3.1.3. ADD_ONION
>>>
>>> For this command to support version 3, new values are added but the syntax
>>> is unchanged:
>>>
>>> "ADD_ONION" SP KeyType ":" KeyBlob
>>> [SP "Flags=" Flag *("," Flag)]
>>> 1*(SP "Port=" VirtPort ["," Target])
>>> *(SP "ClientAuth=" ClientName [":" ClientBlob]) CRLF
>>>
>>> New "KeyType" value to "ED25519-V3" which identifies the key type to be a
>>> v3 ed25519 key.
>>>
>>> New "KeyBlob" value to support the new "ED25519-V3", if specified, will
>>> generate a new ed25519 private key.
>>
>> This might need a couple more details; as-is ADD_ONION can take
>> "NEW:BEST" (which should now return a v3 service?)
When we change the default HiddenServiceVersion to 3, then let's make
BEST return a v3 service. Until then, let's make it v2.
I think it would be a good idea to be consistent like this.
T
>> 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.
>
> 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.
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
