Re: [tor-dev] Default bridges that are not publishing statistics

[David Fifield]

On Wed, May 24, 2017 at 09:31:45PM -0700, David Fifield wrote:
> On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote:
> > Okay, thanks. It still doesn't fully make sense to me, because while
> > some of the default bridges are in Atlas, not all of them are (for
> > example the two from https://bugs.torproject.org/21917). I don't think
> > it's possible that they haven't gotten *any* client traffic.
> > 
> > I wonder if it has something to do with the tor version number?
> 
> I checked all the other default bridges and all of them but 2 are
> publishing statistics:
> C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4  cymrubridge31
> 0BAC39417268B96B9F514E7F63FA6FBA1A788955  cymrubridge33
> I will contact the operators and ask them to try setting
> "AssumeReachable 1".

The operator of these bridges set "AssumeReachable 1" and the bridges
still are not publishing statistics ("No Tor relays or bridges matched
your query :("):
https://atlas.torproject.org/#details/C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4
https://atlas.torproject.org/#details/0BAC39417268B96B9F514E7F63FA6FBA1A788955

According to the operator, the bridges are running version 0.2.9.10, so
my hypothesis about it having something to do with old version numbers
is wrong.

Roger suspects that the reason the bridges haven't reported any
statistics is because they haven't received any connections. That
possibility seems unlikely to me, because they are default bridges
shipping in Tor Browser, and additionally I have an hourly test running
that makes an obfs4 connection and builds a circuit.

I tried downloading one of the bridge's bridge-extra-info descriptors
(which would contain information about how many connections it has had),
but I can't quite make it work. Using this torrc file:
UseMicroDescriptors 0
DownloadExtraInfo 1
FetchUselessDescriptors 1
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ControlPort 9051
CookieAuthentication 1
UseBridges 1
Bridge obfs4 38.229.1.78:80 C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 
cert=Hmyfd2ev46gGY7NoVxA9ngrPF2zCZtzskRTzoWXbxNkzeVnGFPWmrTtILRyqCTjHR+s9dg 
iat-mode=1
And this Stem script:
from stem.control import Controller
with Controller.from_port(port = 9051) as controller:
controller.authenticate()
print 
controller.get_server_descriptor("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4")
I can get the bridge-server-descriptor, but not the bridge-extra-info.
Here are some lines from bridge-server-descriptor:
platform Tor 0.2.9.10 on Linux
proto Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 
Link=1-4 LinkAuth=1 Microdesc=1-2 Relay=1-2
published 2017-06-01 21:19:10
fingerprint C8CB DB24 64FC 9804 A695 3143 7BCF 2BE3 1FDD 2EE4
uptime 613949
bandwidth 1073741824 1073741824 5628404
extra-info-digest 8B5F0BD647B3C4AF2C57F148FF6A1FB8B695B0AE 
398ZHFBxUpTRfLxv+pSMY3BGMUYlzogXMG40dhjPgnA

(Furthermore, with the torrc shown above, tor doesn't save *any*
extra-info descriptors, despite the presence of "DownloadExtraInfo 1"
and "FetchUselessDescriptors 1". The datadir contains cached-certs,
cached-consensus, and cached-descriptors, but no cached-extrainfo. Only
after I change "UseBridges 1" to "UseBridges 0" does the
cached-extrainfo file appear--but then of course it doesn't contain any
information on bridges.)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Safe post-quantum RSA? So says DJB and others

[Taylor R Campbell]

> Date: Thu, 1 Jun 2017 14:03:46 +
> From: Hugo Maxwell Connery 
> 
> Interesting (and surprising):
> 
> https://eprint.iacr.org/2017/351.pdf

This joke paper is an elaborate exercise in burying the lede.

   Abstract: This paper proposes RSA parameters for which (1) key
   generation, encryption, decryption, signing, and verification are
   feasible on today's computers while (2) all known attacks are
   infeasible, even assuming highly scalable quantum computers.

   [...]

   Concrete parameters and initial implementation (buried on p. 12):
   This section looks at performance in more detail, and in particular
   reports successful generation of a 1-terabyte post-quantum RSA key
   built from 4096-bit primes.

The authors don't actually report successful cryptography operations
with such a key -- only successful generation of the key, after four
days.  The largest key they report a successful public-key operation
with was 256 GB; the largest for a private-key operation, 32 GB.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Safe post-quantum RSA? So says DJB and others

[Hugo Maxwell Connery]

Interesting (and surprising):

https://eprint.iacr.org/2017/351.pdf

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