> On 10 Nov 2017, at 03:17, Yawning Angel <yawn...@schwanenlied.me> wrote:
>
> On Thu, 9 Nov 2017 10:13:45 -0500
> David Goulet <dgou...@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
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
