Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[s7r]

Thanks Lunar for bringing this into discussion. See below.

David Goulet wrote:
> On 06 Dec (17:23:10), Lunar wrote:
>> Hi!
>>
>> Sorry to be late to the party. I still haven't seen UX concerns fully
>> addressed, and I think we should not create a specification that will
>> make the life of our users harder if we can avoid it.
> 
> I believe it can be addressed by a good UI in TBB mostly to fit this client
> authorization proposal. Answers below.
> 
>>
>> s7r:
>>> George Kadianakis wrote:
 I have a more mature torspec branch now for your eyes and only.  Please
 see branch `prop224_client_auth_4` in my torspec repo:

 https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4

 The changes are based on the feedback and discussion on this thread.
>>>
>>> I would like to state, since I seen it in older posts on this thread,
>>> that I dislike the idea of generating at client side low entropy ed25519
>>> key pairs based on simple passwords. It may sound simple and good from
>>> UX point of view, but we are decreasing the security of a very secure
>>> auth scheme with it and enabling an over-the-hand practice that keys
>>> come from client to HS and not vice-versa.
>>
>> I hope we can find a balance between “a very secure auth scheme” that
>> will be too cumbersome to use for most users and “a secure and usable
>> auth scheme”.
>>
>> I've been hoping we could get a nice UI in Tor Browser to access
>> authenticated onion services for a while now (#8000). The difficult part
>> UX-wise is that there is no way to differentiate between an onion
>> service that is either non-existant, temporary unavailable or
>> authenticated. (But it's good for security, so let's keep things that
>> way.)
>>
>> How are users expected to give enter the private key in Tor Browser?
>> Does the key have to be saved on disk? What should I have to do to
>> browse an authenticated onion service when running under Tails without
>> persistence enabled?
> 
> We thought about this a bit (maybe not in depth) but the idea here is that an
> HS operator will have a choice between creating an authentication token for a
> specific client or add one that a client gave it to her.
> 

At client side, the private keys have to be saved on disk (in plain text
if we want to provide a simpler UX, because either way I don't think we
can make it as simple as we'd like).

> For a client, we kept the "token" to be a one liner containing the key
> material and an identifier. So it becomes a matter of "How the client
> generates that token?" and "How it is exchanged between client and operator?"
> I think the way to go here is for sure an integration in TBB.
> 
> First option would be for a user to enter a password and the keys are derived
> from it and we output the one line that the user should give to the HS
> operator. If the HS operator already have that line configured in, well great,
> it addresses the Tails use case where you move around and you simply need to
> input your password to get the right token that you've already gave to the HS.
> 

I agree here. This becomes a problem when the same user has multiple
authenticated HSes. She has to either remember a different password
linked to every authorized HS - which is bad for UX, either use a single
password for all of them, to keep things easy. If users choose simple
passwords, which people are inclined to do, brute-forcing the auth
credentials for adversaries that know the onion hostname will become
trivial and will defeat the purpose of authentication.

> The second option would be to "Generate token for me", output the line and
> give out-of-band to HS operator that one liner.
> 
> And the third option would be to "Enter token here" which is the case where HS
> operator gives out token to client.
> 
> All those are a UI challenge but I think will be _great_ improvement to the
> current state of things but they are all on TBB side.
> 

Yes, second and third options are not something human memorable or
easily reproductive, and will not survive a re-install without backup or
suite the 'amnesic' mode users.

Here's a wild idea:

We generate the key client side using a string of words, that are human
memorable and when entered again will produce the same key. I think such
a system would work at large scale. The key produced here will be the
master key.

To solve the challenge of mapping onion hostnames to tokens, eliminate
the need to use the same token for all authorized HS and also kind of
fix the issue when we don't know which HS uses auth or not, we derive
child keys from the master key for each onion hostname.

Client and server need to compute the same child key in every case, so
the derivation key will be the HS full onion hostname itself.

Example:
token for foo.onion =  -> 
token for abc.onion =  -> 

Benefits:
- users share a single master public key with servers which is easier
and also use different credentials for each HS. They can even 

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[David Goulet]

On 06 Dec (17:23:10), Lunar wrote:
> Hi!
> 
> Sorry to be late to the party. I still haven't seen UX concerns fully
> addressed, and I think we should not create a specification that will
> make the life of our users harder if we can avoid it.

I believe it can be addressed by a good UI in TBB mostly to fit this client
authorization proposal. Answers below.

> 
> s7r:
> > George Kadianakis wrote:
> > > I have a more mature torspec branch now for your eyes and only.  Please
> > > see branch `prop224_client_auth_4` in my torspec repo:
> > >
> > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4
> > > 
> > > The changes are based on the feedback and discussion on this thread.
> >
> > I would like to state, since I seen it in older posts on this thread,
> > that I dislike the idea of generating at client side low entropy ed25519
> > key pairs based on simple passwords. It may sound simple and good from
> > UX point of view, but we are decreasing the security of a very secure
> > auth scheme with it and enabling an over-the-hand practice that keys
> > come from client to HS and not vice-versa.
> 
> I hope we can find a balance between “a very secure auth scheme” that
> will be too cumbersome to use for most users and “a secure and usable
> auth scheme”.
> 
> I've been hoping we could get a nice UI in Tor Browser to access
> authenticated onion services for a while now (#8000). The difficult part
> UX-wise is that there is no way to differentiate between an onion
> service that is either non-existant, temporary unavailable or
> authenticated. (But it's good for security, so let's keep things that
> way.)
> 
> How are users expected to give enter the private key in Tor Browser?
> Does the key have to be saved on disk? What should I have to do to
> browse an authenticated onion service when running under Tails without
> persistence enabled?

We thought about this a bit (maybe not in depth) but the idea here is that an
HS operator will have a choice between creating an authentication token for a
specific client or add one that a client gave it to her.

For a client, we kept the "token" to be a one liner containing the key
material and an identifier. So it becomes a matter of "How the client
generates that token?" and "How it is exchanged between client and operator?"
I think the way to go here is for sure an integration in TBB.

First option would be for a user to enter a password and the keys are derived
from it and we output the one line that the user should give to the HS
operator. If the HS operator already have that line configured in, well great,
it addresses the Tails use case where you move around and you simply need to
input your password to get the right token that you've already gave to the HS.

The second option would be to "Generate token for me", output the line and
give out-of-band to HS operator that one liner.

And the third option would be to "Enter token here" which is the case where HS
operator gives out token to client.

All those are a UI challenge but I think will be _great_ improvement to the
current state of things but they are all on TBB side.

One thing that we unfortunately can't solve is the "give token to HS operator
automagically", it has to be out-of-band else we are getting into another
world of complexity. HOWEVER, we could think of a proposal to have some sort
of "Auth Server Transport" support which you could tell your tor to fetch
token from that "auth server" but that is some big piece of work.

> 
> I don't see how to streamline support for an amnesic system if I have to
> generate a unique keypair that I need to give to the onion service
> owner beforehand.

To be honest, it would be quite amazing to pull off a TBB UI for this at the
same time as we roll out prop224 in a tor stable :) with the use case of
amnesic system.

> 
> Should we draw inspiration from miniLock?
> https://minilock.io/files/HOPEX.pdf (see slide 35)
> 
> If I try to think of my experience as an admin, I see several cases
> where it would be much easier to give authentication token to users
> myself. User story:
> 
> Elena has set up an Etherpad instance on her private server. She
> generates a handful of access codes before going to meet the newly
> formed copwatch chapter. After the end of the meeting, she can give
> out a piece of paper to all attendees so they can access the minutes
> and write up reports together in the future.
> 
> You really don't want to have all attendees bring their computer or
> require them to meet with Elena at a later time.

Yeah... the client token I've been talking about is a bit long actually but we
have to to ensure some semblance of modern security that is ECC keys of 32
bytes.

However, what we could do server side is generate a client key associated with
some keywords that if put in TBB UI would generate same client key (a bit like
pond does with the words).

Thanks for the feedback!
David

> 
> Hope that 

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[Lunar]

Hi!

Sorry to be late to the party. I still haven't seen UX concerns fully
addressed, and I think we should not create a specification that will
make the life of our users harder if we can avoid it.

s7r:
> George Kadianakis wrote:
> > I have a more mature torspec branch now for your eyes and only.  Please
> > see branch `prop224_client_auth_4` in my torspec repo:
> >
> > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4
> > 
> > The changes are based on the feedback and discussion on this thread.
>
> I would like to state, since I seen it in older posts on this thread,
> that I dislike the idea of generating at client side low entropy ed25519
> key pairs based on simple passwords. It may sound simple and good from
> UX point of view, but we are decreasing the security of a very secure
> auth scheme with it and enabling an over-the-hand practice that keys
> come from client to HS and not vice-versa.

I hope we can find a balance between “a very secure auth scheme” that
will be too cumbersome to use for most users and “a secure and usable
auth scheme”.

I've been hoping we could get a nice UI in Tor Browser to access
authenticated onion services for a while now (#8000). The difficult part
UX-wise is that there is no way to differentiate between an onion
service that is either non-existant, temporary unavailable or
authenticated. (But it's good for security, so let's keep things that
way.)

How are users expected to give enter the private key in Tor Browser?
Does the key have to be saved on disk? What should I have to do to
browse an authenticated onion service when running under Tails without
persistence enabled?

I don't see how to streamline support for an amnesic system if I have to
generate a unique keypair that I need to give to the onion service
owner beforehand.

Should we draw inspiration from miniLock?
https://minilock.io/files/HOPEX.pdf (see slide 35)

If I try to think of my experience as an admin, I see several cases
where it would be much easier to give authentication token to users
myself. User story:

Elena has set up an Etherpad instance on her private server. She
generates a handful of access codes before going to meet the newly
formed copwatch chapter. After the end of the meeting, she can give
out a piece of paper to all attendees so they can access the minutes
and write up reports together in the future.

You really don't want to have all attendees bring their computer or
require them to meet with Elena at a later time.

Hope that helps,
-- 
Lunar 


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

George Kadianakis  writes:

> Nick Mathewson  writes:
>
>> [ text/plain ]
>> Hi!  I thought I'd write this up while it was fresh in my mind.  It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism.  We could implement both, or just this, or
>> just the other.
>>
>> My description here will be a bit terser than we'd want in a proper
>> proposal, but I wanted to share it.
>>
>> This design is based on George Kadianakis's client authentication
>> design; it won't make sense unless you've read it.
>>
>
> OK people,
>
> I have a more mature torspec branch now for your eyes and only.  Please
> see branch `prop224_client_auth_4` in my torspec repo:
>
> https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4
>
> The changes are based on the feedback and discussion on this thread.
>
> The only real changes from `prop224_client_auth_3` is that it increases
> the max descriptor size to 50k, and it removes the username/password
> intro-level authorization.
>
> Please let me know of anything that seems off, or anything that can make
> the proposal more readable. Otherwise, we should merge this upstream and
> move forward with fixing the already merged prop224 HSDir code.
>
> Thanks!

Hello,

I merged the above patch to torspec.git.

Thanks for the feedback and helpful comments everyone!



___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[s7r]

Hello,

George Kadianakis wrote:
> Nick Mathewson  writes:
> 
>> [ text/plain ]
>> Hi!  I thought I'd write this up while it was fresh in my mind.  It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism.  We could implement both, or just this, or
>> just the other.
>>
>> My description here will be a bit terser than we'd want in a proper
>> proposal, but I wanted to share it.
>>
>> This design is based on George Kadianakis's client authentication
>> design; it won't make sense unless you've read it.
>>
> 
> OK people,
> 
> I have a more mature torspec branch now for your eyes and only.  Please
> see branch `prop224_client_auth_4` in my torspec repo:
>
> https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4
> 
> The changes are based on the feedback and discussion on this thread.
> 
> The only real changes from `prop224_client_auth_3` is that it increases
> the max descriptor size to 50k, and it removes the username/password
> intro-level authorization.
> 
> Please let me know of anything that seems off, or anything that can make
> the proposal more readable. Otherwise, we should merge this upstream and
> move forward with fixing the already merged prop224 HSDir code.
> 
> Thanks!

It is very good. The hard limit raised to 50k is justified, and
excellent to remove the username/password intro-level authorization.

I would like to state, since I seen it in older posts on this thread,
that I dislike the idea of generating at client side low entropy ed25519
key pairs based on simple passwords. It may sound simple and good from
UX point of view, but we are decreasing the security of a very secure
auth scheme with it and enabling an over-the-hand practice that keys
come from client to HS and not vice-versa.

My 2 cents here are that keys should always be generated randomly by the
HS server, and distributed to clients (I think it's over the hand for
the HS server to use keys generated by clients, because the purpose is
for the HS server to secure itself against _everyone_ except some
users). For this I am thinking of a very simple tool, that reads the
auth-client data file in $DataDirectory/ that will just show a table like:

[ADD A CLIENT]
HS | client | pubkey | privkey | notes| actions | date
   [revoke] [change key]

(of course available in console mode also with keyboard shortcuts for
commands)

Since we have no real reason to see the privkey of a client ever again
at the HS server side (unless the client loses it, but in this case we
regenerate fresh keys for security reasons), client privkeys can not be
written to disk at HS server side.

For saved authorized clients we display "**" on privkey column. When
a client is added, highlight the row with red or something signaling
privkey distribution phase and only keep the keys in RAM. After the
privkey has been copied and user checked a box with 2 confirmation
dialogs that state something like "I have distributed the key to the
client and i understand that it will be permanently deleted, and I could
need to regenerate the key for this client if he didn't get it." save
the pubkey, client name, etc to file and permanently delete the privkey.

If anything happens (client manager app is closed, power failure,
reboot, etc.) start over with new key pair. Same when a key for a client
needs to change, we only keep the client name from the table and create
fresh key following the same protocol.

The client mode of the auth tool will look like:

[ADD An ONION]
HS | notes | privkey | actions | date
  [delete] [change key]

(of course available in console mode also with keyboard shortcuts for
commands)

Here the auth tool will only append/modify data from client's torrc.

It's OK to save the privkeys in plain text at client side from my point
of view. We could do encryption with a passphrase but it will be
annoying: either the auth management tool needs to be a plugin of Tor
Browser so that it asks for the passphrase only one time on start /
first connection (otherwise is _very_ annoying for UX) - not everyone
uses Tor Browser and more important not everyone uses HS for web
browsing - maybe it's a ssh server, either the tool itself needs to run
in background all the time.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

Nick Mathewson  writes:

> [ text/plain ]
> Hi!  I thought I'd write this up while it was fresh in my mind.  It
> could be used as an alternative method to the current proposed client
> authentication mechanism.  We could implement both, or just this, or
> just the other.
>
> My description here will be a bit terser than we'd want in a proper
> proposal, but I wanted to share it.
>
> This design is based on George Kadianakis's client authentication
> design; it won't make sense unless you've read it.
>

OK people,

I have a more mature torspec branch now for your eyes and only.  Please
see branch `prop224_client_auth_4` in my torspec repo:
   
https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4

The changes are based on the feedback and discussion on this thread.

The only real changes from `prop224_client_auth_3` is that it increases
the max descriptor size to 50k, and it removes the username/password
intro-level authorization.

Please let me know of anything that seems off, or anything that can make
the proposal more readable. Otherwise, we should merge this upstream and
move forward with fixing the already merged prop224 HSDir code.

Thanks!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[Nima Fatemi]

> - I feel that the max settings imposed by the 50k max size limit, will satisfy
>   most crazy hidden service use cases that someone might have wrt scalability
>   or number of authed clients. It can support up to 350 authed clients, and 20
>   intro points. We should increase the max size limit, if we want to support
>   more advanced use cases.
> 
> - I also feel the configurations that fit in the default descriptor (of 10k
>   bytes blob) will probably satisfy most hidden service use cases out there as
>   it can support up to 80 authed clients, and up to 11 intro points.  The
>   anonymity set of those hidden services descriptors will be good wrt 
> snooping HSDirs
> 
> - Giant hidden service descriptors will stand out and their anonymity set will
>   likely be small. I think such giant hidden services should perhaps split
>   their info to multiple descriptors using some sort of stealth-auth mechanism
>   (where they give different onion address to different clients).
>   Alternatively, we should change our padding rules, or always pad to max
>   descriptor size.

I understand what I'm saying below might be a bit far fetched but while
we're brainstorming on things, I thought I'd just throw this out...

I think it would be interesting to see things like onion-balance get
integrated into this setup at some point in the long run, so if there's
a giant onion service, it would automatically scale after a certain
amount of clients or requests. I haven't thought much about how it can
work in auth mechanism but I find it an interesting subject to think
about. Specially if we want to mainstream the heavy use of onion services.

Kudos for working on such important properties of Tor.

Cheers,
-- 
Nima
0X58C4B928A3E218F6 | @mrphs

"I disapprove of what you say, but I will defend to the death your right
to say it" --Evelyn Beatrice Hall



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

David Goulet  writes:

> [ text/plain ]
> On 15 Nov (16:29:33), George Kadianakis wrote:
>> Nick Mathewson  writes:
>> 
>> 
>> 
>> Hello,
>> 
>> I worked some more on prop224 client authorization. I have a draft
>> torspec patch at prop224_client_auth_3 in my repo:
>> 
>> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_3
>
> I personally like this very much. Apart from minor syntax issues and spacing,
> I think this scheme is getting to a point where it's simple and efficient.
>
> I think the introduce auth section (INTRO-AUTH) needs to be edited more though
> because we are still mentionning password and ed25519 authentication but I
> understand that waiting until we all agree on the client auth mechanism is
> wise.
>
>> 
>> I ended up using the x25519 scheme described above by Nick.
>> 
>> I also ended up dodging the UX questions raised on this thread, by only
>> specifying the Tor protocol level details, and leaving the out-of-band
>> HS<->client protocol mostly unspecified. I believe that this out-of-band
>> protocol and configuration details can be figured out in the future, and
>> we should not block on them right now.
>
> Yes, I believe this is fine. Note that tor-keygen tool is getting another
> _very_ important use case here that is the key generation on client side.
>
>> 
>> I also added some more high-level details on client auth in the intro
>> section, which should be useful to people who read the proposal for the
>> first time.
>> 
>> In the appendix, I added a section with some rough ideas on how the
>> torrc configuration could work, and how a control port interface could
>> work. This is just a sketch so far, and we can get more specific as we
>> get closer to implementation fot this feature.
>
> Looks good to me. The naming will _most_ probably change as we already have
> those names in torrc with a different API but the format to me is simple and
> easy to use.
>
> And the control port commands are _very_ important as it would allow TBB to
> easily add client auth with some UI instead of hot hacking torrc file. And
> this would be a giant step foward in usability of client auth.
>
>> 
>> Finally, I've been assuming AES128 for the STREAM() cipher so that the
>> size computations performed earlier on this thread are still
>> accurate. If we want to pump it to AES256, the IVs and the descriptor
>> cookie ciphertexts will double in size for each authorized client. If we
>> actually want to go with AES256, we need to peform new computations
>> about the padding and max descriptor size. If you people like the rest
>> of the patch here, I can do the calculations again. 
>
> Which might also change our maximum size of 40k we put there.
>
> One note. I haven't seen a maximum value of client we allow. Did I miss it or
> it's also maybe too early to put there as we are still discussing the
> specifics. Which makes me think that maybe that 40k limit is also a bit
> arbitrary for now based on that.
>

Hello,

I understand your concern, and hence I performed the descriptor size
calculations again based on the encoding format of the latest branch
(prop224_client_auth_3). You asked for it!

First of all, in the end of this email I inline a real prop224 HS descriptor
based on the prop224_client_auth_3 torspec branch, and _without any encryption_.
Use that descriptor as a guidance, or to double-check my calculations.

To cut to the chase, here are my current recommendations regarding descriptor
padding and maximum size:

- The superencrypted blob (between "superencrypted\n-BEGIN MESSAGE-"
  and "-END MESSAGE-") should be padded with NULs to the nearest
  multiple of 10k bytes before it gets encrypted and base64ed. This is the same
  as what is specified in prop224_client_auth3.

- Max total descriptor size accepted by HSDirs is 50k bytes. We should also
  control this with a consensus parameter, in case it ever ends up being too
  small or too big. In prop224_client_auth_3 it is suggested that the max size
  should be 40k bytes, but actually I think 50k bytes is a better number given
  the new scheme and the 10k padding. Please see below.

- We always add fake "auth-client" entries to reach the nearest multiple of 16.

Now here are some observations:

a) The superencrypted blob gets padded to nearest multiple of 10k bytes before
   it gets base64ed. If you base64-encode 30k bytes you get back 40k base64
   bytes, which is basically the max size of superencrypted blob we can support
   if the max descriptor size is 50k bytes. The remaining 10k bytes are left
   for the unencrypted header (and footer) of the descriptor which in the
   example below is 400 bytes.

b) Every new intro point block adds about 615 bytes to the blob, whereas legacy
   intro points add about 870 bytes to the blob. For the sake of calculations,
   let's average that to 750 bytes per intro point.

   Every authed client adds 75 bytes to the 

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[teor]

> On 18 Nov. 2016, at 09:20, David Goulet  wrote:
> 
> On 18 Nov (08:27:53), teor wrote:
>> 
>>> On 18 Nov. 2016, at 03:52, David Goulet  wrote:
>>> 
 
 I ended up using the x25519 scheme described above by Nick.
 
 I also ended up dodging the UX questions raised on this thread, by only
 specifying the Tor protocol level details, and leaving the out-of-band
 HS<->client protocol mostly unspecified. I believe that this out-of-band
 protocol and configuration details can be figured out in the future, and
 we should not block on them right now.
>>> 
>>> Yes, I believe this is fine. Note that tor-keygen tool is getting another
>>> _very_ important use case here that is the key generation on client side.
>> 
>> The tor-keygen tool is not currently included in the Tor Browser bundle.
>> So we would have to add it (or provide an alternate method) for Tor Browser
>> users.
> 
> It also does not really exists :). But we have a ticket for it and it's
> very important also for HS offline keys!

Oh right, I had it confused with tor-gencert.

> And yes, I like you idea that TBB should have it included coupled with a
> nice UI for HS auth.

And the Tor Expert Bundle (Windows) so people can run HSs on Windows using
it.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[David Goulet]

On 18 Nov (08:27:53), teor wrote:
> 
> > On 18 Nov. 2016, at 03:52, David Goulet  wrote:
> > 
> >> 
> >> I ended up using the x25519 scheme described above by Nick.
> >> 
> >> I also ended up dodging the UX questions raised on this thread, by only
> >> specifying the Tor protocol level details, and leaving the out-of-band
> >> HS<->client protocol mostly unspecified. I believe that this out-of-band
> >> protocol and configuration details can be figured out in the future, and
> >> we should not block on them right now.
> > 
> > Yes, I believe this is fine. Note that tor-keygen tool is getting another
> > _very_ important use case here that is the key generation on client side.
> 
> The tor-keygen tool is not currently included in the Tor Browser bundle.
> So we would have to add it (or provide an alternate method) for Tor Browser
> users.

It also does not really exists :). But we have a ticket for it and it's
very important also for HS offline keys!

And yes, I like you idea that TBB should have it included coupled with a
nice UI for HS auth.

Cheers!
David

> T
> 
> -- 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> 
> 
> 
> 
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[teor]

> On 18 Nov. 2016, at 03:52, David Goulet  wrote:
> 
>> 
>> I ended up using the x25519 scheme described above by Nick.
>> 
>> I also ended up dodging the UX questions raised on this thread, by only
>> specifying the Tor protocol level details, and leaving the out-of-band
>> HS<->client protocol mostly unspecified. I believe that this out-of-band
>> protocol and configuration details can be figured out in the future, and
>> we should not block on them right now.
> 
> Yes, I believe this is fine. Note that tor-keygen tool is getting another
> _very_ important use case here that is the key generation on client side.

The tor-keygen tool is not currently included in the Tor Browser bundle.
So we would have to add it (or provide an alternate method) for Tor Browser
users.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[David Goulet]

On 15 Nov (16:29:33), George Kadianakis wrote:
> Nick Mathewson  writes:
> 
> > [ text/plain ]
> > Hi!  I thought I'd write this up while it was fresh in my mind.  It
> > could be used as an alternative method to the current proposed client
> > authentication mechanism.  We could implement both, or just this, or
> > just the other.
> >
> > My description here will be a bit terser than we'd want in a proper
> > proposal, but I wanted to share it.
> >
> > This design is based on George Kadianakis's client authentication
> > design; it won't make sense unless you've read it.
> >
> > =
> >
> > Let every client generate a curve25519 keypair, and tell the hidden
> > service operator about the public key.  This keypair takes the place
> > of the long-term shared secret.  For some client C, denote the secret
> > key as x_X and the public key as X_C.
> >
> > For every descriptor, the hidden service generates a fresh keypair  > Y>, and includes Y in the the outer encrypted layer.
> >
> > Now, for each client, the hidden service computes curve25519(X_C, y)
> > and uses this as the input for two KDF functions. Call these outputs
> > K1_C and K2_C.  The hidden service generates an auth-client line for
> > each client as follows:
> >
> >"auth-client" SP client-id SP encrypted-cookie
> >
> > This is the same as in George's proposal, except that client-id is
> > derived from a truncated version of K1_C, and the encrypted-cookie
> > portion is encrypted based on K2_C.
> >
> >
> > When the client receives the descriptor, it decrypts the outer layer,
> > then sees the value of Y that the hidden server advertised.  It
> > computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
> > to find the appropriate entry on the list, and then uses K2_C to
> > decrypt it and find the descriptor cookie.
> >
> > =
> >
> > Advantages:
> >   * managing public keys can be easier than managing shared secrets.
> >   * The encoding is slightly shorter, since no IV is needed, since K2
> > is different every time.
> >   * probably others?
> >
> > Disadvantages:
> >   * Curve25519 costs more computationally than non-public-key operations
> >   * probably others?
> >
> >
> 
> Hello,
> 
> I worked some more on prop224 client authorization. I have a draft
> torspec patch at prop224_client_auth_3 in my repo:
> 
> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_3

I personally like this very much. Apart from minor syntax issues and spacing,
I think this scheme is getting to a point where it's simple and efficient.

I think the introduce auth section (INTRO-AUTH) needs to be edited more though
because we are still mentionning password and ed25519 authentication but I
understand that waiting until we all agree on the client auth mechanism is
wise.

> 
> I ended up using the x25519 scheme described above by Nick.
> 
> I also ended up dodging the UX questions raised on this thread, by only
> specifying the Tor protocol level details, and leaving the out-of-band
> HS<->client protocol mostly unspecified. I believe that this out-of-band
> protocol and configuration details can be figured out in the future, and
> we should not block on them right now.

Yes, I believe this is fine. Note that tor-keygen tool is getting another
_very_ important use case here that is the key generation on client side.

> 
> I also added some more high-level details on client auth in the intro
> section, which should be useful to people who read the proposal for the
> first time.
> 
> In the appendix, I added a section with some rough ideas on how the
> torrc configuration could work, and how a control port interface could
> work. This is just a sketch so far, and we can get more specific as we
> get closer to implementation fot this feature.

Looks good to me. The naming will _most_ probably change as we already have
those names in torrc with a different API but the format to me is simple and
easy to use.

And the control port commands are _very_ important as it would allow TBB to
easily add client auth with some UI instead of hot hacking torrc file. And
this would be a giant step foward in usability of client auth.

> 
> Finally, I've been assuming AES128 for the STREAM() cipher so that the
> size computations performed earlier on this thread are still
> accurate. If we want to pump it to AES256, the IVs and the descriptor
> cookie ciphertexts will double in size for each authorized client. If we
> actually want to go with AES256, we need to peform new computations
> about the padding and max descriptor size. If you people like the rest
> of the patch here, I can do the calculations again. 

Which might also change our maximum size of 40k we put there.

One note. I haven't seen a maximum value of client we allow. Did I miss it or
it's also maybe too early to put there as we are still discussing the
specifics. Which makes me think that maybe that 40k limit is also a bit

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

Nick Mathewson  writes:

> [ text/plain ]
> Hi!  I thought I'd write this up while it was fresh in my mind.  It
> could be used as an alternative method to the current proposed client
> authentication mechanism.  We could implement both, or just this, or
> just the other.
>
> My description here will be a bit terser than we'd want in a proper
> proposal, but I wanted to share it.
>
> This design is based on George Kadianakis's client authentication
> design; it won't make sense unless you've read it.
>
> =
>
> Let every client generate a curve25519 keypair, and tell the hidden
> service operator about the public key.  This keypair takes the place
> of the long-term shared secret.  For some client C, denote the secret
> key as x_X and the public key as X_C.
>
> For every descriptor, the hidden service generates a fresh keypair  Y>, and includes Y in the the outer encrypted layer.
>
> Now, for each client, the hidden service computes curve25519(X_C, y)
> and uses this as the input for two KDF functions. Call these outputs
> K1_C and K2_C.  The hidden service generates an auth-client line for
> each client as follows:
>
>"auth-client" SP client-id SP encrypted-cookie
>
> This is the same as in George's proposal, except that client-id is
> derived from a truncated version of K1_C, and the encrypted-cookie
> portion is encrypted based on K2_C.
>
>
> When the client receives the descriptor, it decrypts the outer layer,
> then sees the value of Y that the hidden server advertised.  It
> computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
> to find the appropriate entry on the list, and then uses K2_C to
> decrypt it and find the descriptor cookie.
>
> =
>
> Advantages:
>   * managing public keys can be easier than managing shared secrets.
>   * The encoding is slightly shorter, since no IV is needed, since K2
> is different every time.
>   * probably others?
>
> Disadvantages:
>   * Curve25519 costs more computationally than non-public-key operations
>   * probably others?
>
>

Hello,

I worked some more on prop224 client authorization. I have a draft
torspec patch at prop224_client_auth_3 in my repo:

https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_3

I ended up using the x25519 scheme described above by Nick.

I also ended up dodging the UX questions raised on this thread, by only
specifying the Tor protocol level details, and leaving the out-of-band
HS<->client protocol mostly unspecified. I believe that this out-of-band
protocol and configuration details can be figured out in the future, and
we should not block on them right now.

I also added some more high-level details on client auth in the intro
section, which should be useful to people who read the proposal for the
first time.

In the appendix, I added a section with some rough ideas on how the
torrc configuration could work, and how a control port interface could
work. This is just a sketch so far, and we can get more specific as we
get closer to implementation fot this feature.

Finally, I've been assuming AES128 for the STREAM() cipher so that the
size computations performed earlier on this thread are still
accurate. If we want to pump it to AES256, the IVs and the descriptor
cookie ciphertexts will double in size for each authorized client. If we
actually want to go with AES256, we need to peform new computations
about the padding and max descriptor size. If you people like the rest
of the patch here, I can do the calculations again. 

Cheers!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[meejah]

George Kadianakis  writes:

> Also, it means that clients need to _securely_ send credentials to the
> HS operator and then they need to _wait_ till the HS operator adds
> those creds to Tor, before they are able to visit the HS.

One thing that might help here is Brian Warner's "magic wormhole"
(http://magic-wormhole.io) -- which supports Tor. This would answer the
"how to securely communicate the key" part, at the expense of both
parties needing to be online at the same time. Basically, instead of
exchanging the HS credentials directly, you'd share a "wormhole code"
which is a SPAKE2 one-time password.

If, for example, a controller library like txtorcon added support for
this, the HS operator (Bob) would run some command on their side
("invite alice") which would add credentials for Alice to Tor (via
ADD_ONION_CLIENT or something) and give Bob a "wormhole code". Bob gives
the code to Alice (ideally securely, but not nearly as critical here as
with "actual" keys), who would run something app-specific on their side
(e.g. "accept invitation") and type in the code they were given. The
command running on Bob's side would pass the actual HS credentials (via
the now-established wormhole) to Alice's running application (which then
also would use some controller command to add the client credentials to
their Tor instance).

So, neither Alice nor Bob ever actually see any keys at all.

> We should probably speak with people that use client auth to tell us
> if this UX will break their model.

+1
It would be great to know how people actually exchange these things
currently :)

-- 
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[meejah]

Regarding the API / interface for communicating client-keys for hidden-
services .. I thought we were encouraging ADD_ONION based services?

Personally, I think using the filesystem as "an API" isn't very
good. From a controller standpoint, it's *way* simpler to use ADD_ONION
properly than on-disc services (i.e. via SETCONF) because directory
permissions, file permissions etc have to line up and it's not
immediately clear if the files will always for-sure be on-disc when the
SETCONF command says OK. (Also, you have to deal with the one-shot
nature of SETCONF and order-matters configuration options)

On the disadvantage side, this means any applications using these
services are then responsible for their own key-management.

In any case, something like growing an "ADD_ONION_CLIENT" command or
similar might be way easier to understand and implement.

A flow might look something like this:

 - client creates a key(/pair) in tor-browser or whatever
 - client sends it to service operator ("exercise to the
   app-developer"?)
 - operator uses their controller to run "ADD_ONION_CLIENT"
 - ???
 - profit!
 
Definitely out-of-scope for "ng hidden-services", but it would also
probably be nice to have more separation in the control-protocol. Right
now, you get the authority to do anything at all -- but maybe you'd like
to give an application *just* the authority to "add hidden services
and/or clients". You can use a control-port-filtering thing
(e.g. roflcopter) to get something like this, but ... not ideal (and not
really the same as being able to grant limited authority to an
application).

I'm thinking here of scenarios where you have an application that wants
to "use Tor" to do service-stuff -- so "just edit the config" isn't a
satisfying answer at all. Also, having every app launch its own Tor
instance (which is about the only answer currently) seems bad.

-- 
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[teor]

> On 12 Nov. 2016, at 03:41, George Kadianakis  wrote:
> 
> teor  writes:
> 
>> [ text/plain ]
>> 
>>> On 11 Nov. 2016, at 04:18, George Kadianakis  wrote:
>>> 
>>> George Kadianakis  writes:
>>> 
 [ text/plain ]
 Nick Mathewson  writes:
 
> [ text/plain ]
> Hi!  I thought I'd write this up while it was fresh in my mind.  It
> could be used as an alternative method to the current proposed client
> authentication mechanism.  We could implement both, or just this, or
> just the other.
> 
> My description here will be a bit terser than we'd want in a proper
> proposal, but I wanted to share it.
> 
> This design is based on George Kadianakis's client authentication
> design; it won't make sense unless you've read it.
> 
> =
> 
> Let every client generate a curve25519 keypair, and tell the hidden
> service operator about the public key.  This keypair takes the place
> of the long-term shared secret.  For some client C, denote the secret
> key as x_X and the public key as X_C.
> 
> For every descriptor, the hidden service generates a fresh keypair  Y>, and includes Y in the the outer encrypted layer.
> 
> Now, for each client, the hidden service computes curve25519(X_C, y)
> and uses this as the input for two KDF functions. Call these outputs
> K1_C and K2_C.  The hidden service generates an auth-client line for
> each client as follows:
> 
>  "auth-client" SP client-id SP encrypted-cookie
> 
> This is the same as in George's proposal, except that client-id is
> derived from a truncated version of K1_C, and the encrypted-cookie
> portion is encrypted based on K2_C.
> 
> 
> When the client receives the descriptor, it decrypts the outer layer,
> then sees the value of Y that the hidden server advertised.  It
> computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
> to find the appropriate entry on the list, and then uses K2_C to
> decrypt it and find the descriptor cookie.
> 
> =
> 
> Advantages:
> * managing public keys can be easier than managing shared secrets.
> * The encoding is slightly shorter, since no IV is needed, since K2
> is different every time.
> * probably others?
> 
> Disadvantages:
> * Curve25519 costs more computationally than non-public-key operations
> * probably others?
> 
> 
 
 Hey Nick,
 
 thanks for the feedback on the torspec patch and this scheme. I'll wait
 to figure out if we want to use this scheme before updating the torspec
 patch further.
 
 This proposed scheme seems like a good idea. It basically switches the
 identity of authed clients from symmetric keys to x25519 keys, which
 seems more intuitive and correct.
 
 I wonder if clients could/should use the same keypair for intro-layer
 authentication as well. Section 3.4.2 currently specifies how to do
 intro-layer auth using ed25519 keys, so perhaps we can use a single
 curve25519 key (and switch it between ed25519 and x25519) to perform
 both descriptor-layer and intro-layer authentication?
 
 WRT the suggested scheme, I think my biggest concern here is the UX, and
 specifically this phrase
 
 "Let every client generate a curve25519 keypair, and tell the hidden
 service operator about the public key".
 
 The client auth UX currently involves the HS operator passing
 credentials to the clients, not the other way around. This is good for
 UX since it means that all configuration is performed by the HS operator
 (who can be assumed technical), instead of its clients (who should be
 assumed to be non-technical). All clients need to do is copy-paste the
 auth line to their torrc. I feel like this UX should be maintained,
 except if there is a very strong reason to break it.
 
>>> 
>>> OK, I think sooner or later we needed to have a UX discussion about HS
>>> client authorization!
>>> 
>>> The current rend-spec.txt specifies the torrc options for client auth in
>>> sections 2.3/2.4. We don't do this in prop224 yet, but I think it's
>>> useful because figuring out the torrc format now will help us understand
>>> if the scheme we are making is useful.
>>> 
>>> Here is a rough proposed UX for prop224 client auth, using Nick's idea
>>> from the top post of this thread. FWIW, I've used the same torrc option
>>> naming as we currently have but we should probably introduce new ones.
>>> 
>>> -- Hidden Service configuration
>>> 
>>> A hidden service uses the following torrc line to specify authed clients:
>>> 
>>>HiddenServiceAuthorizeClient  ,,...
>>> 
>>> If this option is configured, Tor generates client authorization data
>>> and creates a 

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

teor  writes:

> [ text/plain ]
>
>> On 11 Nov. 2016, at 04:18, George Kadianakis  wrote:
>> 
>> George Kadianakis  writes:
>> 
>>> [ text/plain ]
>>> Nick Mathewson  writes:
>>> 
 [ text/plain ]
 Hi!  I thought I'd write this up while it was fresh in my mind.  It
 could be used as an alternative method to the current proposed client
 authentication mechanism.  We could implement both, or just this, or
 just the other.
 
 My description here will be a bit terser than we'd want in a proper
 proposal, but I wanted to share it.
 
 This design is based on George Kadianakis's client authentication
 design; it won't make sense unless you've read it.
 
 =
 
 Let every client generate a curve25519 keypair, and tell the hidden
 service operator about the public key.  This keypair takes the place
 of the long-term shared secret.  For some client C, denote the secret
 key as x_X and the public key as X_C.
 
 For every descriptor, the hidden service generates a fresh keypair , and includes Y in the the outer encrypted layer.
 
 Now, for each client, the hidden service computes curve25519(X_C, y)
 and uses this as the input for two KDF functions. Call these outputs
 K1_C and K2_C.  The hidden service generates an auth-client line for
 each client as follows:
 
   "auth-client" SP client-id SP encrypted-cookie
 
 This is the same as in George's proposal, except that client-id is
 derived from a truncated version of K1_C, and the encrypted-cookie
 portion is encrypted based on K2_C.
 
 
 When the client receives the descriptor, it decrypts the outer layer,
 then sees the value of Y that the hidden server advertised.  It
 computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
 to find the appropriate entry on the list, and then uses K2_C to
 decrypt it and find the descriptor cookie.
 
 =
 
 Advantages:
  * managing public keys can be easier than managing shared secrets.
  * The encoding is slightly shorter, since no IV is needed, since K2
 is different every time.
  * probably others?
 
 Disadvantages:
  * Curve25519 costs more computationally than non-public-key operations
  * probably others?
 
 
>>> 
>>> Hey Nick,
>>> 
>>> thanks for the feedback on the torspec patch and this scheme. I'll wait
>>> to figure out if we want to use this scheme before updating the torspec
>>> patch further.
>>> 
>>> This proposed scheme seems like a good idea. It basically switches the
>>> identity of authed clients from symmetric keys to x25519 keys, which
>>> seems more intuitive and correct.
>>> 
>>> I wonder if clients could/should use the same keypair for intro-layer
>>> authentication as well. Section 3.4.2 currently specifies how to do
>>> intro-layer auth using ed25519 keys, so perhaps we can use a single
>>> curve25519 key (and switch it between ed25519 and x25519) to perform
>>> both descriptor-layer and intro-layer authentication?
>>> 
>>> WRT the suggested scheme, I think my biggest concern here is the UX, and
>>> specifically this phrase
>>> 
>>>  "Let every client generate a curve25519 keypair, and tell the hidden
>>>  service operator about the public key".
>>> 
>>> The client auth UX currently involves the HS operator passing
>>> credentials to the clients, not the other way around. This is good for
>>> UX since it means that all configuration is performed by the HS operator
>>> (who can be assumed technical), instead of its clients (who should be
>>> assumed to be non-technical). All clients need to do is copy-paste the
>>> auth line to their torrc. I feel like this UX should be maintained,
>>> except if there is a very strong reason to break it.
>>> 
>> 
>> OK, I think sooner or later we needed to have a UX discussion about HS
>> client authorization!
>> 
>> The current rend-spec.txt specifies the torrc options for client auth in
>> sections 2.3/2.4. We don't do this in prop224 yet, but I think it's
>> useful because figuring out the torrc format now will help us understand
>> if the scheme we are making is useful.
>> 
>> Here is a rough proposed UX for prop224 client auth, using Nick's idea
>> from the top post of this thread. FWIW, I've used the same torrc option
>> naming as we currently have but we should probably introduce new ones.
>> 
>> -- Hidden Service configuration
>> 
>> A hidden service uses the following torrc line to specify authed clients:
>> 
>> HiddenServiceAuthorizeClient  ,,...
>> 
>> If this option is configured, Tor generates client authorization data
>> and creates a new "hs_client_auth.txt" file which contains lines with the
>> following format:
>> 
>>client-name  NL
>>HidServAuth   
>>   NL
>> 
>> where  is a nickname for the authed client,
>>  

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[teor]

> On 11 Nov. 2016, at 04:18, George Kadianakis  wrote:
> 
> George Kadianakis  writes:
> 
>> [ text/plain ]
>> Nick Mathewson  writes:
>> 
>>> [ text/plain ]
>>> Hi!  I thought I'd write this up while it was fresh in my mind.  It
>>> could be used as an alternative method to the current proposed client
>>> authentication mechanism.  We could implement both, or just this, or
>>> just the other.
>>> 
>>> My description here will be a bit terser than we'd want in a proper
>>> proposal, but I wanted to share it.
>>> 
>>> This design is based on George Kadianakis's client authentication
>>> design; it won't make sense unless you've read it.
>>> 
>>> =
>>> 
>>> Let every client generate a curve25519 keypair, and tell the hidden
>>> service operator about the public key.  This keypair takes the place
>>> of the long-term shared secret.  For some client C, denote the secret
>>> key as x_X and the public key as X_C.
>>> 
>>> For every descriptor, the hidden service generates a fresh keypair >> Y>, and includes Y in the the outer encrypted layer.
>>> 
>>> Now, for each client, the hidden service computes curve25519(X_C, y)
>>> and uses this as the input for two KDF functions. Call these outputs
>>> K1_C and K2_C.  The hidden service generates an auth-client line for
>>> each client as follows:
>>> 
>>>   "auth-client" SP client-id SP encrypted-cookie
>>> 
>>> This is the same as in George's proposal, except that client-id is
>>> derived from a truncated version of K1_C, and the encrypted-cookie
>>> portion is encrypted based on K2_C.
>>> 
>>> 
>>> When the client receives the descriptor, it decrypts the outer layer,
>>> then sees the value of Y that the hidden server advertised.  It
>>> computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
>>> to find the appropriate entry on the list, and then uses K2_C to
>>> decrypt it and find the descriptor cookie.
>>> 
>>> =
>>> 
>>> Advantages:
>>>  * managing public keys can be easier than managing shared secrets.
>>>  * The encoding is slightly shorter, since no IV is needed, since K2
>>> is different every time.
>>>  * probably others?
>>> 
>>> Disadvantages:
>>>  * Curve25519 costs more computationally than non-public-key operations
>>>  * probably others?
>>> 
>>> 
>> 
>> Hey Nick,
>> 
>> thanks for the feedback on the torspec patch and this scheme. I'll wait
>> to figure out if we want to use this scheme before updating the torspec
>> patch further.
>> 
>> This proposed scheme seems like a good idea. It basically switches the
>> identity of authed clients from symmetric keys to x25519 keys, which
>> seems more intuitive and correct.
>> 
>> I wonder if clients could/should use the same keypair for intro-layer
>> authentication as well. Section 3.4.2 currently specifies how to do
>> intro-layer auth using ed25519 keys, so perhaps we can use a single
>> curve25519 key (and switch it between ed25519 and x25519) to perform
>> both descriptor-layer and intro-layer authentication?
>> 
>> WRT the suggested scheme, I think my biggest concern here is the UX, and
>> specifically this phrase
>> 
>>  "Let every client generate a curve25519 keypair, and tell the hidden
>>  service operator about the public key".
>> 
>> The client auth UX currently involves the HS operator passing
>> credentials to the clients, not the other way around. This is good for
>> UX since it means that all configuration is performed by the HS operator
>> (who can be assumed technical), instead of its clients (who should be
>> assumed to be non-technical). All clients need to do is copy-paste the
>> auth line to their torrc. I feel like this UX should be maintained,
>> except if there is a very strong reason to break it.
>> 
> 
> OK, I think sooner or later we needed to have a UX discussion about HS
> client authorization!
> 
> The current rend-spec.txt specifies the torrc options for client auth in
> sections 2.3/2.4. We don't do this in prop224 yet, but I think it's
> useful because figuring out the torrc format now will help us understand
> if the scheme we are making is useful.
> 
> Here is a rough proposed UX for prop224 client auth, using Nick's idea
> from the top post of this thread. FWIW, I've used the same torrc option
> naming as we currently have but we should probably introduce new ones.
> 
> -- Hidden Service configuration
> 
> A hidden service uses the following torrc line to specify authed clients:
> 
> HiddenServiceAuthorizeClient  ,,...
> 
> If this option is configured, Tor generates client authorization data
> and creates a new "hs_client_auth.txt" file which contains lines with the
> following format:
> 
>client-name  NL
>HidServAuth   
>   NL
> 
> where  is a nickname for the authed client,
>  is an x25519 private key used to generate
> descriptor encryption keys (as Nick specified in top mail), and
>  is an ed25519 private key used to perform the
> INTRO1 

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

George Kadianakis  writes:

> [ text/plain ]
> Nick Mathewson  writes:
>
>> [ text/plain ]
>> Hi!  I thought I'd write this up while it was fresh in my mind.  It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism.  We could implement both, or just this, or
>> just the other.
>>
>> My description here will be a bit terser than we'd want in a proper
>> proposal, but I wanted to share it.
>>
>> This design is based on George Kadianakis's client authentication
>> design; it won't make sense unless you've read it.
>>
>> =
>>
>> Let every client generate a curve25519 keypair, and tell the hidden
>> service operator about the public key.  This keypair takes the place
>> of the long-term shared secret.  For some client C, denote the secret
>> key as x_X and the public key as X_C.
>>
>> For every descriptor, the hidden service generates a fresh keypair > Y>, and includes Y in the the outer encrypted layer.
>>
>> Now, for each client, the hidden service computes curve25519(X_C, y)
>> and uses this as the input for two KDF functions. Call these outputs
>> K1_C and K2_C.  The hidden service generates an auth-client line for
>> each client as follows:
>>
>>"auth-client" SP client-id SP encrypted-cookie
>>
>> This is the same as in George's proposal, except that client-id is
>> derived from a truncated version of K1_C, and the encrypted-cookie
>> portion is encrypted based on K2_C.
>>
>>
>> When the client receives the descriptor, it decrypts the outer layer,
>> then sees the value of Y that the hidden server advertised.  It
>> computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
>> to find the appropriate entry on the list, and then uses K2_C to
>> decrypt it and find the descriptor cookie.
>>
>> =
>>
>> Advantages:
>>   * managing public keys can be easier than managing shared secrets.
>>   * The encoding is slightly shorter, since no IV is needed, since K2
>> is different every time.
>>   * probably others?
>>
>> Disadvantages:
>>   * Curve25519 costs more computationally than non-public-key operations
>>   * probably others?
>>
>>
>
> Hey Nick,
>
> thanks for the feedback on the torspec patch and this scheme. I'll wait
> to figure out if we want to use this scheme before updating the torspec
> patch further.
>
> This proposed scheme seems like a good idea. It basically switches the
> identity of authed clients from symmetric keys to x25519 keys, which
> seems more intuitive and correct.
>   
> I wonder if clients could/should use the same keypair for intro-layer
> authentication as well. Section 3.4.2 currently specifies how to do
> intro-layer auth using ed25519 keys, so perhaps we can use a single
> curve25519 key (and switch it between ed25519 and x25519) to perform
> both descriptor-layer and intro-layer authentication?
>
> WRT the suggested scheme, I think my biggest concern here is the UX, and
> specifically this phrase
>
>   "Let every client generate a curve25519 keypair, and tell the hidden
>   service operator about the public key".
>
> The client auth UX currently involves the HS operator passing
> credentials to the clients, not the other way around. This is good for
> UX since it means that all configuration is performed by the HS operator
> (who can be assumed technical), instead of its clients (who should be
> assumed to be non-technical). All clients need to do is copy-paste the
> auth line to their torrc. I feel like this UX should be maintained,
> except if there is a very strong reason to break it.
>

OK, I think sooner or later we needed to have a UX discussion about HS
client authorization!

The current rend-spec.txt specifies the torrc options for client auth in
sections 2.3/2.4. We don't do this in prop224 yet, but I think it's
useful because figuring out the torrc format now will help us understand
if the scheme we are making is useful.

Here is a rough proposed UX for prop224 client auth, using Nick's idea
from the top post of this thread. FWIW, I've used the same torrc option
naming as we currently have but we should probably introduce new ones.

-- Hidden Service configuration

A hidden service uses the following torrc line to specify authed clients:

 HiddenServiceAuthorizeClient  ,,...

If this option is configured, Tor generates client authorization data
and creates a new "hs_client_auth.txt" file which contains lines with the
following format:

client-name  NL
HidServAuth   
  NL

where  is a nickname for the authed client,
 is an x25519 private key used to generate
descriptor encryption keys (as Nick specified in top mail), and
 is an ed25519 private key used to perform the
INTRO1 authorization protocol (as specified in section 3.4.2 of prop224).

e.g.
client-name alice
HidServAuth a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion 
2vMVLDEAu+rc0rXFONpnor9mfG5xj0ovSh+YWIvOAvQ= 

Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[George Kadianakis]

Nick Mathewson  writes:

> [ text/plain ]
> Hi!  I thought I'd write this up while it was fresh in my mind.  It
> could be used as an alternative method to the current proposed client
> authentication mechanism.  We could implement both, or just this, or
> just the other.
>
> My description here will be a bit terser than we'd want in a proper
> proposal, but I wanted to share it.
>
> This design is based on George Kadianakis's client authentication
> design; it won't make sense unless you've read it.
>
> =
>
> Let every client generate a curve25519 keypair, and tell the hidden
> service operator about the public key.  This keypair takes the place
> of the long-term shared secret.  For some client C, denote the secret
> key as x_X and the public key as X_C.
>
> For every descriptor, the hidden service generates a fresh keypair  Y>, and includes Y in the the outer encrypted layer.
>
> Now, for each client, the hidden service computes curve25519(X_C, y)
> and uses this as the input for two KDF functions. Call these outputs
> K1_C and K2_C.  The hidden service generates an auth-client line for
> each client as follows:
>
>"auth-client" SP client-id SP encrypted-cookie
>
> This is the same as in George's proposal, except that client-id is
> derived from a truncated version of K1_C, and the encrypted-cookie
> portion is encrypted based on K2_C.
>
>
> When the client receives the descriptor, it decrypts the outer layer,
> then sees the value of Y that the hidden server advertised.  It
> computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
> to find the appropriate entry on the list, and then uses K2_C to
> decrypt it and find the descriptor cookie.
>
> =
>
> Advantages:
>   * managing public keys can be easier than managing shared secrets.
>   * The encoding is slightly shorter, since no IV is needed, since K2
> is different every time.
>   * probably others?
>
> Disadvantages:
>   * Curve25519 costs more computationally than non-public-key operations
>   * probably others?
>
>

Hey Nick,

thanks for the feedback on the torspec patch and this scheme. I'll wait
to figure out if we want to use this scheme before updating the torspec
patch further.

This proposed scheme seems like a good idea. It basically switches the
identity of authed clients from symmetric keys to x25519 keys, which
seems more intuitive and correct.
  
I wonder if clients could/should use the same keypair for intro-layer
authentication as well. Section 3.4.2 currently specifies how to do
intro-layer auth using ed25519 keys, so perhaps we can use a single
curve25519 key (and switch it between ed25519 and x25519) to perform
both descriptor-layer and intro-layer authentication?

WRT the suggested scheme, I think my biggest concern here is the UX, and
specifically this phrase

  "Let every client generate a curve25519 keypair, and tell the hidden
  service operator about the public key".

The client auth UX currently involves the HS operator passing
credentials to the clients, not the other way around. This is good for
UX since it means that all configuration is performed by the HS operator
(who can be assumed technical), instead of its clients (who should be
assumed to be non-technical). All clients need to do is copy-paste the
auth line to their torrc. I feel like this UX should be maintained,
except if there is a very strong reason to break it.

I think your proposal could be slightly tweaked to fit the above UX, if
the HS generates the client's private keys, and then passes them to the
clients. The rest works the same. Perhaps we can also give the option
for clients to generate the keys themselves if they so want.

Having the HS generate its client's private keys, kind of beats the
purpose of having assymetric crypto keys, since we basically treat them
as shared secrets. However, I don't think this changes the threat model
in any significant way, as the hidden service can be seen a trusted
party in some sense. Some more thinking needs to be done here.

The way I see it, by using this proposed scheme, we get a nicer
cryptographic scheme (symmetric keys kind of suck) and a more compact
auth-client format, for the price of a bit more engineering (generating
ephemeral keypairs and encoding them in descriptors). I think this might
be worth it.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev