Re: [tor-dev] PQ crypto updates

2017-08-23 Thread Yawning Angel
On Tue, 22 Aug 2017 20:47:06 +0200
Peter Schwabe  wrote:
> Yawning Angel  wrote:
> 
> Hi Yawning, hi all,
> 
> > Ultimately none of this matters because Prop. 261 is dead in the
> > water.  Assuming people want the new cell crypto to be both fragile
> > and to resist tagging attacks, Farfalle may be a better choice,
> > assuming there's a Keccak-p parameterization such that it gives
> > adequate performance.  
> 
> At what number of cycles/block on what architecture(s) would you call
> the performance "adequate"?

Note, I'm not hating on Farfalle, I need to look at it more, and the
last time I gave serious thought to this question in a Tor context was
back around the time Prop 261 was being drafted.

The answer to this from my point of view is "not slow to the point
where the network falls over", which I'll admit is extremely handwavy,
but truth be told, I have no idea what fraction of the relays are on
what micro architectures these days.

Looking at the Farfalle and Kangaroo 12 papers, Kravette may be ok with
AVX2 assuming I'm extrapolating correctly.  But, while it's probably
reasonable to assume that all the fast existing relays have AES-NI, I
do not know what fraction of those predate AVX2.

Part of me thinks that focusing on raw primitive performance is a bit
silly (even though I'm the one that brought it up), because just about
anything will likely deliver adequate performance if the cell crypto
used more than one core[0].

Sorry I don't have anything more concrete. :(

Regards,

-- 
Yawning Angel

[0]: And another part of me kind of wants to say "eat the overhead of a
MAC per hop and use AES-GCM-SIV or something".


pgpMDM6QwTKuq.pgp
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] Tor and IP2Location LITE

2017-08-23 Thread Iain R. Learmonth
Hi,

On 23/08/17 03:45, KL Liew wrote:
>> How is your accuracy for data centres?
> 
> I don't aware of any research papers targeting data center only.
> IP2Location should be highly accurate because we are using network
> routing information to determine physical location instead of registrant
> address.
> 
> For example, IP2Location is reporting 185.56.163.144 as in France after
> reviewing the network routing information as below. However, if you
> search the same IP address in other geolocation providers, you might see
> it as reported as North Korea, a country with limited Internet access.

It is possible that this address is used by North Korea, they don't have
a massive IP allocation and I would expect that perhaps there are some
tunnels, but I can't figure out where MaxMind have got this idea from.

I think GeoIP is actually a far more difficult problem when it's not
typical residential customers. Satellite customers, for instance, may
use IP blocks that are spread across multiple countries.

I would expect that cloud providers and larger datacenter providers are
using tunnels of sorts between their datacenters. Tunnels kill any
visibility into the real routing path.

When attempting to perform GeoIP for routers, the problem is compounded
as you don't know who really owns the router based on IP addresses
alone, routers having multiple IP addresses, etc.

With the influx of new TLDs and TLDs being chosen for vanity purposes,
they are also not a useful indicator.

I fear its the smaller providers, the more Tor-friendly providers, that
are missing or inaccurately represented in the databases.

When it comes to measuring the accuracy of databases for datacenters, I
wonder if there could be some means for relay operators to self-report a
location and then we can compare this with different databases.

Is there a safe way for relay operators to prove that they control a
relay and self-report the location of the relay without us having to
have an extra field in relay descriptors or overload the contact field?
Some sort of out-of-band means?

Thanks,
Iain.





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] Tor and IP2Location LITE

2017-08-23 Thread KL Liew
Please find my comments below.

> It is possible that this address is used by North Korea, they don't have
> a massive IP allocation and I would expect that perhaps there are some
> tunnels, but I can't figure out where MaxMind have got this idea from.

We aware of a small number of IP ranges tunneling to North Korea through
some specific ISP. However, this IP address is registered by a VPN provider
which also registered ranges in many other countries. We have no evidence
that this VPN provider has a server located in those countries reported for
their VPN service.

> I think GeoIP is actually a far more difficult problem when it's not
> typical residential customers. Satellite customers, for instance, may
> use IP blocks that are spread across multiple countries.
>
> I would expect that cloud providers and larger datacenter providers are
> using tunnels of sorts between their datacenters. Tunnels kill any
> visibility into the real routing path.

The large cloud providers such as AWS and Azure publishes their data center
and IP addresses range to public. Data centers usually avoiding tunnels due
to performance and cost-effectiveness. We do see rare cases required
tunnels such as DDoS protection.

> When it comes to measuring the accuracy of databases for datacenters, I
> wonder if there could be some means for relay operators to self-report a
> location and then we can compare this with different databases.

If this is possible, then it is a good way to perform benchmarking.
However, we need to make sure the relay operator is giving the right
information.


- Kim


On Thu, Aug 24, 2017 at 3:50 AM, Iain R. Learmonth 
wrote:

> Hi,
>
> On 23/08/17 03:45, KL Liew wrote:
> >> How is your accuracy for data centres?
> >
> > I don't aware of any research papers targeting data center only.
> > IP2Location should be highly accurate because we are using network
> > routing information to determine physical location instead of registrant
> > address.
> >
> > For example, IP2Location is reporting 185.56.163.144 as in France after
> > reviewing the network routing information as below. However, if you
> > search the same IP address in other geolocation providers, you might see
> > it as reported as North Korea, a country with limited Internet access.
>
> It is possible that this address is used by North Korea, they don't have
> a massive IP allocation and I would expect that perhaps there are some
> tunnels, but I can't figure out where MaxMind have got this idea from.
>
> I think GeoIP is actually a far more difficult problem when it's not
> typical residential customers. Satellite customers, for instance, may
> use IP blocks that are spread across multiple countries.
>
> I would expect that cloud providers and larger datacenter providers are
> using tunnels of sorts between their datacenters. Tunnels kill any
> visibility into the real routing path.
>
> When attempting to perform GeoIP for routers, the problem is compounded
> as you don't know who really owns the router based on IP addresses
> alone, routers having multiple IP addresses, etc.
>
> With the influx of new TLDs and TLDs being chosen for vanity purposes,
> they are also not a useful indicator.
>
> I fear its the smaller providers, the more Tor-friendly providers, that
> are missing or inaccurately represented in the databases.
>
> When it comes to measuring the accuracy of databases for datacenters, I
> wonder if there could be some means for relay operators to self-report a
> location and then we can compare this with different databases.
>
> Is there a safe way for relay operators to prove that they control a
> relay and self-report the location of the relay without us having to
> have an extra field in relay descriptors or overload the contact field?
> Some sort of out-of-band means?
>
> Thanks,
> Iain.
>
>
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


Re: [tor-dev] Tor and IP2Location LITE

2017-08-23 Thread Zack Weinberg
On Wed, Aug 23, 2017 at 9:36 PM, KL Liew  wrote:
>
>> It is possible that this address is used by North Korea, they don't have
>> a massive IP allocation and I would expect that perhaps there are some
>> tunnels, but I can't figure out where MaxMind have got this idea from.
>
> We aware of a small number of IP ranges tunneling to North Korea through
> some specific ISP. However, this IP address is registered by a VPN provider
> which also registered ranges in many other countries. We have no evidence
> that this VPN provider has a server located in those countries reported for
> their VPN service.

Allow me to jump in here and mention that I have done some work on
auditing the locations of VPN servers via active probes (very briefly:
pingtimes to hosts in known locations give upper bounds on the
distances to those hosts), and I suspect I know which VPN provider you
are referring to and their claims are indeed ... let's say
questionable. I'm not yet at liberty to share any more details of my
results, but you may find the software at
https://github.com/zackw/active-geolocator/ of interest.

Applying the same techniques to Tor is something I would be interested
in helping with, though not a personal priority.

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