[tor-dev] GSoC final progress update (Stegotorus)
The following tickets were largely achieved (last is in process of debugging) - adding config file (see branch https://github.com/TheTorProject/stegotorus/tree/f--modus-operandi) - adding elligator handshake ( https://github.com/TheTorProject/stegotorus/tree/f--circuit-handshake) [0] - moving remaining stegs over to class-based structure (see note (1) below) (https://github.com/TheTorProject/stegotorus/tree/f--file-stegize-swf-js-pdf ) The following are on deck and I intend to work on them after GSoC code submission date of August 22. - SOCKS proxy over wire from Tor (see https://github.com/SRI-CSL/stegotorus/commit/2d4ac59b8112611a7b63a1c5b15dfb710eed0631 and https://github.com/SRI-CSL/stegotorus/commit/c799f30249c5e1dfbcc1adfe68f6bd36880fcbd4 ) - adding SRI code into Tor fork (such as new JSON steg) - this was simply not anywhere near ready in time for the summer, but now has TBB and gitian ready to go - making transparent proxy robust (as security measure in case stegotorus server is probed) [0] this needs one last check for out of order packets. [1] I was hypothesizing that new larger default buffer size or excessive pointer casting was causing performance issues, but perusal of JavaScript patch via valgrind revealed memory leaks in the decompression methods of several steg mod classes. I am in the process of addressing this. This causes intermittent, not consistent failures, so unit tests would not consistently catch this. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Decentralized VOIP over Tor
I looked at Ostel. Can Ostel be routed over Tor or is there another way to get anonymity using Ostel? I said decentralized VOIP because no central servers would be managing the communications. Any Tor node could possibly be a VOIP server. The network data would have to be continually distributed throughout Tor. Also I was thinking about an option for a user to generate and use their own AES keys via air gap or Diffie–Hellman. I'm interested in this because there's way too many good people hurt by the eavesdropping on telecommunication networks. Thanks, --TZ Original Message From: Jordan jorda...@sent.com To: tor-dev@lists.torproject.org Cc: ter...@safe-mail.net Subject: Re: [tor-dev] Decentralized VOIP over Tor Date: Fri, 15 Aug 2014 18:43:22 -0700 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Orbot Orfox - GSoC bi-weekly report 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Status Report 6 August 17th, 2014. So the past couple of weeks have been a little more hectic than usual, but these are the things that I got to work on: 1) Continuing work on fixing leak: On the Mozilla side, I had a long discussion with snorp and rnewman, they seem to have an idea to solve proxying everything through the added proxy settings but this is going to be one massive bug, so I haven't been able to land it yet. Bugs are http://bugzil.la/942652, http://bugzil.la/942653 and http://bugzil.la/942654. Fixing the first two should solve the dns leak. 2) Temporary loadFavicon fix: As you will be able to see my changes at https://github.com/amoghbl1/gecko-dev/commit/4baa2111b7d8a90af5b7bb787cc9d52ae3ab92eb , I have a temporary fix for this, but hopefully this won't be necessary after the above mentioned bugs are fixed. 3) Getting Orfox built on the guardian projects build server: Hopefully this will be done before Monday, although all the code for the app is there, if we could provide the apk officially before hard pencils down, it would be nicer. This has been one great summer for me, I've had loads of fun, learned a lot and met some amazing people. I thank everyone for their support and look forward to continuing working with you guys. -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJT8KzvAAoJELm/SSKdtjUkrS8IAIrgJYhvdoa6+7HGfHPqu0cq ocQX8Hd67hXwHrtGHmmdS3c7aCOyV4K0g/aGi4WTVbFRqd+tFzHNK9zTKYpUvXXP wfuORN/SKWCnjLrmjQ6ZXks1+mq7lnaTxSAPYo4GCJj6nTbDzDZryHlHncxMQheA VoU+0JV9bg7OAYpLDaF/4/TPSqG1KE5H5Ae633dXBt0/dmMhFmhNtfJdbNrlilIz UleRhERZe5h94Bz6QYJtCeD0zOdnHxI0udT73c7MYCLTiS7SxFssZYuUiE1grpHl GgVvnR8vfwFCgz7O6WLven+bfOMGZV0ZJZCIPopyZ7HXw034WmTgKLbLQl2H1cM= =ymdp -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] On picking Introduction Points in Next Generation Hidden Services
Matthew Finkel matthew.fin...@gmail.com writes: On Tue, Aug 12, 2014 at 02:05:49PM +0300, George Kadianakis wrote: One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here: - How many IPs should an HS have? - Which relays can be IPs? - What's the lifetime of an IP? --Snip-- ==How many IPs should an HS have?== Now let's investigate how many IPs an HS should have. The current situation is that HSes attempt to estimate their own popularity [2], and then they launch a number of IPs between 3 and 10 depending on how popular they think they are. FWIW, we don't really understand whether the formula works properly [3]. There are a few options for the future here: a) Fix the formula and keep number of IPs dynamic based on the popularity of the HS. This is not a bad idea. However, we should make sure that from the number of IPs you can't easily derive the number of clients of the HS. Also we should make sure that the formula works properly. b) Have a static amount of IPs per HS. For example '5' of them. I'm not sure what kind of calculations we need to do to find the right constant here (same for the (a) option). c) Have a static amount of IPs per HS, but also allow this to be configurable by the HS operator. The idea here is that popular HSes can pump up the number of IPs to make the service more reachable. It's worth noting that HSes who do so will stand out as manually configured; not sure if any other partition attacks can happen here. Also, there is also the danger of all HS operators thinking they are special and pumping the number of IPs to 42. There's also the choice ac) allow the HS operator to set a fixed number or allow them to set an upper limit of IPs and let Tor dynamically allocate them depending on popularity. Many choices :) Something else we can consider is publishing multiple versions of the HS descriptor, each containing a subset of IPs. An adversary will need to collect them all to see the full picture and know how popular the HS thinks it is. On the other hand, it is likely better for a HS operator to simply add more HS addresses when their popularity increases. This decreases the usability of the HS, though, and relies on users understanding why they should uniformly distribute their connections over the various connections. Generally, we want to have a healthy amount of IPs (so that they don't get DoSed, and that requests get load balanced nicely), but also not too many because every HS having many IP circuits will put a load to the network (especially with services like Torchat where each client is an HS), and also because we want to avoid too many nodes becoming our IPs over time (more on this below). We should consider profiling the affect of an IP circuit on the network. Granted, we shouldn't waste any unnecessary bandwidth on useless connections, but I wonder how much load is really added. Right. FWIW, the only rationale for `#define NUM_INTRO_POINTS_MAX 10` that I know about, is Robert's post: https://trac.torproject.org/projects/tor/ticket/4862#comment:13 . Maybe we need to estimate the number of HSes we want the Tor network to be able to support, and then calculate how many circuits the Tor network can handle, and then... ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] PKCS#1 ASN.1 Public Key Encoding
Hi all I wonder if someone might be able to help me with the above. I understand, that to generate the digest, the PK must be encoded in PKCS#1 format. And further to this, the public keys in the router descriptors are NOT in PKCS#1 format, but plain ASN.1. I'm trying to generate the fingerprint given just the pubilc key in Java and after almost a whole day I'm about to give up. Does anyone have a sample PKCS#1 encoded public key that is used immediately before SHA-1 to generate the fingerprint? e.g. a hex string is what I'm after. It seems there are subtle ways that an PKCS#1 can vary while encoding the same information which affects the hash, Java seems to be doing it one way, OpenSSL another, an example on stack overflow adds an extra field, etc. Many thanks Gareth ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Decentralized VOIP over Tor
ter...@safe-mail.net: I said decentralized VOIP because no central servers would be managing the communications. Any Tor node could possibly be a VOIP server. Tor is a transport network. Relays only transport data, they do not offer services other than what's needed for Tor clients to work. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PKCS#1 ASN.1 Public Key Encoding
On Sun, 17 Aug 2014 16:19:56 +0100
Gareth Owen gareth.o...@port.ac.uk wrote:
I'm trying to generate the fingerprint given just the pubilc key in
Java and after almost a whole day I'm about to give up. Does anyone
have a sample PKCS#1 encoded public key that is used immediately
before SHA-1 to generate the fingerprint? e.g. a hex string is what
I'm after.
Both descriptors and microdescriptors contain this in the appropriate
format (albeit Base64 encoded and with a PEM envelope). Check the data
directory of a running tor instance and look at
cached-microdescs(.new), which will have onion-key entries for all the
relays.
It seems there are subtle ways that an PKCS#1 can vary while encoding
the same information which affects the hash, Java seems to be doing
it one way, OpenSSL another, an example on stack overflow adds an
extra field, etc.
The way that you care about (that matches how tor does it) is specified
in RFC 2313.
7.1 Public-key syntax
An RSA public key shall have ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e }
(This type is specified in X.509 and is retained here for
compatibility.)
How to do this in Java depends on which crypto API you are using, look
at oracle.security.crypto.asn1 or org.bouncycastle.asn1. Additionally
this (http://lapo.it/asn1js/) will probably be useful.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PKCS#1 ASN.1 Public Key Encoding
Yawning
Thanks very much - you've saved me another few days down the wrong path!
It seems I was taking the onion-key not the signing key. Would never have
caught that this far down the rabbit hole without your response!
Now to work out why Tor is detecting a different identity to the SSL cert
I'm sending.
Best
Garth
On 17 August 2014 17:06, Yawning Angel yawn...@schwanenlied.me wrote:
On Sun, 17 Aug 2014 16:19:56 +0100
Gareth Owen gareth.o...@port.ac.uk wrote:
I'm trying to generate the fingerprint given just the pubilc key in
Java and after almost a whole day I'm about to give up. Does anyone
have a sample PKCS#1 encoded public key that is used immediately
before SHA-1 to generate the fingerprint? e.g. a hex string is what
I'm after.
Both descriptors and microdescriptors contain this in the appropriate
format (albeit Base64 encoded and with a PEM envelope). Check the data
directory of a running tor instance and look at
cached-microdescs(.new), which will have onion-key entries for all the
relays.
It seems there are subtle ways that an PKCS#1 can vary while encoding
the same information which affects the hash, Java seems to be doing
it one way, OpenSSL another, an example on stack overflow adds an
extra field, etc.
The way that you care about (that matches how tor does it) is specified
in RFC 2313.
7.1 Public-key syntax
An RSA public key shall have ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e }
(This type is specified in X.509 and is retained here for
compatibility.)
How to do this in Java depends on which crypto API you are using, look
at oracle.security.crypto.asn1 or org.bouncycastle.asn1. Additionally
this (http://lapo.it/asn1js/) will probably be useful.
Regards,
--
Yawning Angel
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
Dr Gareth Owen
Senior Lecturer
School of Computing, University of Portsmouth
Tel: 02392 846423
Web: ghowen.me
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Consensus diffs - Sixth report
Hello everyone, This is the sixth and last status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. Two weeks ago I had two main tasks left for the project to get to a minimal functioning state. The first was to figure out a clean way to cache old consensuses on disk. The second was to write the fetching of consensus diffs, and the corresponding serving of consensus diffs via spooling. Both of these were done, and last week I was able to launch a small local network via chutney and finally see consensus diffs be properly generated, served, fetched and applied. The hard pencils down date is tomorrow evening. I want to polish things up a bit and try to find last-minute bugs. Of course there will be quite a bit of work left once GSoC is over to get the outcome of this project included in Tor. Other than that, I'm quite happy with how the project turned out. I intend to continue contributing to Tor, at least to the extent of getting the code merged into master and fixing any bugs that may arise until it is suitable for a stable release. I'll continue pushing my work on Github [1] for now. See the readme branch for reference on what the consdiff-N branches mean. Regards. [1] https://github.com/mvdan/tor -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519
Hi Nick, On 25 Feb 2014, at 17:18, Nick Mathewson ni...@torproject.org wrote: To mirror the way that authority identity keys work, we'll fully support keeping Ed25519 identity keys offline; they'll be used to sign long-ish term signing keys, which in turn will do all of the heavy lifting. A signing key will get used to sign the things that RSA1024 identity keys currently sign. There was a discussion of this point on tor-talk just now. s7r (one of the nice support people) was also present, maybe he will follow up here as well. Basically, the operational complexity of doing this seems to be under-appreciated here, and we're wondering if the added code complexity can possibly be worth it. Maybe we should ask some of the super big relays to weigh in. Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
