Re: [tor-dev] Revisiting prop224 client authorization
On Tue, Nov 1, 2016 at 1:32 PM, George Kadianakis wrote: > I worked some more on the descriptor part of client authorization and > prepared a torspec patch. You can find it at `prop224_client_auth_2` in > my repo: > > https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_2&id=a85ffa341cc6c493ad031972f466a6dd5d8510e2 > > Based on received feedback, I went with the double-layer encryption > style, where the first layer is encrypted using the HS pubkey and the > second layer is encrypted using the descriptor cookie. Inside the first > layer plaintext is the information for authorized clients to derive the > descriptor cookie. > > I also included the padding suggestions from my previous post that > should help with hiding the number of client auths. Hi, George! This looks like solid stuff. I'll try to answer your questions and > I'd like feedback on the following: > > a) Do you like the descriptor format and logic? Can we make it nicer or >easier to implement? No objections. > b) Do you like the proposal format? Is it messy and/or hard to >understand? Ideas on how can it be improved? I think it's fine. >I think we have reached the point where every subsystem of prop224 is >complex enough to warrant its own proposal, but I'm resisting the >urge to dig into this rabbithole right now. Maybe we can clean it all up when we turn it from "prop224" to "rend-spec-v2.txt" ? :) > c) Is the descriptor cookie encryption format good enough Namely: > encrypted_cookie = STREAM(iv, client_auth_cookie) XOR descriptor_cookie I don't much care for the lack of a MAC here. I haven't found any actual vulnerability here, but every time in my life that I have omitted a MAC from a malleable ciphertext, I have turned out to regret it. > d) Current changes: I changed "authentication-required" to >"intro-auth-required" in the descriptor, to make it more clear its >about introduction-layer authentication. > > Feedback on the patch and the above points is very much welcome! > > BTW, I'm not done with this thread yet, there are still some more points > that need to be handled wrt client authorization. But this spec patch is > the most important and lengthiest of them all, so let's get it out of > the way first. So, here's my feedback on the branch itself. wrt 3da540606a85e6 "Make subcredential actually change every time period." This change is safe, I think, but not necessary: Note that the blinded_public_key input already changes every time period because of the nonce value N used in blinding the public key. wrt a85ffa341cc6c4 "Use per-client desc auth keys" What is the format of "IV" and "client-id" and "encrypted-cookie"? Base64? How long are they? I would guess "base64-encoded, 32 bytes each"? The IV has to be random, right? The spec ought to say so, but I didn't see where. Malleability on the encrypted descriptor_cookie bothers me for some reason I can't figure out; see note above. The syntax on "superencrypted" doesn't seem right. The "encrypted-string" part should probably be after an NL, not an SP, right? Descriptor-cookie needs to be random each time, yeah? Does the spec say so? In all, this looks fine to me. I like the part where we do two layers of encryption unconditionally. -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Revisiting prop224 client authorization
teor wrote: > >> On 3 Nov. 2016, at 10:37, s7r wrote: >> >> I am very happy with the torspec patch. >> >> Not quoting entirely, only want to add something wrt randomizing the >> value for fake clients based on David's and teor's comments: >> >> David Goulet wrote: >> [SNIP] >>> >>> - I think "superencrypted" -> "super-encrypted" would be nicer as everything >>> in the descriptor as that separation of word. Or even "client-encrypted" if >>> we want to add extra semantic. No strong opinion apart from the "-" :). >>> >> >> I prefer super-encrypted vs. client-encrypted. >> >>> - [XXX consider randomization of the value 16] >>> >>> If it's fixed, we basically create bucket so a client can know that there >>> are 0-16 clients or 16-32 clients and so on. >>> >>> If we randomize that value and let's say it's 7 then we have bucket of 7. >>> If >>> that value is randomized _every_ new descriptor, we create multiple size of >>> buckets but over time someone could deduce (maybe) the low bound of clients >>> by observing all random values and thus assume there are 0-. >>> >>> I'm uncertain here what's best but seems that in any case, bucketing is >>> happening as we pad with fake "auth-client". So I would assume here, out of >>> my head to be safe, that we might want _all_ services to kind of look the >>> same thus a fixed value would make sense following that train of thought. >>> >>> I'm liking the rest here! We'll have to think also on some padding in the >>> INTRODUCE1 cell to avoid leaking client auth is being used. >>> >> >> This is true, we create buckets no matter what, but I think it's better >> if one has to watch a hidden service for a lot more time to determine >> the probable number rather than being able to tell from the first >> descriptor that there are 0-16 clients, 16-32 clients and so on. >> >> I fully agree that randomizing _every_ new descriptor does not help and >> probably in short time someone could deduce a possible number, but I am >> slightly uncomfortable with a global fixed value for this. One more >> idea, if it's not helpful we can just go ahead with a fixed value of 16. >> >> I think it's better if we pick a random number between 8 and 32 fake >> clients and remember the picked value so it will be used for every new >> descriptor until something in our setup changes or enough time has >> passed. In order to know when to reset it, we save it (in our state) >> along with: >> 1. The number of real authorized clients when the random value was picked. >> 2. Timestamp when the random value was picked + an end of life for the >> random value. >> >> We reset the random value of fake authorized clients and also its end of >> life when: >> >> a) number of real authorized clients in torrc changes from what we have >> in our state. >> b) end of life for the random value is reached. End of life will be >> timestamp + a random period between 30 and 90 days. >> c) obvious case when Tor is re-installed and old state is lost. >> >> We call this function on every HUP and (re)start. We can tune the >> numbers 8 - 32 and period 30 - 90 days as you like. >> >> This way there are a lot of buckets and significantly more time needed >> for an observer to deduce a probable number. It is quite possible one >> can never deduce a "probable enough" number. >> >> We combine this with faking extra if needed in the encrypted portion to >> the next multiple of 10k bytes. >> >> It's true that it won't help if the hidden service operator changes the >> number of authorized clients every hour for a long period but in >> practice this doesn't happen - number of authorized clients changes >> rarely. And even in this scenario it still makes things a lot more >> confusing. >> >> Compared to other parts of prop 224, this is easy to code and should be >> worth the effort. What do you think? > > If you want to do it this way, with noise and buckets, ask someone who is > good at differential privacy to do the numbers for you, rather than guessing. > > You'll need to know the level of activity you want to hide. > > T > As I said the numbers can be changed - I was illustrating an example. I guessed some numbers that seamed reasonable to me so I could give an example, and also because it's not a critical part. We only try to hide the number of real authorized clients, or make it as hard as possible for an observer to deduce a number close to the realistic number of authorized clients, that's all. Simply using the numbers that were guessed without deep knowledge in differential privacy is a lot better than using a global fixed value of 16, but as I said this doesn't need to be a debate because I am not against the fixed value, only saying it's better to randomize, if the solution exists. 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] Revisiting prop224 client authorization
> On 3 Nov. 2016, at 10:37, s7r wrote: > > I am very happy with the torspec patch. > > Not quoting entirely, only want to add something wrt randomizing the > value for fake clients based on David's and teor's comments: > > David Goulet wrote: > [SNIP] >> >> - I think "superencrypted" -> "super-encrypted" would be nicer as everything >> in the descriptor as that separation of word. Or even "client-encrypted" if >> we want to add extra semantic. No strong opinion apart from the "-" :). >> > > I prefer super-encrypted vs. client-encrypted. > >> - [XXX consider randomization of the value 16] >> >> If it's fixed, we basically create bucket so a client can know that there >> are 0-16 clients or 16-32 clients and so on. >> >> If we randomize that value and let's say it's 7 then we have bucket of 7. If >> that value is randomized _every_ new descriptor, we create multiple size of >> buckets but over time someone could deduce (maybe) the low bound of clients >> by observing all random values and thus assume there are 0-. >> >> I'm uncertain here what's best but seems that in any case, bucketing is >> happening as we pad with fake "auth-client". So I would assume here, out of >> my head to be safe, that we might want _all_ services to kind of look the >> same thus a fixed value would make sense following that train of thought. >> >> I'm liking the rest here! We'll have to think also on some padding in the >> INTRODUCE1 cell to avoid leaking client auth is being used. >> > > This is true, we create buckets no matter what, but I think it's better > if one has to watch a hidden service for a lot more time to determine > the probable number rather than being able to tell from the first > descriptor that there are 0-16 clients, 16-32 clients and so on. > > I fully agree that randomizing _every_ new descriptor does not help and > probably in short time someone could deduce a possible number, but I am > slightly uncomfortable with a global fixed value for this. One more > idea, if it's not helpful we can just go ahead with a fixed value of 16. > > I think it's better if we pick a random number between 8 and 32 fake > clients and remember the picked value so it will be used for every new > descriptor until something in our setup changes or enough time has > passed. In order to know when to reset it, we save it (in our state) > along with: > 1. The number of real authorized clients when the random value was picked. > 2. Timestamp when the random value was picked + an end of life for the > random value. > > We reset the random value of fake authorized clients and also its end of > life when: > > a) number of real authorized clients in torrc changes from what we have > in our state. > b) end of life for the random value is reached. End of life will be > timestamp + a random period between 30 and 90 days. > c) obvious case when Tor is re-installed and old state is lost. > > We call this function on every HUP and (re)start. We can tune the > numbers 8 - 32 and period 30 - 90 days as you like. > > This way there are a lot of buckets and significantly more time needed > for an observer to deduce a probable number. It is quite possible one > can never deduce a "probable enough" number. > > We combine this with faking extra if needed in the encrypted portion to > the next multiple of 10k bytes. > > It's true that it won't help if the hidden service operator changes the > number of authorized clients every hour for a long period but in > practice this doesn't happen - number of authorized clients changes > rarely. And even in this scenario it still makes things a lot more > confusing. > > Compared to other parts of prop 224, this is easy to code and should be > worth the effort. What do you think? If you want to do it this way, with noise and buckets, ask someone who is good at differential privacy to do the numbers for you, rather than guessing. You'll need to know the level of activity you want to hide. 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] Revisiting prop224 client authorization
I am very happy with the torspec patch. Not quoting entirely, only want to add something wrt randomizing the value for fake clients based on David's and teor's comments: David Goulet wrote: [SNIP] > > - I think "superencrypted" -> "super-encrypted" would be nicer as everything > in the descriptor as that separation of word. Or even "client-encrypted" if > we want to add extra semantic. No strong opinion apart from the "-" :). > I prefer super-encrypted vs. client-encrypted. > - [XXX consider randomization of the value 16] > > If it's fixed, we basically create bucket so a client can know that there > are 0-16 clients or 16-32 clients and so on. > > If we randomize that value and let's say it's 7 then we have bucket of 7. If > that value is randomized _every_ new descriptor, we create multiple size of > buckets but over time someone could deduce (maybe) the low bound of clients > by observing all random values and thus assume there are 0-. > > I'm uncertain here what's best but seems that in any case, bucketing is > happening as we pad with fake "auth-client". So I would assume here, out of > my head to be safe, that we might want _all_ services to kind of look the > same thus a fixed value would make sense following that train of thought. > > I'm liking the rest here! We'll have to think also on some padding in the > INTRODUCE1 cell to avoid leaking client auth is being used. > This is true, we create buckets no matter what, but I think it's better if one has to watch a hidden service for a lot more time to determine the probable number rather than being able to tell from the first descriptor that there are 0-16 clients, 16-32 clients and so on. I fully agree that randomizing _every_ new descriptor does not help and probably in short time someone could deduce a possible number, but I am slightly uncomfortable with a global fixed value for this. One more idea, if it's not helpful we can just go ahead with a fixed value of 16. I think it's better if we pick a random number between 8 and 32 fake clients and remember the picked value so it will be used for every new descriptor until something in our setup changes or enough time has passed. In order to know when to reset it, we save it (in our state) along with: 1. The number of real authorized clients when the random value was picked. 2. Timestamp when the random value was picked + an end of life for the random value. We reset the random value of fake authorized clients and also its end of life when: a) number of real authorized clients in torrc changes from what we have in our state. b) end of life for the random value is reached. End of life will be timestamp + a random period between 30 and 90 days. c) obvious case when Tor is re-installed and old state is lost. We call this function on every HUP and (re)start. We can tune the numbers 8 - 32 and period 30 - 90 days as you like. This way there are a lot of buckets and significantly more time needed for an observer to deduce a probable number. It is quite possible one can never deduce a "probable enough" number. We combine this with faking extra if needed in the encrypted portion to the next multiple of 10k bytes. It's true that it won't help if the hidden service operator changes the number of authorized clients every hour for a long period but in practice this doesn't happen - number of authorized clients changes rarely. And even in this scenario it still makes things a lot more confusing. Compared to other parts of prop 224, this is easy to code and should be worth the effort. What do you think? Thanks a lot for considering all my previous points. 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] Revisiting prop224 client authorization
> On 3 Nov. 2016, at 04:45, David Goulet wrote: > > - I think "superencrypted" -> "super-encrypted" would be nicer as everything > in the descriptor as that separation of word. Or even "client-encrypted" if > we want to add extra semantic. No strong opinion apart from the "-" :). client-encrypted could be very confusing. It sounds like the client has encrypted it. > - [XXX consider randomization of the value 16] > > If it's fixed, we basically create bucket so a client can know that there > are 0-16 clients or 16-32 clients and so on. > > If we randomize that value and let's say it's 7 then we have bucket of 7. If > that value is randomized _every_ new descriptor, we create multiple size of > buckets but over time someone could deduce (maybe) the low bound of clients > by observing all random values and thus assume there are 0-. Yes, this is true. And it would be quite easy over time, as hidden services don't change their client auth that often. So you would just need to download a descriptor every hour. > I'm uncertain here what's best but seems that in any case, bucketing is > happening as we pad with fake "auth-client". So I would assume here, out of > my head to be safe, that we might want _all_ services to kind of look the > same thus a fixed value would make sense following that train of thought. Yes, buckets are the best. State of the art is add random noise then bucket, but I don't think that's needed here. And the noise would have to be large to hide an unchanging value. 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] Revisiting prop224 client authorization
On 01 Nov (13:32:13), George Kadianakis wrote: > David Goulet writes: > > > [ text/plain ] > > On 17 Oct (13:35:24), George Kadianakis wrote: > >> George Kadianakis writes: > >> > >> > [ text/plain ] > >> > Hello, > >> > > >> > we've reached the point in prop224 development where we need to pin down > >> > the precise cell formats, so that we can start implementing them. HS > >> > client authorization has been one of those areas that are not yet > >> > finalized and are still influencing cell format. > >> > > >> > Here are some topics based on special's old notes, plus some further > >> > recent discussion with David and Yawning. > >> > > >> > >> Hello again, > >> > >> I read the feedback on the thread and thought some more about this. Here > >> are some thoughts based on received feedback. A torspec branch coming > >> soon if people agree with my points below. > >> > >> I'd also like to introduce a new topic of discussion here: > >> > >> > >> > >> > a) I think the most important problem here is that the authorization-key > >> > logic > >> >in the current prop224 is very suboptimal. Specifically, prop224 uses > >> > a > >> >global authorization-key to ensure that descriptors are only read by > >> >authorized clients. However, since that key is global, if we ever > >> > want to > >> >revoke a single client we need to change the keys for all clients. The > >> >current rend-spec.txt does not suffer from this issue, hence I > >> > adapted the > >> >current technique to prop224. > >> > > >> >Please see my torspec branch `prop224_client_auth` for the proposed > >> > changes: > >> > > >> > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth > >> > > >> >Some further questions here: > >> > > >> >i) Should we fake the client-auth-desc-key blob in case client > >> > authorization > >> > is not enabled? Otherwise, we leak to the HSDir whether client > >> > auth is > >> > enabled. The drawback here is the desc size increase (by about 330 > >> > bytes). > >> > > >> > Alternatively, we can try to put it in the encrypted part of the > >> > descriptor. So that we require subcredential knowledge to access > >> > the > >> > encrypted part, and then client_auth_cookie knowledge to get the > >> > encryption key to decrypt the intro points etc. I feel that this > >> > double-encryption design might be too annoying to implement, but > >> > perhaps > >> > it's worth it? > >> > > >> > >> Seems like people preferred the double-encryption idea here, so that we > >> reveal the least amount of information possible in the plaintext part of > >> the desc. > >> > >> I think this is a reasonable point since if we put the auth keys in the > >> plaintext part of the descriptor, and we always pad (or fake clients) up > >> to N authorized clients, it will be obvious to an HSDir if a hidden > >> service has more than N authorized clients (since we will need to fake > >> 2*N clients then). > >> > > Hello, > > I worked some more on the descriptor part of client authorization and > prepared a torspec patch. You can find it at `prop224_client_auth_2` in > my repo: > > https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_2&id=a85ffa341cc6c493ad031972f466a6dd5d8510e2 > > Based on received feedback, I went with the double-layer encryption > style, where the first layer is encrypted using the HS pubkey and the > second layer is encrypted using the descriptor cookie. Inside the first > layer plaintext is the information for authorized clients to derive the > descriptor cookie. > > I also included the padding suggestions from my previous post that > should help with hiding the number of client auths. > > I'd like feedback on the following: > > a) Do you like the descriptor format and logic? Can we make it nicer or >easier to implement? This line in the superencrypted section: "auth-client" SP iv SP client-id SP encrypted-cookie ... all three values will be raw bytes as far as I can tell. I'm fine with bytes in the descriptor (like we do know for v2) but mixing "text param" with "binary param" might not be ideal. If we want a human readable representation, I would go with base64 encoding those or if not, full binary. I like the human readable personally as it's so much easier to debug. As we stated before, size is not that of an issue and going from binary to base64 won't create huge strings at all... Downside, we have to parse more strings! :P but we do that _HEAVILY_ anyway with descriptors so... > > b) Do you like the proposal format? Is it messy and/or hard to >understand? Ideas on how can it be improved? > >I think we have reached the point where every subsystem of prop224 is >complex enough to warrant its own proposal, but I'm resisting the >urge to dig into this rabbithole right now. We could indeed split but I think it's fine for now. No
Re: [tor-dev] Revisiting prop224 client authorization
David Goulet writes: > [ text/plain ] > On 17 Oct (13:35:24), George Kadianakis wrote: >> George Kadianakis writes: >> >> > [ text/plain ] >> > Hello, >> > >> > we've reached the point in prop224 development where we need to pin down >> > the precise cell formats, so that we can start implementing them. HS >> > client authorization has been one of those areas that are not yet >> > finalized and are still influencing cell format. >> > >> > Here are some topics based on special's old notes, plus some further >> > recent discussion with David and Yawning. >> > >> >> Hello again, >> >> I read the feedback on the thread and thought some more about this. Here >> are some thoughts based on received feedback. A torspec branch coming >> soon if people agree with my points below. >> >> I'd also like to introduce a new topic of discussion here: >> >> >> >> > a) I think the most important problem here is that the authorization-key >> > logic >> >in the current prop224 is very suboptimal. Specifically, prop224 uses a >> >global authorization-key to ensure that descriptors are only read by >> >authorized clients. However, since that key is global, if we ever want >> > to >> >revoke a single client we need to change the keys for all clients. The >> >current rend-spec.txt does not suffer from this issue, hence I adapted >> > the >> >current technique to prop224. >> > >> >Please see my torspec branch `prop224_client_auth` for the proposed >> > changes: >> > >> > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth >> > >> >Some further questions here: >> > >> >i) Should we fake the client-auth-desc-key blob in case client >> > authorization >> > is not enabled? Otherwise, we leak to the HSDir whether client auth >> > is >> > enabled. The drawback here is the desc size increase (by about 330 >> > bytes). >> > >> > Alternatively, we can try to put it in the encrypted part of the >> > descriptor. So that we require subcredential knowledge to access the >> > encrypted part, and then client_auth_cookie knowledge to get the >> > encryption key to decrypt the intro points etc. I feel that this >> > double-encryption design might be too annoying to implement, but >> > perhaps >> > it's worth it? >> > >> >> Seems like people preferred the double-encryption idea here, so that we >> reveal the least amount of information possible in the plaintext part of >> the desc. >> >> I think this is a reasonable point since if we put the auth keys in the >> plaintext part of the descriptor, and we always pad (or fake clients) up >> to N authorized clients, it will be obvious to an HSDir if a hidden >> service has more than N authorized clients (since we will need to fake >> 2*N clients then). >> Hello, I worked some more on the descriptor part of client authorization and prepared a torspec patch. You can find it at `prop224_client_auth_2` in my repo: https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_2&id=a85ffa341cc6c493ad031972f466a6dd5d8510e2 Based on received feedback, I went with the double-layer encryption style, where the first layer is encrypted using the HS pubkey and the second layer is encrypted using the descriptor cookie. Inside the first layer plaintext is the information for authorized clients to derive the descriptor cookie. I also included the padding suggestions from my previous post that should help with hiding the number of client auths. I'd like feedback on the following: a) Do you like the descriptor format and logic? Can we make it nicer or easier to implement? b) Do you like the proposal format? Is it messy and/or hard to understand? Ideas on how can it be improved? I think we have reached the point where every subsystem of prop224 is complex enough to warrant its own proposal, but I'm resisting the urge to dig into this rabbithole right now. c) Is the descriptor cookie encryption format good enough Namely: encrypted_cookie = STREAM(iv, client_auth_cookie) XOR descriptor_cookie d) Current changes: I changed "authentication-required" to "intro-auth-required" in the descriptor, to make it more clear its about introduction-layer authentication. Feedback on the patch and the above points is very much welcome! BTW, I'm not done with this thread yet, there are still some more points that need to be handled wrt client authorization. But this spec patch is the most important and lengthiest of them all, so let's get it out of the way first. Thanks! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Revisiting prop224 client authorization
Hello George, Inline comments: > Hello again, > > I read the feedback on the thread and thought some more about this. Here > are some thoughts based on received feedback. A torspec branch coming > soon if people agree with my points below. > > I'd also like to introduce a new topic of discussion here: > > d) Should we introduce the concept of stealth auth again? > >IIUC the current prop224 client auth solutions are not providing all >the security properties that stealth auth did. Specifically, if Alice >is an ex-authorized-client of a hidden service and she got revoked, >she can still fetch the descriptor of a hidden service and hence >learn the uptime/presense of the HS. IIUC, with stealth auth this was >not previously possible. > I also share David's feeling here, presence hiding is not so critical and I am not sure if its worth its engineering and additional code costs. We can add this feature any time after deployment anyway because there are many questions and we need some stats and to analyze user demands in order to take the right decision here. Freezing this specific feature until further analysis shouldn't be a problem. >> a) I think the most important problem here is that the authorization-key >> logic >>in the current prop224 is very suboptimal. Specifically, prop224 uses a >>global authorization-key to ensure that descriptors are only read by >>authorized clients. However, since that key is global, if we ever want to >>revoke a single client we need to change the keys for all clients. The >>current rend-spec.txt does not suffer from this issue, hence I adapted the >>current technique to prop224. >> >>Please see my torspec branch `prop224_client_auth` for the proposed >> changes: >> >> https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth >> >>Some further questions here: >> >>i) Should we fake the client-auth-desc-key blob in case client >> authorization >> is not enabled? Otherwise, we leak to the HSDir whether client auth is >> enabled. The drawback here is the desc size increase (by about 330 >> bytes). >> >> Alternatively, we can try to put it in the encrypted part of the >> descriptor. So that we require subcredential knowledge to access the >> encrypted part, and then client_auth_cookie knowledge to get the >> encryption key to decrypt the intro points etc. I feel that this >> double-encryption design might be too annoying to implement, but >> perhaps >> it's worth it? >> > > Seems like people preferred the double-encryption idea here, so that we > reveal the least amount of information possible in the plaintext part of > the desc. > > I think this is a reasonable point since if we put the auth keys in the > plaintext part of the descriptor, and we always pad (or fake clients) up > to N authorized clients, it will be obvious to an HSDir if a hidden > service has more than N authorized clients (since we will need to fake > 2*N clients then). > Agreed. > --- > > WRT protocol, I guess the idea here is that if client auth is enabled, > then we add some client authorization fields in the top of the encrypted > section of the descriptor, that can be used to find the client-auth > descriptor encryption key. Then we add another client-auth-encrypted > blob inside the encrypted part, which contains the intro points etc. and > is encrypted using the descriptor encryption key found above. > > So the first layer is encrypted using the onion address, and the second > layer is encrypted using the client auth descriptor key. This won't be > too hard to implement, but it's also different from what's currently > coded in #17238. > > Do people feel OK with this? > Yes, sounds good. > Also, what should happen if client auth is not used? Should we fall back > to the current descriptor format, or should we fake authorized clients > and add a fake client-auth-encrypted-blob for uniformity? Feedback is > welcome here, and I think the main issue here is engineering time and > reuse of the current code. > > --- > I say Yes with capital letter here. We should make as many descriptors as we can look alike as we can. If client auth is not used, that descriptor should contain N fake clients (given we choose a reasonable N that will result in an reasonable average size for descriptors network wide). > Now WRT security, even if we do the double-encryption thing, and we > consider an HSDir adversary that knows the onion address but is not an > authorized client,we still need to add fake clients, otherwise that > adversary will know the exact number of authorized clients. So fake > clients will probably need to be introduced anyhow. > Of course, fake clients will patch this problem in a good way - an adversary that only knows the onion address but its not an authorized client will not have an _exact_ number of authorized clients no matter what. And the addit
Re: [tor-dev] Revisiting prop224 client authorization
On 17 Oct (13:35:24), George Kadianakis wrote: > George Kadianakis writes: > > > [ text/plain ] > > Hello, > > > > we've reached the point in prop224 development where we need to pin down > > the precise cell formats, so that we can start implementing them. HS > > client authorization has been one of those areas that are not yet > > finalized and are still influencing cell format. > > > > Here are some topics based on special's old notes, plus some further > > recent discussion with David and Yawning. > > > > Hello again, > > I read the feedback on the thread and thought some more about this. Here > are some thoughts based on received feedback. A torspec branch coming > soon if people agree with my points below. > > I'd also like to introduce a new topic of discussion here: > > d) Should we introduce the concept of stealth auth again? > >IIUC the current prop224 client auth solutions are not providing all >the security properties that stealth auth did. Specifically, if Alice >is an ex-authorized-client of a hidden service and she got revoked, >she can still fetch the descriptor of a hidden service and hence >learn the uptime/presense of the HS. IIUC, with stealth auth this was >not previously possible. I think this has value if client revocation is a something that actually happens and the operator wants that revoked client to NEVER know anything about the service anymore. My guts tells me that it might be a very small portion of operators that do that and have concerns on hidding the service. I could be wrong so we can try to ask around on our public channels and see what's the response. I can see this feature being added _after_ deployment as well. > > > a) I think the most important problem here is that the authorization-key > > logic > >in the current prop224 is very suboptimal. Specifically, prop224 uses a > >global authorization-key to ensure that descriptors are only read by > >authorized clients. However, since that key is global, if we ever want to > >revoke a single client we need to change the keys for all clients. The > >current rend-spec.txt does not suffer from this issue, hence I adapted > > the > >current technique to prop224. > > > >Please see my torspec branch `prop224_client_auth` for the proposed > > changes: > > > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth > > > >Some further questions here: > > > >i) Should we fake the client-auth-desc-key blob in case client > > authorization > > is not enabled? Otherwise, we leak to the HSDir whether client auth is > > enabled. The drawback here is the desc size increase (by about 330 > > bytes). > > > > Alternatively, we can try to put it in the encrypted part of the > > descriptor. So that we require subcredential knowledge to access the > > encrypted part, and then client_auth_cookie knowledge to get the > > encryption key to decrypt the intro points etc. I feel that this > > double-encryption design might be too annoying to implement, but > > perhaps > > it's worth it? > > > > Seems like people preferred the double-encryption idea here, so that we > reveal the least amount of information possible in the plaintext part of > the desc. > > I think this is a reasonable point since if we put the auth keys in the > plaintext part of the descriptor, and we always pad (or fake clients) up > to N authorized clients, it will be obvious to an HSDir if a hidden > service has more than N authorized clients (since we will need to fake > 2*N clients then). > > --- > > WRT protocol, I guess the idea here is that if client auth is enabled, > then we add some client authorization fields in the top of the encrypted > section of the descriptor, that can be used to find the client-auth > descriptor encryption key. Then we add another client-auth-encrypted > blob inside the encrypted part, which contains the intro points etc. and > is encrypted using the descriptor encryption key found above. Well, I would only encrypt the key that was used to encrypt the introduction points but I'm sure this is what you meant! > > So the first layer is encrypted using the onion address, and the second > layer is encrypted using the client auth descriptor key. This won't be > too hard to implement, but it's also different from what's currently > coded in #17238. Indeed, we need to change stuff but I think it's fine. We can get #17238 merged and then simply apply those changes after. I'm not too concerned about the engineering logistics personally. > > Do people feel OK with this? > > Also, what should happen if client auth is not used? Should we fall back > to the current descriptor format, or should we fake authorized clients > and add a fake client-auth-encrypted-blob for uniformity? Feedback is > welcome here, and I think the main issue here is engineering time and > reuse of the current code. Right, the
Re: [tor-dev] Revisiting prop224 client authorization
George Kadianakis writes: > [ text/plain ] > Hello, > > we've reached the point in prop224 development where we need to pin down > the precise cell formats, so that we can start implementing them. HS > client authorization has been one of those areas that are not yet > finalized and are still influencing cell format. > > Here are some topics based on special's old notes, plus some further > recent discussion with David and Yawning. > Hello again, I read the feedback on the thread and thought some more about this. Here are some thoughts based on received feedback. A torspec branch coming soon if people agree with my points below. I'd also like to introduce a new topic of discussion here: d) Should we introduce the concept of stealth auth again? IIUC the current prop224 client auth solutions are not providing all the security properties that stealth auth did. Specifically, if Alice is an ex-authorized-client of a hidden service and she got revoked, she can still fetch the descriptor of a hidden service and hence learn the uptime/presense of the HS. IIUC, with stealth auth this was not previously possible. > a) I think the most important problem here is that the authorization-key logic >in the current prop224 is very suboptimal. Specifically, prop224 uses a >global authorization-key to ensure that descriptors are only read by >authorized clients. However, since that key is global, if we ever want to >revoke a single client we need to change the keys for all clients. The >current rend-spec.txt does not suffer from this issue, hence I adapted the >current technique to prop224. > >Please see my torspec branch `prop224_client_auth` for the proposed > changes: > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth > >Some further questions here: > >i) Should we fake the client-auth-desc-key blob in case client > authorization > is not enabled? Otherwise, we leak to the HSDir whether client auth is > enabled. The drawback here is the desc size increase (by about 330 > bytes). > > Alternatively, we can try to put it in the encrypted part of the > descriptor. So that we require subcredential knowledge to access the > encrypted part, and then client_auth_cookie knowledge to get the > encryption key to decrypt the intro points etc. I feel that this > double-encryption design might be too annoying to implement, but perhaps > it's worth it? > Seems like people preferred the double-encryption idea here, so that we reveal the least amount of information possible in the plaintext part of the desc. I think this is a reasonable point since if we put the auth keys in the plaintext part of the descriptor, and we always pad (or fake clients) up to N authorized clients, it will be obvious to an HSDir if a hidden service has more than N authorized clients (since we will need to fake 2*N clients then). --- WRT protocol, I guess the idea here is that if client auth is enabled, then we add some client authorization fields in the top of the encrypted section of the descriptor, that can be used to find the client-auth descriptor encryption key. Then we add another client-auth-encrypted blob inside the encrypted part, which contains the intro points etc. and is encrypted using the descriptor encryption key found above. So the first layer is encrypted using the onion address, and the second layer is encrypted using the client auth descriptor key. This won't be too hard to implement, but it's also different from what's currently coded in #17238. Do people feel OK with this? Also, what should happen if client auth is not used? Should we fall back to the current descriptor format, or should we fake authorized clients and add a fake client-auth-encrypted-blob for uniformity? Feedback is welcome here, and I think the main issue here is engineering time and reuse of the current code. --- Now WRT security, even if we do the double-encryption thing, and we consider an HSDir adversary that knows the onion address but is not an authorized client,we still need to add fake clients, otherwise that adversary will know the exact number of authorized clients. So fake clients will probably need to be introduced anyhow. As David pointed out, this all boils down to how much we pad the encrypted part of the descriptor, otherwise we always leak info. If we are hoping for a leakless strategy here, we should be generous with our padding. Let's see how much padding we need: - Each intro point adds about 1.1k bytes to the descriptor (according to david). - Each block of 16 authorized clients adds about 1k bytes to the descriptor (according to the format described below). - Apart from intro points and authorized clients, the rest of the descriptor is not that heavy: less than 1k bytes (right?) To get an average size here, let's consider a normal descriptor with 5 intro points and 16 authorized clients
Re: [tor-dev] Revisiting prop224 client authorization
Hi David, David Goulet wrote: > > Personally, I would really like to be able to hide the fact that a service is > using client authorization. Both could hide that but not that trivially. > > I would pick double encryption for the simple fact that I really want to us to > expose as little as we can in the plaintext section. Also, it seems to me that > we could increase our chances of fuck up with this "fake client-auth-desc-key > blob" situation for service without client auth?.. > > An other thing here, I have this feeling that client authorization might > always leak unless we set a maximum number of clients and pad up to that > value. I mean, how much do we pad in for a non-client auth service descriptor? > I guess our ultimate goal would be to make all descriptors look a like in > terms of size? (Except for extra IPs...) > > The other thing I which we could fix if we pick double encryption is "if I > know the .onion then I can know how many clients are authorized" but that's a > thougher one and might need us to fake client auth in the encrypted section as > well... > > So we should try to answer this question: Do we care about the increasing size > of the descriptor considerably from what we have now? I could see a concern on > mobile or even the horrible world of IoT (which uses cell's networks a lot in > the end.) > > To give an idea, how we implemented 224 so far, a default descriptor (with 3 > non-legacy IPs and no client auth) is 3153 bytes. Every new IPs adds ~870 > bytes (this can vary a bit depending if IPv6). Adding a legacy IP (RSA keys), > we are are ~1215 extra bytes (again vary because IPv6). > > I tend to say yes to increasing descriptor size if it's offer more security. I > mean, <10k bytes is pretty small also on todays network I guess?... > Hey, very clever how you thought about this. I wanted to say no, don't limit the max number of clients can be authorized on a HS, but a descriptor has to have some hard limit anyway (I guess it has one, if not it should). So, bottom of the line, the theoretical possible number of authorized clients is already limited by the max descriptor size. I think it's simpler if we think towards making the majority of descriptors look alike (in terms of size) as opposite to making each and every one look alike (in terms of size) because this means we need to pad up to the hard limit in all cases. Considering the introduction points, which can be from 3 to 20 and add to that how many clients we have authorized this creates very different possible descriptor sizes. What we should do is come up with a fair number of authorized clients which is in most cases not exceeded (hard to come up with accurate stats for this), and pad up to that with dummy authorized clients for both auth enabled hidden services with less authorized clients than the so-called 'default' number and non-auth hidden services. This could also partially solve "if I know the .onion I know how may clients are authorized". Only the auth-enabled HSes who have more authorized clients than the so-called 'default' number will leak this this popularity info, but it should be no worse than the current stage anyway. This is better because the majority of auth-enabled hidden services are assumed to be under this limit so you can't tell their exact number of authorized clients because you don't know how many of them are dummy clients. Hardest part here is picking the right numbers: MAX ALLOWED DESCRIPTOR SIZE (descriptor version will be useful in case we decide to change this limit in the future) DEFAULT NUMBER OF AUTHORIZED CLIENTS - let's say 100 (this is not based on any analysis, just what came into my mind - probably not a good number). I am inclined to make this number as high as we can considering mobile clients and/or small bandwidth clients. In this case a HS with 1 authorized client will have in its descriptor: 1 real authorized client 99 dummy authorized clients which do not exit but nobody can tell A HS with 2 authorized clients will have the real:dummy client ratio 2:98, and so on. When new authorized clients are added, the dummy slots will be occupied first, if previous authorized clients weren't revoked/deleted. A non-auth HS will have 100 dummy authorized clients (??? or 99 and global non-auth anyclient ???). If we can't make all descriptors perfectly equal in terms of size (not because it's technically impossible, but because of the costs) at least making the very vast majority of them look alike is one step forward. 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] Revisiting prop224 client authorization
On 11 Oct (16:58:43), George Kadianakis wrote: > Hello, Hi! Thanks for this George! > > we've reached the point in prop224 development where we need to pin down > the precise cell formats, so that we can start implementing them. HS > client authorization has been one of those areas that are not yet > finalized and are still influencing cell format. > > Here are some topics based on special's old notes, plus some further > recent discussion with David and Yawning. > > a) I think the most important problem here is that the authorization-key logic >in the current prop224 is very suboptimal. Specifically, prop224 uses a >global authorization-key to ensure that descriptors are only read by >authorized clients. However, since that key is global, if we ever want to >revoke a single client we need to change the keys for all clients. The >current rend-spec.txt does not suffer from this issue, hence I adapted the >current technique to prop224. > >Please see my torspec branch `prop224_client_auth` for the proposed > changes: > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth > >Some further questions here: > >i) Should we fake the client-auth-desc-key blob in case client > authorization > is not enabled? Otherwise, we leak to the HSDir whether client auth is > enabled. The drawback here is the desc size increase (by about 330 > bytes). > > Alternatively, we can try to put it in the encrypted part of the > descriptor. So that we require subcredential knowledge to access the > encrypted part, and then client_auth_cookie knowledge to get the > encryption key to decrypt the intro points etc. I feel that this > double-encryption design might be too annoying to implement, but perhaps > it's worth it? Personally, I would really like to be able to hide the fact that a service is using client authorization. Both could hide that but not that trivially. I would pick double encryption for the simple fact that I really want to us to expose as little as we can in the plaintext section. Also, it seems to me that we could increase our chances of fuck up with this "fake client-auth-desc-key blob" situation for service without client auth?.. An other thing here, I have this feeling that client authorization might always leak unless we set a maximum number of clients and pad up to that value. I mean, how much do we pad in for a non-client auth service descriptor? I guess our ultimate goal would be to make all descriptors look a like in terms of size? (Except for extra IPs...) The other thing I which we could fix if we pick double encryption is "if I know the .onion then I can know how many clients are authorized" but that's a thougher one and might need us to fake client auth in the encrypted section as well... So we should try to answer this question: Do we care about the increasing size of the descriptor considerably from what we have now? I could see a concern on mobile or even the horrible world of IoT (which uses cell's networks a lot in the end.) To give an idea, how we implemented 224 so far, a default descriptor (with 3 non-legacy IPs and no client auth) is 3153 bytes. Every new IPs adds ~870 bytes (this can vary a bit depending if IPv6). Adding a legacy IP (RSA keys), we are are ~1215 extra bytes (again vary because IPv6). I tend to say yes to increasing descriptor size if it's offer more security. I mean, <10k bytes is pretty small also on todays network I guess?... > >ii) Should we use the descriptor ASCII format to encode all the >client-auth-desc-key data? Or is that weird binary format OK? > >iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt > does not do that, and IIUC that's OK because it uses a fresh key for > every encryption (even though the plaintext and IV is the same). > > b) Do we want a NACK from the HS for when client authorization fails? > Currently >the only way for a client to learn that they are not authorized (or that >their keys changed or got revoked) is that they never complete the > rendezvous. > >To achieve that we would need a whole new cell (INTRODUCE_SERVICE_NACK) > from >the hidden service all the way to the client. Worth it? I would definitely not NACK with a error code that says "authorization failure" as this gives out a new "oracle" to anyone out there to poke the service. However, I would assume that most of the NACK would come from bad authorization because establishing an INTRO with the service is usually not something that fails often... So I'm hesitant here to do so as it would be very useful for only a specific use case of HS that is client auth. And when I say specific is that I assume blindly that most HS out there don't use client auth much... I might be very wrong! > > c) Another suggestion here by special, is to introduce an additional >layer of access cont
Re: [tor-dev] Revisiting prop224 client authorization
Hi, George Kadianakis wrote: [SNIP] > >Some further questions here: > >i) Should we fake the client-auth-desc-key blob in case client > authorization > is not enabled? Otherwise, we leak to the HSDir whether client auth is > enabled. The drawback here is the desc size increase (by about 330 > bytes). > > Alternatively, we can try to put it in the encrypted part of the > descriptor. So that we require subcredential knowledge to access the > encrypted part, and then client_auth_cookie knowledge to get the > encryption key to decrypt the intro points etc. I feel that this > double-encryption design might be too annoying to implement, but perhaps > it's worth it? > I suggest faking the client-auth-desc-key blob. 330 bytes should be worth it for making both auth non-auth hidden services look very alike (in size). The double-encryption, aside that it might be too annoying to implement, will grow the size of the descriptor too, right? Except it will be a guess if it uses authentication or has more introduction points (since we raised the max limit for this and one HS can have 3, one 20 for example). I think just increasing both auth and non-auth HS descriptors with 330 bytes is cleaner and simpler. >ii) Should we use the descriptor ASCII format to encode all the >client-auth-desc-key data? Or is that weird binary format OK? > If there are no indications that this can cause problems, yes of course. It's not weird if it's not "possible problematic". >iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt > does not do that, and IIUC that's OK because it uses a fresh key for > every encryption (even though the plaintext and IV is the same). > There's little cost for using a fresh IV for each ENCRYPTED_DESC_COOKIE so we should do it. > b) Do we want a NACK from the HS for when client authorization fails? > Currently >the only way for a client to learn that they are not authorized (or that >their keys changed or got revoked) is that they never complete the > rendezvous. > >To achieve that we would need a whole new cell (INTRODUCE_SERVICE_NACK) > from >the hidden service all the way to the client. Worth it? > No. I think it complicates stuff, adds extra code, adds a whole new cell and could be a potential DoS surface for a hidden service with auth enabled (you can trivially make a HS to send thousands of INTRODUCE_SERVICE_NACK cells and add extra load / bandwidth usage). I think failing with 'invalid authorization data or too many unsuccessful retries to connect to [scrubbed].onion.' if we can't complete rendezvous is ok. This way we also don't learn that a HS uses auth or doesn't exist any more or never existed, if we don't know anything about that HS and just found its address somewhere. > c) Another suggestion here by special, is to introduce an additional >layer of access control at the HSDir request level, such that HSDirs >don't even serve descriptors to clients that do not prove knowledge >of a pre-shared fetch key. > >This way unauthorized clients cannot even learn presense information of >hidden services. This might be quite useful for applications like Ricochet, >who want to hide their presense from revoked clients. > >Of course this assumes that the HSDir is honest and will honor the fetch > key >protocol. However, even if the HSDir is dishonest we are just back to the >current security level. Interesting, this doesn't sound bad. But then the protocol to fetch the descriptor from the HSDir will have additional steps, so padding at this level will be needed to ensure a HSDir cannot distinguish if it just served a descriptor for which a pre-shared fetch key was provided or not. If presence hiding is very important and we have important use cases for it, we should think about this because it sounds like a good solution. My 2 cents are that presence hiding is considerably less important than the ability to allow only who I want to reach (connect) to me, and 100% presence hiding is very hard to achieve for, in my view, little gains. > >We started sketching out a solution in the bottom of these notes: > https://people.torproject.org/~asn/hs_notes/client_auth.jpg >but the solution is not trivial to implement and we are not sure whether >it's worth complicating the protocol further (e.g. we need to design a way >for apps like Ricochet to get access to the fetch key). > > d) It might be worthwhile padding the encrypted part of INTRODUCE1 to obscure >whether client authorization is in place. > Don't understand how this exactly helps. This will hide the existence of a client authorization at introduction point side, correct? The introduction point doesn't know the hidden service, and it's rotated after a random number of introductions so the worst it can do is collect (highly inaccurate stats) about how m
Re: [tor-dev] Revisiting prop224 client authorization
> On 12 Oct 2016, at 07:58, George Kadianakis wrote: > > Hello, > > we've reached the point in prop224 development where we need to pin down > the precise cell formats, so that we can start implementing them. HS > client authorization has been one of those areas that are not yet > finalized and are still influencing cell format. > > Here are some topics based on special's old notes, plus some further > recent discussion with David and Yawning. > > a) I think the most important problem here is that the authorization-key logic > in the current prop224 is very suboptimal. Specifically, prop224 uses a > global authorization-key to ensure that descriptors are only read by > authorized clients. However, since that key is global, if we ever want to > revoke a single client we need to change the keys for all clients. The > current rend-spec.txt does not suffer from this issue, hence I adapted the > current technique to prop224. > > Please see my torspec branch `prop224_client_auth` for the proposed changes: > > https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth > > Some further questions here: > > i) Should we fake the client-auth-desc-key blob in case client authorization > is not enabled? Otherwise, we leak to the HSDir whether client auth is > enabled. The drawback here is the desc size increase (by about 330 > bytes). > > Alternatively, we can try to put it in the encrypted part of the > descriptor. So that we require subcredential knowledge to access the > encrypted part, and then client_auth_cookie knowledge to get the > encryption key to decrypt the intro points etc. I feel that this > double-encryption design might be too annoying to implement, but perhaps > it's worth it? Double-encryption, because it minimises leakage. But then the size of the descriptor probabilistically leaks client auth anyway, because 330 bytes is not that much smaller than the padding to a multiple of 512 bytes. So do we need all HSs to include either padding or a client auth section? > ii) Should we use the descriptor ASCII format to encode all the > client-auth-desc-key data? Or is that weird binary format OK? ASCII? If it's not too hard? Better to make it readable for people who have to parse and debug it. > iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt >does not do that, and IIUC that's OK because it uses a fresh key for >every encryption (even though the plaintext and IV is the same). Why not? Re-using IVs is generally bad practice, even if it works in this case. > b) Do we want a NACK from the HS for when client authorization fails? > Currently > the only way for a client to learn that they are not authorized (or that > their keys changed or got revoked) is that they never complete the > rendezvous. > > To achieve that we would need a whole new cell (INTRODUCE_SERVICE_NACK) from > the hidden service all the way to the client. Worth it? This is better UI for the client, at the cost of leaking some information about why authentication failed. In general, authentication systems try to avoid providing specific information about why authentication failed. But I'm not sure if that applies in this specific case. > c) Another suggestion here by special, is to introduce an additional > layer of access control at the HSDir request level, such that HSDirs > don't even serve descriptors to clients that do not prove knowledge > of a pre-shared fetch key. > > This way unauthorized clients cannot even learn presense information of > hidden services. This might be quite useful for applications like Ricochet, > who want to hide their presense from revoked clients. > > Of course this assumes that the HSDir is honest and will honor the fetch key > protocol. However, even if the HSDir is dishonest we are just back to the > current security level. > > We started sketching out a solution in the bottom of these notes: > https://people.torproject.org/~asn/hs_notes/client_auth.jpg > but the solution is not trivial to implement and we are not sure whether > it's worth complicating the protocol further (e.g. we need to design a way > for apps like Ricochet to get access to the fetch key). Why do we need both a fetch key and a client auth key? Isn't proving that you have a fetch key and a client auth key redundant? > d) It might be worthwhile padding the encrypted part of INTRODUCE1 to obscure > whether client authorization is in place. Yes. 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 -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists
