Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration

[David Fifield]

On Fri, Nov 06, 2015 at 08:29:19PM -0500, Roger Dingledine wrote:
> On Sat, Nov 07, 2015 at 12:13:45AM +, bo...@torproject.org wrote:
> > commit 7a1c6fd121dd001eb999ef03ebbbed264da37026
> > Author: Nicolas Vigier 
> > Date:   Sat Nov 7 00:45:48 2015 +0100
> > 
> > Bug 17492: Include default bridges configuration
> > 
> > However, we exclude meek from the bridges configuration, as it currently
> > doesn't work in Tor Messenger because it requires firefox.
> 
> This could be a great opportunity for Yawning's recent meek variant that
> doesn't use an actual browser. (It won't work as well as the real meek,
> but maybe no actual adversaries care about the difference quite yet?)

You can also just run meek-client without the Firefox helper. It has a
standalone mode. Just change the torrc line

ClientTransportPlugin meek exec 
./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- 
./TorBrowser/Tor/PluggableTransports/meek-client

to

ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client

There's a man page for meek-client:
https://gitweb.torproject.org/pluggable-transports/meek.git/tree/doc/meek-client.1.txt
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration

[Yawning Angel]

On Fri, 6 Nov 2015 19:29:45 -0800
David Fifield  wrote:
> > This could be a great opportunity for Yawning's recent meek variant
> > that doesn't use an actual browser. (It won't work as well as the
> > real meek, but maybe no actual adversaries care about the
> > difference quite yet?)  
> 
> You can also just run meek-client without the Firefox helper. It has a
> standalone mode. Just change the torrc line
> 
> ClientTransportPlugin meek
> exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser
> -- ./TorBrowser/Tor/PluggableTransports/meek-client
> 
> to
> 
> ClientTransportPlugin meek
> exec ./TorBrowser/Tor/PluggableTransports/meek-client
> 
> There's a man page for meek-client:
> https://gitweb.torproject.org/pluggable-transports/meek.git/tree/doc/meek-client.1.txt

Yeah, the obfs4proxy change is mostly just to save bundle size/disk
space for android and the like.

Regards,

-- 
Yawning Angel


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

[tor-dev] Mail Address Translation Protocol Tor>Internet, Internet

[Liste]

Enter/Exit OnionMail SMTP servers connect the Internet and Tor.
The addressed must be translated from hidden service address to Internet
address ad viceversa.

There are some way to do this:

MAT = Mail Address Translation:
localpart.hiddenservice.on...@internetserver.tld =
localpart@hiddenservice.onion

VMAT = Virtual Mail Address Translation:
localpa...@internetserver.tld =
localpart2@hiddenservice.onion
(With public Database)

SMAT = Scrambled Mail Address Translation:
base32encryptedwithhc256address-hiddenserviceidandsalt...@internetserver.tld
=
localpart@hiddenservice.onion
(With private hidden service salt and id; without database).

VCMAT = Virtual circuit VMAT.
localpart2...@internetserver.tld =
(firstHop.vc@server.onion) =
(secondHop.vc@server.onion) =
...
(nHop.vc@server.onion) =
localpart@hiddenservice.onion
(False connection).
(False connection).
Available from OnionMail2.

And others

Valid characters of localpart: [a-zA-Z0-9\-\.\_]
The last part after the character dot "." declare the type of address.

*.onion = M.A.T. Address.
*.list = Mailing list.
*.news = Newsgroup.
*.op = SysOp reserved.
*.app = Applications / bot.
*.sys = OnionMail system.
*.so = Scrambled VMAT.
*.vc or *.iam = Virtual circuit VMAT.
*.o = VMAT 3 Reserved.
*.tor (or other word with 3 ot less characters) = Old only Tor address
protocol (Removed in OnionMail 1.8.1 Alpha).
*.a = Anonymous remailer address.
*.x = Reserved.
sysop = SysOp System administrator.
server = Server bot.

All others *.* are free for user as normal address local part.
Example: user.wxyz@hiddenservice.onion is a normal user's OnionMail address.
(The MAT address is: user.wxyz.hiddenservice.on...@internetsevewr.tld )

Some address functions may be encapsulated.
*.list.*.on...@internetserver.tld = A mailing list MAT address.
OR
*.l...@internetserver.tld = VMAT address of a mailing list.
VMAT Mail type must be the same of tor address type.

The special characters: +~ and others, except -_
Reserved for future use.

The special address: iam.onion
The meaning of this invalid hidden service address is "the otherside
address".
Can be used to set the local addresses on the same server only for
special users like:
sysop@iam.onion, server@iam.onion

This address is used by TORM IAM request by the OnionMail server's
IAM/InterNos protocol.
for example if you send a request "TORM IAM iam.onion V2" you will
receive the server's manifest without reversed request.

All IP addresses are set to [0.0.0.0]

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

[tor-dev] Changing Rendezvous Single Onion Service at Runtime

[teor]

Hi all,

Is there any reason an onion service would want to temporarily switch from 
1-hop to 3-hop paths?
Is it ok if we force operators to restart the tor instance when onion service 
path lengths change?

The original proposal for rendezvous single onion services (RSOS) was silent on 
whether path lengths could change at runtime. (I honestly didn't think anyone 
would do that!)

The existing proposal doesn't allow operators to run hidden services (HS) and 
RSOS on the same Tor instance at the same time. I'd like to strengthen this 
security feature, and ensure operators can't run HS and RSOS on the same 
instance sequentially. This would also mean that operators can't switch an 
onion service's flavour from HS to RSOS or vice versa at runtime.

In detail, this means that after an onion service is launched, a Tor instance 
can only run all RSOS, or all HS, until Tor is restarted.
This design change protects operators from inadvertent network address 
disclosure from running onion services with 1 and 3 hop paths on the same Tor 
instance. But it also supports an ephemeral RSOS use-case, where the operator 
launches Tor, sets (or unsets) RendezvousSingleOnionServiceNonAnonymousServer, 
then launches an onion service.

To implement this change, Tor needs to check: if 
RendezvousSingleOnionServiceNonAnonymousServer is changed, and there are any 
onion services active (excluding deleted/inactive services, if this is a 
feature of (ephemeral) services), then reject the change and warn the user. 
(Tell them to restart if they really want to change it.)

For what it's worth, the implementation is also much simpler if we force a 
restart when this parameter changes. If we start enforcing the recommended 
options, like disabling entry guards and pathbias, a restart will be even more 
important.

I've been talking with asn about this on Trac ticket #17178. Please feel free 
to comment by email or on the ticket. I'll modify the proposal after I'm sure 
this covers all use cases.

In summary:
Is there any rendezvous single onion service use case that wouldn't be possible 
with this new restriction?
I want to check we aren't breaking any neat onion service uses, if we force Tor 
to restart when changing path lengths.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Alternate Single Onion Service Designs

[teor]

Hi all,

Do we need both single onion services (Proposal 252) and rendezvous single 
onion services?
We want to enable secure usage by default, and avoid splitting anonymity sets. 
But we also want to support real-world use cases, because anonymous protocols 
are safer if more people use them.

There are currently two different proposed single onion service designs:
* Single Onion Services (SOS - Proposal 252): require an ORPort, no 
introduction/rendezvous, one-hop extend
* Rendezvous Single Onion Services (RSOS - No Proposal Number): 
introduction/rendezvous with one-hop paths

I see at least the following scenarios for using these alternate single onion 
service designs:

0. an onion service operator who wants to minimise latency and maximise 
bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous 
protocol)

1. an onion service operator runs a SOS for new clients, and an RSOS for old 
clients (a RSOS is compatible with current clients, a SOS Is not)

2. an onion service operator who can’t expose an ORPort runs a RSOS for all 
clients (there are enclave and NAT configurations where external ports are an 
issue)

3. an onion service operator who wants to use Proposal 255 for load-balancing 
runs a RSOS, and splits their introduction and rendezvous instances by passing 
the introduction over the control port (proposal 255 relies on the rendezvous 
protocol to handoff the rendezvous point connection to another Tor instance)

4. an onion service wants low latency and better bandwidth, and doesn't want to 
wait until the SOS feature is developed and deployed (SOS is a larger feature, 
and it needs client changes). They'll switch to SOS when it's well supported by 
installed versions of Tor Browser.

Given these use cases, I think we could implement both flavours of single onion 
service. But this splits the onion service anonymity set at least 3 ways (and 
maybe also by some other onion service features). I'm not sure how much of an 
impact this will have - it does depend on our threat model for each flavour of 
onion service.

If we wanted to generate more onion service cover traffic, we could move 
various automated Tor Browser actions (such as update checks and update 
downloads) to appropriate flavours of onion service. This would shift load away 
from exits, and also have address authentication benefits. (Tor Browser 
wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)

The other mitigations I'm aware of are cover traffic and lookalike protocol 
interactions, but these require significant research and design work.

We're working on implementing rendezvous single onion services in #17178. I 
think they're pretty close: we need to do some more testing, and handle some 
edge cases. RSOS servers work with existing clients, including current Tor 
Browser releases.

Single onion services (Proposal 252) is a larger feature, so it's a bit further 
away. SOS are incompatible  with current clients, so supporting code will need 
to be deployed in Tor clients (such as Tor Browser) as well as on the onion 
service itself. After the feature is ready, there will be some lead time before 
SOS are usable with the majority of deployed Tor clients.

What do you think?
Are onion services big enough to safely have multiple flavours?
Could they get that big if we support enough functionality?
Or are we better to implement secure, one-size-fits-all defaults, and ask users 
and operators to sacrifice some performance?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Changing Rendezvous Single Onion Service at Runtime

[Alec Muffett]

> On Nov 6, 2015, at 4:16 PM, teor  wrote:
> Hi all,

Hiya!

> Is there any reason an onion service would want to temporarily switch from 
> 1-hop to 3-hop paths?
> Is it ok if we force operators to restart the tor instance when onion service 
> path lengths change?

Well - as a user of RSOS, given the current state of the tor codebase, I feel 
it’s entirely reasonable that having a daemon need to cold-start in order to 
use oddball and privacy-impacting functionality be enabled.

By comparison: Tor2web requires being compiled-in before you can futz with 
connection configurations, and bans attempts to simultaneously set up 
connections in T2W and “normal” mode, so RSOS by comparison appears 
user-friendly. :-)

- alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Alternate Single Onion Service Designs

[Alec Muffett]

> On Nov 6, 2015, at 4:56 PM, teor  wrote:
> Do we need both single onion services (Proposal 252) and rendezvous single 
> onion services?

I would say they are both desirable, and that we could/should have both.

RSOS is great for adoption, the rendezvous step enables NAT-punching and yet 
lowers latency.

The NAT-punching is particularly desirable where - like in our configuration - 
the tor daemon resides in a DMZ enclave without inbound connectivity.

See diagram at: https://twitter.com/dcuthbert/status/573197027242315776/photo/1

Source: https://storify.com/AlecMuffett/tor-tips

RSOS thereby also offers a easy, nearly-no-rearchitecture-required route to 
enterprise deployment.

Also RSOS enables OnionBalance, and other performance hacks such as those 
proposed by Tom van der Woerdt 
(https://lists.torproject.org/pipermail/tor-dev/2015-October/009618.html) all 
without requiring broad changes to deployed Tor daemons

SOS by comparison sounds best where pure performance matters, but I am not sure 
how the other scaling solutions will fit into it; but pure performance matters 
a lot, so overall I think I’d like to see both.

My plans for Onion scaling are approximately as follows:

1) Remove unnecessary privacy hops / deploy RSOS (in progress)

2) OnionBalance: Merge introduction points (IPs) from multiple daemons into one 
descriptor (possible issue: there is a hardcoded limit of 3x IPs?)

3) Steven Murdoch / Ceysun Sucu research: Implement distinct OnionBalance 
descriptors at each (6?) point on the HSDir ring

These three solutions in aggregate should lower latency and scale tor daemon 
bandwidth by a range of 18..60x

Then:

4) (Wishlist) implementation of TVDW's handoff of RP callback

...which will resolve any remaining CPU-bandwidth issues.

These plans are subject to change, but seem reasonable so far.

- alec


> I see at least the following scenarios for using these alternate single onion 
> service designs:
> 
> 0. an onion service operator who wants to minimise latency and maximise 
> bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous 
> protocol)
> 
> 1. an onion service operator runs a SOS for new clients, and an RSOS for old 
> clients (a RSOS is compatible with current clients, a SOS Is not)
> 
> 2. an onion service operator who can’t expose an ORPort runs a RSOS for all 
> clients (there are enclave and NAT configurations where external ports are an 
> issue)
> 
> 3. an onion service operator who wants to use Proposal 255 for load-balancing 
> runs a RSOS, and splits their introduction and rendezvous instances by 
> passing the introduction over the control port (proposal 255 relies on the 
> rendezvous protocol to handoff the rendezvous point connection to another Tor 
> instance)
> 
> 4. an onion service wants low latency and better bandwidth, and doesn't want 
> to wait until the SOS feature is developed and deployed (SOS is a larger 
> feature, and it needs client changes). They'll switch to SOS when it's well 
> supported by installed versions of Tor Browser.
> 
> Given these use cases, I think we could implement both flavours of single 
> onion service. But this splits the onion service anonymity set at least 3 
> ways (and maybe also by some other onion service features). I'm not sure how 
> much of an impact this will have - it does depend on our threat model for 
> each flavour of onion service.
> 
> If we wanted to generate more onion service cover traffic, we could move 
> various automated Tor Browser actions (such as update checks and update 
> downloads) to appropriate flavours of onion service. This would shift load 
> away from exits, and also have address authentication benefits. (Tor Browser 
> wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)
> 
> The other mitigations I'm aware of are cover traffic and lookalike protocol 
> interactions, but these require significant research and design work.
> 
> We're working on implementing rendezvous single onion services in #17178. I 
> think they're pretty close: we need to do some more testing, and handle some 
> edge cases. RSOS servers work with existing clients, including current Tor 
> Browser releases.
> 
> Single onion services (Proposal 252) is a larger feature, so it's a bit 
> further away. SOS are incompatible  with current clients, so supporting code 
> will need to be deployed in Tor clients (such as Tor Browser) as well as on 
> the onion service itself. After the feature is ready, there will be some lead 
> time before SOS are usable with the majority of deployed Tor clients.
> 
> What do you think?
> Are onion services big enough to safely have multiple flavours?
> Could they get that big if we support enough functionality?
> Or are we better to implement secure, one-size-fits-all defaults, and ask 
> users and operators to sacrifice some performance?
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> 
> teor 

[tor-dev] Ideas for TorBrowser

[Michał Dziczkowski]

Hello. I would like to propose following for the TorBrowser:

* request folder structure change because the actual one is a big mess and it's 
hard to find anything without browsing each folder

* add the patches with fix the bugs of not working functions (like by example: 
options, addons, etc.) of current version of browser (till the next version of 
TorBrowser get ready to download)

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

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

[David Goulet]

On 06 Nov (15:35:50), George Kadianakis wrote:
> George Kadianakis  writes:
> 
> > s7r  writes:
> >
> >> Hello,
> >>
> >> 
> >>
> >> 4.1.1. Computing commitments and reveals [COMMITREVEAL]
> >> "The value REVEAL is computed as follows:
> >>
> >>   REVEAL = base64-encode( TIMESTAMP || RN )"
> >>
> >> * Maybe it is useful to also sign the REVEAL value with the SR key for
> >> broadcasting, besides keeping the unsigned one for computing COMMIT
> >> which obviously needs a separate signature. It provides some security
> >> against little effort. Useful for directory authorities who miss the
> >> commitment phase and only participate in the reveal phase. Something
> >> like this (switched TIMESTAMP's place at the end):
> >>
> >>REVEAL = base64-encode( RN || TIMESTAMP )
> >>SIGNATURE = ed25519-sign( privkey=PRIVKEY, msg=RN || TIMESTAMP )
> >>REVEAL_BROADCAST = base64-encode( RN || TIMESTAMP || SIGNATURE )
> >>
> >> where the signature is performed using a special shared randomness
> >> ed25519 key [SRKEY].
> >>
> >
> > To be honest now that we removed the conflict detection code, the SR keys 
> > are
> > almost useless, since there is already origin proof for authoritative
> > commits/reveals by listing them on the signed vote.
> >
> > I'm kinda contemplating removing the SR keys altogether, since that would 
> > remove
> > another good 500+ lines of code. It would also simplify considerably our
> > commit/reveal generation and verification procedures. It would also speed 
> > up the
> > code review procedure.
> >
> > I'm kind of sad for us killing all that nice code, but hey we can keep it 
> > in a
> > branch and use it when we actually need to.
> >
> > Let me know what you think here. Maybe i'm crazy.
> 
> and here is a spec change for this suggestion:
> 
>  
> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop250-nosrkeys-v1=4a799b3b5b7955a1b3b07475ae341c37b29c1f3b
> 
> Let me know what you think.

It's indeed weird to keep lots of code and a section in the proposal
that actually is useless. The only argument I can see to keep it is for
"future use" if we want to start addressing partition attack directly in
the code for instance or other _unknown_ design flaw.

That being said, I think we can knife it. The code will still exists in
a branch somewhere and we are starting to get quite a good understanding
of the problem space here ;).

Now question about the commit above ^:

+   where the ID_a value is the identity key fingerprint of authority 'a' and 
R_a
+   is the corresponding reveal value of that authority for the current period.

We had this discussion before and also asked Nick about this. We should
_NOT_ use the RSA key here of the authority and as far as I know we
don't have the ed25519 key of an authority accessible in the vote?

Also, the TIMESTAMP was removed. Can you explain why? I like it even
though it doesn't have a direct practical use in the protocol. With it
we can know when the authority generated its commit and it's an extra
nice check to match commit/reveal value (you know avoiding unknown crazy
replay attack :P). I see it useful for debugging potential issues in the
long run since in the vote (and sr-state) we'll have a data point on
when the authority did generate that commitment.

Apart from that, I vote go on the removal of SR keys.

Cheers!
David

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


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

[tor-dev] DoS resistance for Next-Generation Onion Services

[teor]

Hi all,

I think we can make next-generation onion (hidden) services (proposal #224) 
more resilient against certain kinds of DoS / client discovery attacks, by 
using a different blinded public key for each HSDir.

Attack Summary:

Once a malicious HSDir receives a descriptor, it can locate other HSDirs with 
that descriptor's blinded public key. It doesn't need to know the onion service 
address or decrypt the descriptor. Each descriptor contains the blinded public 
key:

> The 'certificate' field contains a certificate in the format from proposal 
> 220, with the short-term ed25519 descriptor-signing key signed by the blinded 
> public key. It must contain a ed25519-signing-key extension containing the 
> blinded public key.

(All quotes are from 
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt 
 
)

This allows an attacker to target onion services for DoS, as long as they don't 
care which onion service they're targeting.

The effects of this attack could be:
* if the malicious HSDir also stops serving the descriptor, it denies service 
to some onion service,
* if the malicious HSDir continues to serve the descriptor, it becomes the only 
source of descriptors for some onion service.

I think this enables traffic confirmation attacks on some onion service or its 
clients (by bringing the sole descriptor source up and down). Client descriptor 
downloads could also be subject to traffic fingerprinting or slow 
(byte-at-a-time) delivery.

Attack Details:

Let's assume an attacker who:
* doesn't know any onion service addresses
* runs a malicious HSDir that collects blinded public keys
* can check other HSDirs for descriptors based on blinded public keys
* wants to DoS some onion services, but doesn't care which ones

This attacker then:
1. chooses an arbitrary blinded public key from their HSDir's collection
2. calculates possible HSDirs for the blinded public key
3. checks each of the possible HSDirs to see if they actually have a descriptor 
with that blinded public key
4. runs a DoS on each HSDir with that blinded public key (this is the 
resource-intensive step)

A refinement of the attack is to:
A. find the HSDirs for each blinded public key uploaded to the malicious HSDir 
(steps 1-3)
B. find the blinded public keys with the most vulnerable HSDirs (perhaps using 
the maximum consensus weight among all 5)
C. DoS the blinded public keys with the most vulnerable HSDirs (step 4)

I think this is a plausible attack that could be run repeatedly until the 
attacker happens to hit a high-value onion service, or a high enough number of 
onion services. The targeted onion services would change blinded keys and 
HSDirs with the next shared random period, but they'd be down for up to 24 
hours.

Mitigation Summary:

If each onion service uploads a descriptor with a different blinded public key 
to each HSDir, a malicious HSDir is unable to locate other HSDirs serving the 
same onion service.

Even with this change, an attacker who knows an onion service's address can 
still find all its HSDirs. They can set up a malicious HSDir and wait unit it 
happens to get chosen as the HSDir for that service. But this targeted attack 
requires more resources and time than the unknown target attack I describe 
above. The unknown target attack can also consider hundreds of blinded public 
keys, and target the ones with the weakest HSDirs. The targeted attack is 
unlikely to host a particular descriptor on a malicious HSDir, and also 
simultaneously find that all the other HSDirs for that descriptor are 
vulnerable to a DoS.

Alternative Mitigations:

The current keyblinding nonce is based on the period number and start time. 
This allows the blinded keys to be generated in advance. But the drawback is 
that the blinded key is the same for each HSDir.

> There is a master keypair (sk, pk). Given the keypair and a nonce n, there is 
> a derivation function that gives a new blinded keypair (sk_n, pk_n). This 
> keypair can be used for signing. Given only the public key and the nonce, 
> there is a function that gives pk_n.
> …
> 
> We propose the following scheme for key blinding, based on Ed25519.
> 
>   (This is an ECC group, so remember that scalar multiplication is the
>   trapdoor function, and it's defined in terms of iterated point
>   addition. See the Ed25519 paper [Reference ED25519-REFS] for a fairly
>   clear writeup.)
> 
>   Let the basepoint be written as B. Assume B has prime order l, so
>   lB=0. Let a master keypair be written as (a,A), where a is the private
>   key and A is the public key (A=aB).
> 
>   To derive the key for a nonce N and an optional secret s, compute the
>   blinding factor h as H(A | s, B, N), and let:
> 
>   private key for the period:   a' = h a
>   public key for the period:A' = h A = (ha)B
> 
> Generating a signature of M: given a deterministic random-looking r (see 

Re: [tor-dev] Alternate Single Onion Service Designs

[Tim Wilson-Brown - teor]

> On 7 Nov 2015, at 04:36, Alec Muffett  wrote:
> 
> These three solutions in aggregate should lower latency and scale tor daemon 
> bandwidth by a range of 18..60x
> 
> Then:
> 
> 4) (Wishlist) implementation of TVDW's handoff of RP callback
> 
> ...which will resolve any remaining CPU-bandwidth issues.
> 
> These plans are subject to change, but seem reasonable so far.

Rendezvous handoff is partially implemented in:
https://trac.torproject.org/projects/tor/ticket/17254 


I think we're waiting on the following:
* a more detailed specification of the handoff data fields for current and 
next-generation onion services, so we can be sure it's future-proof (I believe 
this is the decrypted and parsed cell content)
* confirmation that the introduction-side will decrypt (and parse) the 
INTRODUCE2 cell, to avoid sending introduction point private keys over the 
control port (this puts slightly more load on the introduction point, but a 
single message compromise would only compromise that rendezvous, not all the 
rendezvous for that day from that introduction point)

Together, these two changes would also support the "rendezvous approver" 
control port feature, where the handoff controller can filter requests as 
needed based on their content or on external factors such as load.

This also might be a nice way of doing geographical load-balancing: an 
introduction for a European rendezvous point could be sent to a nearby European 
data center to perform the actual rendezvous. Alternately, it could be send to 
a lightly-loaded instance.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting

[George Kadianakis]

George Kadianakis  writes:

> s7r  writes:
>
>> Hello,
>>
>> 
>>
>> 4.1.1. Computing commitments and reveals [COMMITREVEAL]
>> "The value REVEAL is computed as follows:
>>
>>   REVEAL = base64-encode( TIMESTAMP || RN )"
>>
>> * Maybe it is useful to also sign the REVEAL value with the SR key for
>> broadcasting, besides keeping the unsigned one for computing COMMIT
>> which obviously needs a separate signature. It provides some security
>> against little effort. Useful for directory authorities who miss the
>> commitment phase and only participate in the reveal phase. Something
>> like this (switched TIMESTAMP's place at the end):
>>
>>  REVEAL = base64-encode( RN || TIMESTAMP )
>>  SIGNATURE = ed25519-sign( privkey=PRIVKEY, msg=RN || TIMESTAMP )
>>  REVEAL_BROADCAST = base64-encode( RN || TIMESTAMP || SIGNATURE )
>>
>> where the signature is performed using a special shared randomness
>> ed25519 key [SRKEY].
>>
>
> To be honest now that we removed the conflict detection code, the SR keys are
> almost useless, since there is already origin proof for authoritative
> commits/reveals by listing them on the signed vote.
>
> I'm kinda contemplating removing the SR keys altogether, since that would 
> remove
> another good 500+ lines of code. It would also simplify considerably our
> commit/reveal generation and verification procedures. It would also speed up 
> the
> code review procedure.
>
> I'm kind of sad for us killing all that nice code, but hey we can keep it in a
> branch and use it when we actually need to.
>
> Let me know what you think here. Maybe i'm crazy.

and here is a spec change for this suggestion:

 
https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop250-nosrkeys-v1=4a799b3b5b7955a1b3b07475ae341c37b29c1f3b

Let me know what you think.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev