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

[teor]

> On 10 Nov 2017, at 03:17, Yawning Angel <yawning at schwanenlied.me> wrote:
> 
> On Thu, 9 Nov 2017 10:13:45 -0500
> David Goulet <dgoulet at ev0ke.net> 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.)

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171110/0eed74ff/attachment-0001.html>