Proposal 284: Hidden Service v3 Control Port
Hi everyone, Attached is the proposal draft for the hidden service v3 contro port specification. The idea with this proposal is to _only_ extend the current commands and events to v3. Nothing new is added. We can think of more things to add after but for now, I wanted a baseline to start with that is only extending what exists. Any kind of feedbacks is welcome! :) Cheers! David -- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ=
Hey David, Are there any ways of revoking a service's key and should it be included as a control port function? For example, in the case that the master key is kept offline but the host and its descriptor signing key are compromised, the box could be run for a period of time(?) until the keys expire and need to be re-signed. That window could be forcefully closed remotely with a revocation that reports that key as compromised. I don't know how big that window is so I don't know how big of a risk it ends up being. @ On Mon, Nov 6, 2017 at 9:59 AM David Goulet <dgoulet@ev0ke.net> wrote:
Hi everyone,
Attached is the proposal draft for the hidden service v3 contro port specification.
The idea with this proposal is to _only_ extend the current commands and events to v3. Nothing new is added. We can think of more things to add after but for now, I wanted a baseline to start with that is only extending what exists.
Any kind of feedbacks is welcome! :)
Cheers! David
-- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 06 Nov (15:44:26), AntiTree wrote:
Hey David,
Are there any ways of revoking a service's key and should it be included as a control port function? For example, in the case that the master key is kept offline but the host and its descriptor signing key are compromised, the box could be run for a period of time(?) until the keys expire and need to be re-signed. That window could be forcefully closed remotely with a revocation that reports that key as compromised. I don't know how big that window is so I don't know how big of a risk it ends up being.
To have a revocation system like that, we need some sort of mechanism that remembers revoked keys at maybe the directory level of as a complete new entity that keeps a registry of those. We do not have a way to do that nor a proposal for it :S... David
@
On Mon, Nov 6, 2017 at 9:59 AM David Goulet <dgoulet@ev0ke.net> wrote:
Hi everyone,
Attached is the proposal draft for the hidden service v3 contro port specification.
The idea with this proposal is to _only_ extend the current commands and events to v3. Nothing new is added. We can think of more things to add after but for now, I wanted a baseline to start with that is only extending what exists.
Any kind of feedbacks is welcome! :)
Cheers! David
-- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ= _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
Hi David, great proposal! Sorry I'm juggling too many things right now to really really review it. Quick skim though looks great. One quick thought is that the HS_DESC event has an optional positional argument (DescriptorID). This is fine *but* I'd advise against it since it will prevent you from ever adding more positional arguments in the future. Making it a key=value argument instead sidesteps this. On Mon, Nov 6, 2017 at 6:59 AM, David Goulet <dgoulet@ev0ke.net> wrote:
Hi everyone,
Attached is the proposal draft for the hidden service v3 contro port specification.
The idea with this proposal is to _only_ extend the current commands and events to v3. Nothing new is added. We can think of more things to add after but for now, I wanted a baseline to start with that is only extending what exists.
Any kind of feedbacks is welcome! :)
Cheers! David
-- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ=
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 06 Nov (10:15:18), Damian Johnson wrote:
Hi David, great proposal! Sorry I'm juggling too many things right now to really really review it. Quick skim though looks great. One quick thought is that the HS_DESC event has an optional positional argument (DescriptorID). This is fine *but* I'd advise against it since it will prevent you from ever adding more positional arguments in the future. Making it a key=value argument instead sidesteps this.
What do you propose exactly? I can't really change the "DescriptorID" to a key=value format. So, you think I should just not extend that field and use a new "key=value" for it? Thanks! David
On Mon, Nov 6, 2017 at 6:59 AM, David Goulet <dgoulet@ev0ke.net> wrote:
Hi everyone,
Attached is the proposal draft for the hidden service v3 contro port specification.
The idea with this proposal is to _only_ extend the current commands and events to v3. Nothing new is added. We can think of more things to add after but for now, I wanted a baseline to start with that is only extending what exists.
Any kind of feedbacks is welcome! :)
Cheers! David
-- Zu3IyL4LcdnKNkQIZqEqaTNUapUEJFdEcN02dPwo5FQ=
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
What do you propose exactly?
Hi David. What I mean is that having an optional positional field... MyEvent Field1 Field2 [Field3] Key1=Value1 ... means we cannot ever add more positional fields in the future. For example... MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1 ... would be ambiguous if the third field is Field3 or Field4 since they're both optional. We also could not add new mandatory positional fields... MyEvent Field1 Field2 Field4 [Field3] Key1=Value1 ... because it would be ambiguous if the third field was Field4 with a new version of tor or Field3 with an old one.
I can't really change the "DescriptorID" to a key=value format. So, you think I should just not extend that field and use a new "key=value" for it?
Why not? Does the DescriptorID have equal signs in it? If so then you could also make this be a mandatory positional field with a filler value like 'none' if unavailable. Cheers! -Damian
On 07 Nov (09:40:36), Damian Johnson wrote:
What do you propose exactly?
Hi David. What I mean is that having an optional positional field...
MyEvent Field1 Field2 [Field3] Key1=Value1
... means we cannot ever add more positional fields in the future. For example...
MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1
... would be ambiguous if the third field is Field3 or Field4 since they're both optional. We also could not add new mandatory positional fields...
MyEvent Field1 Field2 Field4 [Field3] Key1=Value1
... because it would be ambiguous if the third field was Field4 with a new version of tor or Field3 with an old one.
I can't really change the "DescriptorID" to a key=value format. So, you think I should just not extend that field and use a new "key=value" for it?
Why not? Does the DescriptorID have equal signs in it? If so then you could also make this be a mandatory positional field with a filler value like 'none' if unavailable.
Oh! I guess we aren't breaking backward compat. by changing DescriptorID field because it is optional in the first place so all future version will simply never use it and only use the new "DescriptorID=<value>" field instead. Thanks! David
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
On 07 Nov (12:47:43), David Goulet wrote:
On 07 Nov (09:40:36), Damian Johnson wrote:
What do you propose exactly?
Hi David. What I mean is that having an optional positional field...
MyEvent Field1 Field2 [Field3] Key1=Value1
... means we cannot ever add more positional fields in the future. For example...
MyEvent Field1 Field2 [Field3] [Field4] Key1=Value1
... would be ambiguous if the third field is Field3 or Field4 since they're both optional. We also could not add new mandatory positional fields...
MyEvent Field1 Field2 Field4 [Field3] Key1=Value1
... because it would be ambiguous if the third field was Field4 with a new version of tor or Field3 with an old one.
I can't really change the "DescriptorID" to a key=value format. So, you think I should just not extend that field and use a new "key=value" for it?
Why not? Does the DescriptorID have equal signs in it? If so then you could also make this be a mandatory positional field with a filler value like 'none' if unavailable.
Oh! I guess we aren't breaking backward compat. by changing DescriptorID field because it is optional in the first place so all future version will simply never use it and only use the new "DescriptorID=<value>" field instead.
Not entirely true actually, if we do that, the old Stem won't be able to pickup the descriptor ID from new Tor... So how do you suggest to proceed with backward compat? Just a new field like "DESCRIPTOR_ID=" and we leave the "DescriptorID" in duplicating the information for v2 descriptors? Kinda seems weird. David
Thanks! David
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
Not entirely true actually, if we do that, the old Stem won't be able to pickup the descriptor ID from new Tor... So how do you suggest to proceed with backward compat? Just a new field like "DESCRIPTOR_ID=" and we leave the "DescriptorID" in duplicating the information for v2 descriptors? Kinda seems weird.
Hi David. Meejah was right that there seems to be a misunderstanding here. I only commented about it because the DESCRIPTOR_ID was part of your proposal. If it's just citing an existing part of the spec then no worries. :)
Damian Johnson <atagar@torproject.org> writes:
What do you propose exactly?
Hi David. What I mean is that having an optional positional field...
I think the missing fact here is that there is *already* the DescriptorID field and it's already optional (in the current control-spec). -- meejah
David Goulet <dgoulet@ev0ke.net> writes:
On 06 Nov (10:15:18), Damian Johnson wrote:
Hi David, great proposal! Sorry I'm juggling too many things right now to really really review it. Quick skim though looks great. One quick thought is that the HS_DESC event has an optional positional argument (DescriptorID). This is fine *but* I'd advise against it since it will prevent you from ever adding more positional arguments in the future. Making it a key=value argument instead sidesteps this.
What do you propose exactly? I can't really change the "DescriptorID" to a key=value format. So, you think I should just not extend that field and use a new "key=value" for it?
Ahhh, I see what you mean: DescriptorID is *already* in the spec for HS_DESC as an (optional) positional argument -- you're just extending it to accept possibly more characters? So, yes, just making it "possibly bigger" is fine IMO. In other words, we've already baked into the spec the thing Damian doesn't want (an optional positional arg) so there's not really any way out of that. -- meejah
David Goulet <dgoulet@ev0ke.net> writes: Hi David, Overall looks good! A few comments inline:
"onions/{current,detached}" No change. This command can support v3 hidden service without changes returning v3 address(es).
Does the control-spec need a note pointing out that you might get some "longer" (v3) addresses?
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?) or "NEW:ED25519-V3" for explicitly asking for a V3 key, or "ED25519-V3:<56 base32 chars>" for adding an already-existing v3 service.
Because client authentication is not yet implemented, the "ClientAuth" field is ignored as well as "Flags=BasicAuth".
I think these should generate a 500-level error (if used for a v3 service) instead of being ignored. That is, if you try to use auth with v3, you get an error.
For this event to support vesrion 3, one optional field and new values are added:
I echo Damian's comments on the positional-arg; making it [SP "DescriptorID=" ] or similar (i.e. an optional kwarg) would mean easier later extending and also it *should* then "just work" with most controller libs already at least as far as parsing goes (because controller libs in general have to accept new, unknown kwargs). The rest all sounds good to me! thanks, meejah
On 06 Nov (22:35:32), meejah wrote:
David Goulet <dgoulet@ev0ke.net> writes:
Hi David,
Overall looks good! A few comments inline:
"onions/{current,detached}" No change. This command can support v3 hidden service without changes returning v3 address(es).
Does the control-spec need a note pointing out that you might get some "longer" (v3) addresses?
Yes, once this proposal is merged to control-spec.txt, it will mention it for sure what to expect.
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?) 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.
Because client authentication is not yet implemented, the "ClientAuth" field is ignored as well as "Flags=BasicAuth".
I think these should generate a 500-level error (if used for a v3 service) instead of being ignored. That is, if you try to use auth with v3, you get an error.
Indeed. I'm unsure between "512 Syntax error in command argument" "552 Unrecognized entity" [A configuration key, a stream ID, circuit ID, event, mentioned in the command did not actually exist.] But overall yes!
For this event to support vesrion 3, one optional field and new values are added:
I echo Damian's comments on the positional-arg; making it [SP "DescriptorID=" ] or similar (i.e. an optional kwarg) would mean easier later extending and also it *should* then "just work" with most controller libs already at least as far as parsing goes (because controller libs in general have to accept new, unknown kwargs).
See other thread about this. Big thanks! David
The rest all sounds good to me!
thanks, meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- 1ThD0Y7lJWfAN3qxos27iPGUdHQS5sZ4kMwlov3un5k=
David Goulet <dgoulet@ev0ke.net> writes:
Indeed.
I'm unsure between "512 Syntax error in command argument"
"552 Unrecognized entity" [A configuration key, a stream ID, circuit ID, event, mentioned in the command did not actually exist.]
But overall yes!
It looks like the previous code would have done a 512 (when ADD_ONION existed but didn't support authentication yet) so that's probably good here too. ...but, maybe "513 Unrecognized command argument" would be a good candidate, too? ...or even a new one for this case (and future cases) of "recognized, but not yet supported". "560 Not yet implemented" or similar? -- meejah
David Goulet <dgoulet@ev0ke.net> writes:
To be consistent then we could ask for a <Base64 Blob> as well:
"ED25519-V3:<Base64 Blob>"
... which contains the ed25519 private key.
Maybe it's too late, but it would be nice if the hs_ed25519_secret_key file was encoded in base64 as well (instead of binary) to facilitate copying them (if, e.g. you're upgrading from an on-disk v3 service to an ADD_ONION v3 service) cheers, -- meejah
On 8 Nov 2017, at 04:20, David Goulet <dgoulet@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.
On Tue, 7 Nov 2017 12:20:15 -0500 David Goulet <dgoulet@ev0ke.net> 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
On 09 Nov (09:27:15), Yawning Angel wrote:
On Tue, 7 Nov 2017 12:20:15 -0500 David Goulet <dgoulet@ev0ke.net> 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.)
Oh I didn't spot that far away from the "KeyBlob" :).
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? Cheers! David
Regards,
-- Yawning Angel
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=
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 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. -- Yawning Angel
On 10 Nov 2017, at 03:17, Yawning Angel <yawning@schwanenlied.me> wrote:
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 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
On 10 Nov (04:06:55), teor wrote:
On 10 Nov 2017, at 03:17, Yawning Angel <yawning@schwanenlied.me> wrote:
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 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.)
It follows the tor base64 API so basically padding is added when encoding and padding or not when decoding is working. Because we know the size of the keys, tor expects a specific byte size (padding or not). This is what the RSA base64 encoding/decoding does. David
T
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- jwMAzSbdAk2gz6mB7hJP3u/fieOzZS9dPqwPXXmyVoc=
participants (7)
-
AntiTree -
Damian Johnson -
David Goulet -
David Goulet -
meejah -
teor -
Yawning Angel