On Thu, 9 Nov 2017 10:13:45 -0500
David Goulet <dgoulet@ev0ke.net> wrote:Ok fun! I'll add this. Good catch! And control-spec.txt should beupdated.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 actuallyuse something that's sensible and consistent with the torrc and ondisk files for easy interoperability like Base64 of the private key(I haven't check to see what encoding is used for on disk EdDSAkeys, I assume PEM).Unfortunately not, it is custom to tor I believe with this 32 bytesheader:"== ed25519v1-secret: type0 ==\0\0\0"... followed by the private key (64 bytes). Seecrypto_write_tagged_contents_to_file().Not sure we can change that within the 032 freeze. So the approachwould 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 0Considering the current situation with the encoded file on disk ofthe key, I think this is kind of the simplest approach?Show Quoted ContentOk fun! I'll add this. Good catch! And control-spec.txt should beupdated.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 actuallyuse something that's sensible and consistent with the torrc and ondisk files for easy interoperability like Base64 of the private key(I haven't check to see what encoding is used for on disk EdDSAkeys, I assume PEM).Unfortunately not, it is custom to tor I believe with this 32 bytesheader:"== ed25519v1-secret: type0 ==\0\0\0"... followed by the private key (64 bytes). Seecrypto_write_tagged_contents_to_file().Not sure we can change that within the 032 freeze. So the approachwould 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 0Considering the current situation with the encoded file on disk ofthe key, I think this is kind of the simplest approach?Ok fun! I'll add this. Good catch! And control-spec.txt should beupdated.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 actuallyuse something that's sensible and consistent with the torrc and ondisk files for easy interoperability like Base64 of the private key(I haven't check to see what encoding is used for on disk EdDSAkeys, I assume PEM).Unfortunately not, it is custom to tor I believe with this 32 bytesheader:"== ed25519v1-secret: type0 ==\0\0\0"... followed by the private key (64 bytes). Seecrypto_write_tagged_contents_to_file().Not sure we can change that within the 032 freeze. So the approachwould 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 0Considering the current situation with the encoded file on disk ofthe key, I think this is kind of the simplest approach?
Yeah. Just the Base64ed private key (excluding that header and things)
seems reasonable.