July 2018 - cypherpunks-legacy

Tor 0.1.0.10 is released
by Roger Dingledine 06 Jul '18

06 Jul '18

Tor 0.1.0.10, the first stable release of the 0.1.0.x branch, is finally ready. This release features cleanup on Windows, including making NT services work; many performance improvements, including libevent to use poll/epoll/kqueue when available, and pthreads and better buffer management to avoid so much memory bloat; better performance and reliability for hidden services; automated self-reachability testing by servers; http and https proxy support for clients; and much more support for the Tor controller protocol. http://tor.eff.org/download.html o Fixes on Win32: - Make NT services work and start on startup on Win32 (based on patch by Matt Edman). See the FAQ entry for details. - Make 'platform' string in descriptor more accurate for Win32 servers, so it's not just "unknown platform". - REUSEADDR on normal platforms means you can rebind to the port right after somebody else has let it go. But REUSEADDR on Win32 means you can bind to the port _even when somebody else already has it bound_! So, don't do that on Win32. - Clean up the log messages when starting on Win32 with no config file. - Allow seeding the RNG on Win32 even when you're not running as Administrator. If seeding the RNG on Win32 fails, quit. o Assert / crash bugs: - Refuse relay cells that claim to have a length larger than the maximum allowed. This prevents a potential attack that could read arbitrary memory (e.g. keys) from an exit server's process. - If unofficial Tor clients connect and send weird TLS certs, our Tor server triggers an assert. Stop asserting, and start handling TLS errors better in other situations too. - Fix a race condition that can trigger an assert when we have a pending create cell and an OR connection attempt fails. o Resource leaks: - Use pthreads for worker processes rather than forking. This was forced because when we forked, we ended up wasting a lot of duplicate ram over time. - Also switch to foo_r versions of some library calls to allow reentry and threadsafeness. - Implement --disable-threads configure option. Disable threads on netbsd and openbsd by default, because they have no reentrant resolver functions (!), and on solaris since it has other threading issues. - Fix possible bug on threading platforms (e.g. win32) which was leaking a file descriptor whenever a cpuworker or dnsworker died. - Fix a minor memory leak when somebody establishes an introduction point at your Tor server. - Fix possible memory leak in tor_lookup_hostname(). (Thanks to Adam Langley.) - Add ./configure --with-dmalloc option, to track memory leaks. - And try to free all memory on closing, so we can detect what we're leaking. o Protocol correctness: - When we've connected to an OR and handshaked but didn't like the result, we were closing the conn without sending destroy cells back for pending circuits. Now send those destroys. - Start sending 'truncated' cells back rather than destroy cells if the circuit closes in front of you. This means we won't have to abandon partially built circuits. - Handle changed router status correctly when dirserver reloads fingerprint file. We used to be dropping all unverified descriptors right then. The bug was hidden because we would immediately fetch a directory from another dirserver, which would include the descriptors we just dropped. - Revise tor-spec to add more/better stream end reasons. - Revise all calls to connection_edge_end to avoid sending 'misc', and to take errno into account where possible. - Client now retries when streams end early for 'hibernating' or 'resource limit' reasons, rather than failing them. - Try to be more zealous about calling connection_edge_end when things go bad with edge conns in connection.c. o Robustness improvements: - Better handling for heterogeneous / unreliable nodes: - Annotate circuits with whether they aim to contain high uptime nodes and/or high capacity nodes. When building circuits, choose appropriate nodes. - This means that every single node in an intro rend circuit, not just the last one, will have a minimum uptime. - New config option LongLivedPorts to indicate application streams that will want high uptime circuits. - Servers reset uptime when a dir fetch entirely fails. This hopefully reflects stability of the server's network connectivity. - If somebody starts his tor server in Jan 2004 and then fixes his clock, don't make his published uptime be a year. - Reset published uptime when we wake up from hibernation. - Introduce a notion of 'internal' circs, which are chosen without regard to the exit policy of the last hop. Intro and rendezvous circs must be internal circs, to avoid leaking information. Resolve and connect streams can use internal circs if they want. - New circuit pooling algorithm: keep track of what destination ports we've used recently (start out assuming we'll want to use 80), and make sure to have enough circs around to satisfy these ports. Also make sure to have 2 internal circs around if we've required internal circs lately (and with high uptime if we've seen that lately too). - Turn addr_policy_compare from a tristate to a quadstate; this should help address our "Ah, you allow 1.2.3.4:80. You are a good choice for google.com" problem. - When a client asks us for a dir mirror and we don't have one, launch an attempt to get a fresh one. - First cut at support for "create-fast" cells. Clients can use these when extending to their first hop, since the TLS already provides forward secrecy and authentication. Not enabled on clients yet. o Reachability testing. - Your Tor server will automatically try to see if its ORPort and DirPort are reachable from the outside, and it won't upload its descriptor until it decides at least ORPort is reachable (when DirPort is not yet found reachable, publish it as zero). - When building testing circs for ORPort testing, use only high-bandwidth nodes, so fewer circuits fail. - Notice when our IP changes, and reset stats/uptime/reachability. - Authdirservers don't do ORPort reachability detection, since they're in clique mode, so it will be rare to find a server not already connected to them. - Authdirservers now automatically approve nodes running 0.1.0.2-rc or later. o Dirserver fixes: - Now we allow two unverified servers with the same nickname but different keys. But if a nickname is verified, only that nickname+key are allowed. - If you're an authdirserver connecting to an address:port, and it's not the OR you were expecting, forget about that descriptor. If he *was* the one you were expecting, then forget about all other descriptors for that address:port. - Allow servers to publish descriptors from 12 hours in the future. Corollary: only whine about clock skew from the dirserver if he's a trusted dirserver (since now even verified servers could have quite wrong clocks). - Require servers that use the default dirservers to have public IP addresses. We have too many servers that are configured with private IPs and their admins never notice the log entries complaining that their descriptors are being rejected. o Efficiency improvements: - Use libevent. Now we can use faster async cores (like epoll, kpoll, and /dev/poll), and hopefully work better on Windows too. - Apple's OS X 10.4.0 ships with a broken kqueue API, and using kqueue on 10.3.9 causes kernel panics. Don't use kqueue on OS X. - Find libevent even if it's hiding in /usr/local/ and your CFLAGS and LDFLAGS don't tell you to look there. - Be able to link with libevent as a shared library (the default after 1.0d), even if it's hiding in /usr/local/lib and even if you haven't added /usr/local/lib to your /etc/ld.so.conf, assuming you're running gcc. Otherwise fail and give a useful error message. - Switch to a new buffer management algorithm, which tries to avoid reallocing and copying quite as much. In first tests it looks like it uses *more* memory on average, but less cpu. - Switch our internal buffers implementation to use a ring buffer, to hopefully improve performance for fast servers a lot. - Reenable the part of the code that tries to flush as soon as an OR outbuf has a full TLS record available. Perhaps this will make OR outbufs not grow as huge except in rare cases, thus saving lots of CPU time plus memory. - Improve performance for dirservers: stop re-parsing the whole directory every time you regenerate it. - Keep a big splay tree of (circid,orconn)->circuit mappings to make it much faster to look up a circuit for each relay cell. - Remove most calls to assert_all_pending_dns_resolves_ok(), since they're eating our cpu on exit nodes. - Stop wasting time doing a case insensitive comparison for every dns name every time we do any lookup. Canonicalize the names to lowercase when you first see them. o Hidden services: - Handle unavailable hidden services better. Handle slow or busy hidden services better. - Cannibalize GENERAL circs to be C_REND, C_INTRO, S_INTRO, and S_REND circ as necessary, if there are any completed ones lying around when we try to launch one. - Make hidden services try to establish a rendezvous for 30 seconds after fetching the descriptor, rather than for n (where n=3) attempts to build a circuit. - Adjust maximum skew and age for rendezvous descriptors: let skew be 48 hours rather than 90 minutes. - Reject malformed .onion addresses rather then passing them on as normal web requests. o Controller: - More Tor controller support. See http://tor.eff.org/doc/control-spec.txt for all the new features, including signals to emulate unix signals from any platform; redirectstream; extendcircuit; mapaddress; getinfo; postdescriptor; closestream; closecircuit; etc. - Encode hashed controller passwords in hex instead of base64, to make it easier to write controllers. - Revise control spec and implementation to allow all log messages to be sent to controller with their severities intact (suggested by Matt Edman). Disable debug-level logs while delivering a debug-level log to the controller, to prevent loop. Update TorControl to handle new log event types. o New config options/defaults: - Begin scrubbing sensitive strings from logs by default. Turn off the config option SafeLogging if you need to do debugging. - New exit policy: accept most low-numbered ports, rather than rejecting most low-numbered ports. - Put a note in the torrc about abuse potential with the default exit policy. - Add support for CONNECTing through https proxies, with "HttpsProxy" config option. - Add HttpProxyAuthenticator and HttpsProxyAuthenticator support based on patch from Adam Langley (basic auth only). - Bump the default BandwidthRate from 1 MB to 2 MB, to accommodate the fast servers that have been joining lately. (Clients are now willing to load balance over up to 2 MB of advertised bandwidth capacity too.) - New config option MaxAdvertisedBandwidth which lets you advertise a low bandwidthrate (to not attract as many circuits) while still allowing a higher bandwidthrate in reality. - Require BandwidthRate to be at least 20kB/s for servers. - Add a NoPublish config option, so you can be a server (e.g. for testing running Tor servers in other Tor networks) without publishing your descriptor to the primary dirservers. - Add a new AddressMap config directive to rewrite incoming socks addresses. This lets you, for example, declare an implicit required exit node for certain sites. - Add a new TrackHostExits config directive to trigger addressmaps for certain incoming socks addresses -- for sites that break when your exit keeps changing (based on patch from Mike Perry). - Split NewCircuitPeriod option into NewCircuitPeriod (30 secs), which describes how often we retry making new circuits if current ones are dirty, and MaxCircuitDirtiness (10 mins), which describes how long we're willing to make use of an already-dirty circuit. - Change compiled-in SHUTDOWN_WAIT_LENGTH from a fixed 30 secs to a config option "ShutdownWaitLength" (when using kill -INT on servers). - Fix an edge case in parsing config options: if they say "--" on the commandline, it's not a config option (thanks weasel). - New config option DirAllowPrivateAddresses for authdirservers. Now by default they refuse router descriptors that have non-IP or private-IP addresses. - Change DirFetchPeriod/StatusFetchPeriod to have a special "Be smart" default value: low for servers and high for clients. - Some people were putting "Address " in their torrc, and they had a buggy resolver that resolved " " to 0.0.0.0. Oops. - If DataDir is ~/.tor, and that expands to /.tor, then default to LOCALSTATEDIR/tor instead. - Implement --verify-config command-line option to check if your torrc is valid without actually launching Tor. o Logging improvements: - When dirservers refuse a server descriptor, we now log its contactinfo, platform, and the poster's IP address. - Only warn once per nickname from add_nickname_list_to_smartlist() per failure, so an entrynode or exitnode choice that's down won't yell so much. - When we're connecting to an OR and he's got a different nickname/key than we were expecting, only complain loudly if we're an OP or a dirserver. Complaining loudly to the OR admins just confuses them. - Whine at you if you're a server and you don't set your contactinfo. - Warn when exit policy implicitly allows local addresses. - Give a better warning when some other server advertises an ORPort that is actually an apache running ssl. - If we get an incredibly skewed timestamp from a dirserver mirror that isn't a verified OR, don't warn -- it's probably him that's wrong. - When a dirserver causes you to give a warn, mention which dirserver it was. - Initialize libevent later in the startup process, so the logs are already established by the time we start logging libevent warns. - Use correct errno on win32 if libevent fails. - Check and warn about known-bad/slow libevent versions. - Stop warning about sigpipes in the logs. We're going to pretend that getting these occassionally is normal and fine. o New contrib scripts: - New experimental script tor/contrib/exitlist: a simple python script to parse directories and find Tor nodes that exit to listed addresses/ports. - New experimental script tor/contrib/ExerciseServer.py (needs more work) that uses the controller interface to build circuits and fetch pages over them. This will help us bootstrap servers that have lots of capacity but haven't noticed it yet. - New experimental script tor/contrib/PathDemo.py (needs more work) that uses the controller interface to let you choose whole paths via addresses like "<hostname>.<path,separated by dots>.<length of path>.path" - New contributed script "privoxy-tor-toggle" to toggle whether Privoxy uses Tor. Seems to be configured for Debian by default. - Have torctl.in/tor.sh.in check for location of su binary (needed on FreeBSD) o Misc bugfixes: - chdir() to your datadirectory at the *end* of the daemonize process, not the beginning. This was a problem because the first time you run tor, if your datadir isn't there, and you have runasdaemon set to 1, it will try to chdir to it before it tries to create it. Oops. - Fix several double-mark-for-close bugs, e.g. where we were finding a conn for a cell even if that conn is already marked for close. - Stop most cases of hanging up on a socks connection without sending the socks reject. - Fix a bug in the RPM package: set home directory for _tor to something more reasonable when first installing. - Stop putting nodename in the Platform string in server descriptors. It doesn't actually help, and it is confusing/upsetting some people. - When using preferred entry or exit nodes, ignore whether the circuit wants uptime or capacity. They asked for the nodes, they get the nodes. - Tie MAX_DIR_SIZE to MAX_BUF_SIZE, so now directory sizes won't get artificially capped at 500kB. - Cache local dns resolves correctly even when they're .exit addresses. - If we're hibernating and we get a SIGINT, exit immediately. - tor-resolve requests were ignoring .exit if there was a working circuit they could use instead. - Pay more attention to the ClientOnly config option. - Resolve OS X installer bugs: stop claiming to be 0.0.9.2 in certain installer screens; and don't put stuff into StartupItems unless the user asks you to. o Misc features: - Rewrite address "serifos.exit" to "externalIP.serifos.exit" rather than just rejecting it. - If our clock jumps forward by 100 seconds or more, assume something has gone wrong with our network and abandon all not-yet-used circs. - When an application is using socks5, give him the whole variety of potential socks5 responses (connect refused, host unreachable, etc), rather than just "success" or "failure". - A more sane version numbering system. See http://tor.eff.org/cvs/tor/doc/version-spec.txt for details. - Change version parsing logic: a version is "obsolete" if it is not recommended and (1) there is a newer recommended version in the same series, or (2) there are no recommended versions in the same series, but there are some recommended versions in a newer series. A version is "new" if it is newer than any recommended version in the same series. - Report HTTP reasons to client when getting a response from directory servers -- so you can actually know what went wrong. - Reject odd-looking addresses at the client (e.g. addresses that contain a colon), rather than having the server drop them because they're malformed. - Stop publishing socksport in the directory, since it's not actually meant to be public. For compatibility, publish a 0 there for now. - Since we ship our own Privoxy on OS X, tweak it so it doesn't write cookies to disk and doesn't log each web request to disk. (Thanks to Brett Carrington for pointing this out.) - Add OSX uninstall instructions. An actual uninstall script will come later. - Add "opt hibernating 1" to server descriptor to make it clearer whether the server is hibernating. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [liberationtech] How SOPA's 'circumvention' ban could put a target on Tor
by liberationtech＠lewman.us 06 Jul '18

06 Jul '18

On Thu, Dec 22, 2011 at 02:28:09PM -0500, lilbambi(a)gmail.com wrote 1.6K bytes in 43 lines about: : How SOPA's 'circumvention' ban could put a target on Tor : http://news.cnet.com/8301-31921_3-57346592-281/how-sopas-circumvention-ban-… : A little-noticed section of the Stop Online Piracy Act could make it : illegal to distribute Tor and other software that can "circumvent" : attempts by the U.S. government to block pirate Web sites. Clearly putting the word 'tor' in your article generates pageviews. There's the extreme position for the pageviews and then there's reality. If Tor was marketed as a way to explicitly defeat the SOPA provisions, if SOPA is passed as is, and if the US Attorney General's office comes after Tor for specifically marketing Tor as a way to defeat the DNS censorship of a blocked url in the US, then perhaps Declan is correct. Even Wendy's blog post mentioned in Declan's blog post is full of 'could' and 'if' statements. I take Declan's post with a huge grain of salt. In some bizarre world where the First Amendment of the US Constitution is gutted, then Tor falling under SOPA is the least of our concerns. -- Andrew http://tpo.is/contact pgp 0x74ED336B _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

24C3: Current events in Tor development
by Roger Dingledine 06 Jul '18

06 Jul '18

Hi folks, My talk at 24C3 in Berlin is now up on the web in various formats. Basically I gave an overview of some of the big technical things we did in 2007, some of the policy/legal issues that we're tackling, and some of the technical things that need to come next. The focus was on Germany, so it included some discussion of the upcoming data retention problems, and of the general issue with police in Germany seizing servers. You can download the high-quality version here: http://berlin.ccc.de/~24c3_torrents/24c3-2325-en-current_events_in_tor_deve… or watch the low-quality version here: http://video.google.com/videoplay?docid=4445148387567182005 and the slides are here: http://freehaven.net/~arma/slides-24c3.pdf Enjoy, --Roger ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Tor: A JAP Replacement
by brian-slashdotnews＠hyperreal.org 06 Jul '18

06 Jul '18

Link: http://slashdot.org/article.pl?sid=04/08/05/2352235 Posted by: CowboyNeal, on 2004-08-06 01:14:00 from the trust-no-one dept. [1]kid_wonder writes "Wired is running an article [2]describing an answer to this [3]previous /. story. Packets are sent through a network of randomly selected servers each of which knows only its predecessor and successor. Packets are unwrapped by a symmetric encryption key at each server that peels off one layer and reveals instructions for the next downstream node. As a 'connection-based low-latency anonymous communication system,' [4]Tor seems to be the answer to [5]JAP to allow anonymous networking activities of all kinds." References 1. http://.moc.nielk-ttocs..ta..nielks/ 2. http://www.wired.com/news/print/0,1294,64464,00.html 3. file://ask.slashdot.org/article.pl?sid=03/09/18/0051216&tid=158 4. http://www.freehaven.net/tor/ 5. http://anon.inf.tu-dresden.de/index_en.html/ ----- End forwarded message ----- Onion Routing Averts Prying Eyes By Ann Harrison Story location: http://www.wired.com/news/privacy/0,1848,64464,00.html 02:00 AM Aug. 05, 2004 PT Computer programmers are modifying a communications system, originally developed by the U.S. Naval Research Lab, to help Internet users surf the Web anonymously and shield their online activities from corporate or government eyes. The system is based on a concept called onion routing. It works like this: Messages, or packets of information, are sent through a distributed network of randomly selected servers, or nodes, each of which knows only its predecessor and successor. Messages flowing through this network are unwrapped by a symmetric encryption key at each server that peels off one layer and reveals instructions for the next downstream node. In contrast, messages traveling across the Internet are generally not encrypted, and the path of a message can be seen easily, linking users to activities like website visits. The Navy is financing the development of a second-generation onion-routing system called Tor, which addresses many of the flaws in the original design and makes it easier to use. The Tor client behaves like a SOCKS proxy (a common protocol for developing secure communication services), allowing applications like Mozilla, SSH and FTP clients to talk directly to Tor and route data streams through a network of onion routers, without long delays. Onion routing does not guarantee perfect anonymity. But it helps protect users from eavesdroppers who aren't watching both the initiator and recipient of the message at the time of the transaction. Developers say Tor can be used to prevent websites from tracking their users; block governments from collecting lists of website visitors; protect whistleblowers; and circumvent local censorship by employers, ISPs or schools that restrict access to certain online services. The Navy is financing Tor because it wants to hide the identity of government employees who have long used anonymous communications systems for intelligence gathering and politically sensitive negotiations. "The point of the Tor system is to spread the traffic over multiple points of control so that no one person or company has the ability to link people," said programmer Roger Dingledine. Dingledine and Nick Mathewson, both based in Boston, are building Tor as a research platform with a worldwide community of open-source software developers. Their goal is to blend together a wide range of users and avoid the weakness of many anonymizing services that are located on a handful of machines and vulnerable to a single point of failure. Companies could also use Tor for discreet competitive research, said Dingledine, or to route their employees' Web browsing so employment sites like Monster can't determine which of them are trolling for a job. "Plenty of people don't want their source IP listed in Web logs, especially .mil or .gov visitors," said Dingledine. The security of the Tor service is proportional to the number of nodes in the system. Tor is slowly scaling and looking for tens of thousands of participants who can provide enough nodes to prevent the service from being compromised by what the project website describes as "curious telcos and brute-force attacks." "The current Tor version very effectively builds on 20 years of development in anonymous designs," said cryptographer David Chaum, whose 1981 paper on untraceable e-mail, return addresses and digital pseudonyms set the groundwork for the Tor service. Tor is distributed as free software under the commonly used 3-clause BSD license. About 1,000 users (it's an anonymous network, so developers aren't exactly sure) are running the service in client or server mode. The Tor network currently includes 35 servers that forward each data stream at least three times. Each server averages 10 Kbps of bandwidth. Those with reliable Internet connections, who can support at least 1 Mbps in both directions, are being recruited as potential servers in the network. Users are permitted to operate an unrestricted number of nodes. But Dingledine pointed out that a well-funded adversary could sign up for a large number of servers and potentially take over the network. Those who want to operate Tor routers must therefore convince the Tor directory server operators that they are trustworthy and reliable. Dingledine said developers are trying to find ways to scale the system without having to have a human check the integrity of every new server that becomes part of the network. Dingeldine said the developers of another online anonymity project, called JAP, were forced by the German government to insert a backdoor into the program and were barred from revealing it. If anyone insisted on similar measures for Tor, Dingledine said the community of open-source developers who analyze source-code changes for each Tor revision would expose it -- as they did with JAP. "The reason Tor works is that it's free and available software," said Dingledine. "If it was a closed source or a proprietary system, there is no way to know." -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[ShmooCon-News] Saturday night's con
by shmoocon-news＠lists.shmoo.com 06 Jul '18

06 Jul '18

Saturday night's fun has basically been finalized, so it's time to clue attendees in. ShmooCon 2005 attendees are invited to boogie at FUR, a rather hip dance club in D.C., Saturday night, February 5th, from 10 to whenever. Check out FUR's website here: http://www.furnightclub.com FUR is letting all ShmooCon 2005 attendees, 21 and over, in for FREE. The private speaker party with open bar in the Mafia lounge at FUR runs from 10 to midnight, and features spinning by everyone's favorite West-coast, DefCon & ToorCon-infamous DJ, Keith! w00t! Anyone who reserved a room at the conference hotel under the ShmooCon group rate will get a pass to the speaker party once they check-in at the hotel. If you didn't reserve a room at the conference hotel, or you aren't a speaker, then you'd better practice on your social engineering skills to score a pass to the speaker party. Rumor has it, speakers will have extra passes to distribute as they see fit. ;) And one more note: FUR, not the Shmoo Group, controls the dress code--read the FUR FAQ here: http://www.furnightclub.com/Content/FAQ.html So no whining about having to look (and smell) nice. Got it? See you at FUR on Saturday night of the con! Sincerely, Beetle The Shmoo Group _______________________________________________ Shmoocon-News mailing list Shmoocon-News(a)lists.shmoo.com https://lists.shmoo.com/mailman/listinfo/shmoocon-news --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Pentagon Targets Blogs
by Ralph Sierra 06 Jul '18

06 Jul '18

In what may be the understatement of the year, the Pentagon includes the warning that their actions may "sound ominous." Not only are we paying to have favorable stories planted in foreign newspapers, but now we're employing professionals to post information to blogs. Question: Do you suppose when they blog they identify themselves as paid Pentagon informants? "Pentagon Targets Blogs "A new U.S. Central Command team, according to a news release, "contacts bloggers to inform the writers about any given topic that may have been posted on their site. . . . The team engages bloggers who are posting inaccurate or untrue information, as well as bloggers who are posting incomplete information." "While that may sound ominous, the release says the unit works with more than 250 bloggers "to try to disseminate news about the good work being done by U.S. forces in the global war on terror." This, says Army Reserve Maj. Richard Norton, has a "viral effect" that drives Web users to CentCom's Web site. The team's motto: "Engage." http://www.washingtonpost.com/wp-dyn/content/article/2006/03/05/AR200603050… 90.html Ralph Sierra ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] Pentagon Targets Blogs
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

24C3: Current events in Tor development
by Roger Dingledine 06 Jul '18

06 Jul '18

Hi folks, My talk at 24C3 in Berlin is now up on the web in various formats. Basically I gave an overview of some of the big technical things we did in 2007, some of the policy/legal issues that we're tackling, and some of the technical things that need to come next. The focus was on Germany, so it included some discussion of the upcoming data retention problems, and of the general issue with police in Germany seizing servers. You can download the high-quality version here: http://berlin.ccc.de/~24c3_torrents/24c3-2325-en-current_events_in_tor_deve… or watch the low-quality version here: http://video.google.com/videoplay?docid=4445148387567182005 and the slides are here: http://freehaven.net/~arma/slides-24c3.pdf Enjoy, --Roger ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0