July 2018 - cypherpunks-legacy

[WIKILEAKS] NYTimes Ed / Icelandic bank threats
by Wikileaks Press Office 06 Jul '18

06 Jul '18

WIKILEAKS NEWS Sat Aug 1 00:46:32 GMT 2009 1. Offshore banks v. WikiLeaks--round 2 Back in February 2008, WikiLeaks together with our boldest supporters, defeated an attack by Swiss Bank Julius Baer over "banking secrets". Now WikiLeaks has received a legal demand from the infamous Icelandic bank Kaupthing. The legal letter requests the removal of a confidential 210 page risk analysis of hundreds of companies and groups which owed the bank billions shortly before its collapse. Kaupthing's lawyers claim to have briefed US counsel. http://bit.ly/cJpDh 2. New York Times editorial on the money, but 7 years out of date On Wednesday, the New York Times devoted an editorial to domestic intelligence "fusion centers" and possible violations of the Posse Comitatus Act. Posse Comitatus prevents the US military from being used as police. The potential violations cited by the Times date back to 2002--seven years ago. While it is good to see the issue getting some attention, on May 5, 2009, we released the March 2009 "US Army Concept of Operations for Police Intelligence Operations", a 60 page, official US military manual. The confidential manual contains phrases such as "It [fusion] does not have constraints that are emplaced on MI [Military Intelligence] activities within the US, because it operates under the auspice and oversight of the police discipline and standards." and "The coordinated effort gave law enforcement agencies the knowledge to identify and prevent disruptive actions by violent protesters. The operation was considered by Corps leadership to be a watershed event for in-depth involvement of a garrison-based FP [Force Protection] fusion cell in support of unit deployments. Moreover, the Corps headquarters integrated the fusion cell into other operations where the G2 [military intelligence] is constrained by intelligence oversight rules". This is the official policy behind the recently Force Protection infitration of the activist group SDS in Washington State. On July 25 we released "Washington Joint Analytical Center Seattle private intelligence outsourcing, 1525 pages, 2006-2008". And on July 29, an analysis, "The spy who billed me twice", which starts: "There has been extensive political debate in the United States on how safe it would be to move Guantanmo's detainees to US soilbut what about their interrogators? A confidential 1525 page file of correspondence released to the public by WikiLeaks provides insights into the privatization of intelligence operations in the United States and the movement of such individuals into domestic intelligence 'fusion' centers...." See http://wikileaks.org/wiki/The_spy_who_billed_me_twice and associated links under "Source Documents". The New York Times does good work, but its editorial on this subject is bizarrely antique. +-------------------------------------------------- | Why you receive this mail and what to do with it: | | You are receiving this mail because you were invited to | the Wikileaks Press Release list run by the transparency group Sunshine Press. | | Releases ensure you are aware, before the rest of the world, | of significant geopolitical and other disclosures released | by Wikileaks, an international platform for the first release of | of classified, confidential or censored materials of political, | diplomatic, ethical or historical interest. | | We rely on you to distribute the content of this mail to your | community, industry, press and regulators, to defend us in your | country and to invite people of integrity and commitment via | via https://lists.riseup.net/www/subscribe/wl-press | | Our materials range from secret Guantanamo documents to political | assassinations to confidential reports of children's hospital | corruption, and have spawned tens of thousands of press articles, | many reforms and changed electoral outcomes. | | Releases average one per week but can be higher or lower depending on | events. You can easily set the frequency to monthly or change your | subscription via https://lists.riseup.net/www/sendpasswd/ | | If you know people that have access to sensitive documents of public | interest, tell them about us. We have an unbroken record of protecting | sensitive sources and defeating censorship attacks from all corners of the globe. | See https://secure.wikileaks.org/wiki/Wikileaks:Submissions | | If you are about to release an investigative report or article, we can release the | underlaying source material concurrently to substantiate the allegations, | draw attention away from the true source, deflect legal or censorship | attacks and promote secondary investigations and public awareness. | | Live bank-grade encrypted chat to the office is available via | https://secure.wikileaks.org/chat/irc2.cgi (multiple languages spoken) | | Inquiries for speaking engagements, comment, interventions, | investigations, source-protection and censorship consultations | may be addressed to http://wikileaks.org/wiki/Wikileaks:Contact | | If you are serious about analysis, translation, | legal, coding, network, financial or other contributions, please contact | us via: http://wikileaks.org/wiki/Wikileaks:Contact | | See http://wikileaks.org for all other information and | https://secure.wikileaks.org for secure access. ----- 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

Re: [cryptography] Digital cash in the news...
by James A. Donald 06 Jul '18

06 Jul '18

On 2011-06-11 1:58 PM, Peter Gutmann wrote: > I wouldn't call bitcoins digital cash. They're more like digital tulip bulbs, Monetary value is always speculative. It depends on the expectation that they will be used as money. There is a small but not totally insignificant chance that after fiat monies collapse, the world will go bitcoin standard. There is a large chance that the world will go gold standard. There are about ten billion ounces of gold in the world, therefore fifteen trillion dollars worth of gold. This value only makes sense if there is large chance that gold will be money. There are about three hundred million dollars worth of bitcoins. Therefore the market is valuing the chance that the world will go to a bitcoin standard at The current value of gold looks about right to me. So the current value of bitcoin is also about right - that all the gold in the world is worth about five hundred thousand times all the bitcoins in the world. Which is probably a fairly conservative estimate for the prospects that the world will go bitcoin. If the current price of gold makes sense, the current price of bitcoin makes sense. I would recommend putting most of one's cashi in gold, and a tiny bit of one's cash in bitcoin. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[osint] Martha's lesson - don't talk to the FBI
by Tefft, Bruce 06 Jul '18

06 Jul '18

Thought everyone knew that. Bruce ----- http://www.nwanews.com/times/story_Editorial.php?storyid=115586 Guest Commentary : Martha's lesson - don't talk to the FBI BY DONALD KAUL Posted on Saturday, March 20, 2004 Here is the lesson to be learned from the fall of Martha Stewart: Don't ever, under any circumstances, answer questions put to you by the FBI or any other federal agent unless you have a competent criminal lawyer at your side. And it would be better if it were a very good criminal lawyer. There are other lessons to be drawn from the fate of poor Martha, but that's the main one. You see, there is a section in the federal code, referred to as 1001 by legal eagles, that makes it a crime to lie to a federal agent. The agent doesn't have to put you under oath. If you tell him or her a lie, you're guilty. The federal officer doesn't even have to tape the conversation. All he or she has to do is produce handwritten notes that indicate that you made false statements. So, if you misspeak or the agent mishears or there is an ambiguity that the agent chooses to interpret in an unfortunate (for you) direction, you're on the hook. There's also the possibility that you might be tempted to shade the truth a bit when an IRS agent is quizzing you about that business deduction you took for the trip to Vegas. My advice to you is: Don't do it. To be on the safe side, when confronted by a federal agent, don't say anything at all unless your lawyer says you have to. It's a shame things have come to this. It used to be that people felt it their duty as citizens to cooperate with federal authorities. That was before Law 1001. We now live in an era of Incredible Shrinking Civil Rights. You have to protect yourself at all times. Let's look more closely at the case of Poor Martha the Match Girl. What did she do? She was convicted of lying about the reason she sold her shares in a biotechnology company two years ago. She said she sold them because they had fallen to the price at which she and her broker had agreed to sell. The government argued (and the jury believed) that she sold because her broker passed on some inside information that the stock was going to plunge in the next couple of days. I know what you're going to say - "insider trading." True, it has that smell about it, but the government did not charge her with insider trading, only with lying about it. I hate that. It seems to me that convicting someone of lying about a crime that the government isn't willing to prove happened is unfair. Add to that the fact that Ms. Stewart saved all of $45,000 on the stock transaction and has seen her fortune decrease by hundreds of millions because of the trial, and the penalty does not seem to fit the crime. I think the reason the government has spent millions pursuing this two-bit case is because Ms. Stewart is famous and the case makes it look as though the Justice Department is doing a bang-up job running down crooks in high places. Also, the lifestyle lady - a political contributor to Democrats rather than Republicans, incidentally - irritated prosecutors with her haughty, arrogant attitude. (It's always a bad idea to make prosecutors mad.) Then too, her high-priced attorney, Robert Morvillo, lost a series of strategic gambles that left his client virtually defenseless. After the government had spent six weeks making the case against Stewart, Morvillo called only one witness in her defense and questioned him for 20 minutes. His chief argument was that Stewart and her broker were too smart to pull a dumb stunt like this. As one juror said later, "How could we tell anything about how smart either of them was if they never took the stand?" Ultimately, I suppose, Ms. Stewart's downfall was precipitated by petty greed, arrogance and deceitfulness, not attractive attributes. But I still feel sorry for her. She's getting worse than she deserves. Donald Kaul recently retired as Washington columnist for the Des Moines Register. -------------------------- Want to discuss this topic? Head on over to our discussion list, discuss-osint(a)yahoogroups.com. -------------------------- Brooks Isoldi, editor bisoldi(a)intellnet.org http://www.intellnet.org Post message: osint(a)yahoogroups.com Subscribe: osint-subscribe(a)yahoogroups.com Unsubscribe: osint-unsubscribe(a)yahoogroups.com *** FAIR USE NOTICE. This message contains copyrighted material whose use has not been specifically authorized by the copyright owner. OSINT, as a part of The Intelligence Network, is making it available without profit to OSINT YahooGroups members who have expressed a prior interest in receiving the included information in their efforts to advance the understanding of intelligence and law enforcement organizations, their activities, methods, techniques, human rights, civil liberties, social justice and other intelligence related issues, for non-profit research and educational purposes only. We believe that this constitutes a 'fair use' of the copyrighted material as provided for in section 107 of the U.S. Copyright Law. If you wish to use this copyrighted material for purposes of your own that go beyond 'fair use,' you must obtain permission from the copyright owner. For more information go to: http://www.law.cornell.edu/uscode/17/107.shtml Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/osint/ <*> To unsubscribe from this group, send an email to: osint-unsubscribe(a)yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ --- 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

Re: [cryptography] Digital cash in the news...
by James A. Donald 06 Jul '18

06 Jul '18

On 2011-06-11 1:58 PM, Peter Gutmann wrote: > I wouldn't call bitcoins digital cash. They're more like digital tulip bulbs, Monetary value is always speculative. It depends on the expectation that they will be used as money. There is a small but not totally insignificant chance that after fiat monies collapse, the world will go bitcoin standard. There is a large chance that the world will go gold standard. There are about ten billion ounces of gold in the world, therefore fifteen trillion dollars worth of gold. This value only makes sense if there is large chance that gold will be money. There are about three hundred million dollars worth of bitcoins. Therefore the market is valuing the chance that the world will go to a bitcoin standard at The current value of gold looks about right to me. So the current value of bitcoin is also about right - that all the gold in the world is worth about five hundred thousand times all the bitcoins in the world. Which is probably a fairly conservative estimate for the prospects that the world will go bitcoin. If the current price of gold makes sense, the current price of bitcoin makes sense. I would recommend putting most of one's cashi in gold, and a tiny bit of one's cash in bitcoin. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[Politech] Correction on security firms and detecting spyware [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

Whoops! I mistyped when sending out the last message. To be clear, we asked the 13 companies this question: "Is it your policy to alert the user to the presence of any spyware or keystroke logger, even if it is installed by a police or intelligence agency in the absence of a lawful court order signed by a judge?" And we received 13 responses saying YES, it was their policy. Putting this thing together was a beast (about 5,000 words including the verbatim responses) and you can tell that I'm a bit frazzled as a result. Previous Politech message: http://www.politechbot.com/2007/07/17/will-security-firms/ And, by way of comparison, here's something from the archives saying Symantec in 2001 would overlook FBI spyware: http://www.politechbot.com/p-02851.html And McAfee apparently saying the same: http://www.politechbot.com/p-02834.html But then McAfee challenged the AP article: http://www.politechbot.com/p-02846.html http://www.politechbot.com/p-02840.html At least now we have them on the record in a less ambiguous way. (The court order clause could be a loophole, but National Security Letters aren't signed by a judge so I don't think it's a big one.) -Declan _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

[liberationtech] Cryptography Alt-Folk Band Release a New MixTape!
by Nathan of Guardian 06 Jul '18

06 Jul '18

(See, I am learning a thing our two about how to get publicity, aren't I?) Just a quick note to say that Gibberbot, the Guardian Project's free (bot ways), open-source, standards compliant, secure instant messaging app for Android, has been updated. It is rare that you have the opportunity to implement a feature that makes an app more secure AND more usable at the same time, but we did just that, by supporting Google OAuth2 for @gmail and @google domain accounts. We also now support TOFU-POP for SSL verification, which is fun to say, but even more fun to use. You can read about this and find all the relevant links here: https://guardianproject.info/2013/03/08/gibberbot-v11-secure-usable/ HOWEVER, what I would rather you do, is try out a new interactive "how to" for Gibberbot, that walks through both options for installation, and how to set up a secure and verified mobile chat. View it here - I promise you'll love it: https://guardianproject.info/howto/chatsecurely/ This how-to is the first of a series we will be releasing for all of the apps and services we offer. Many thanks to Mark Belinksy for taking this new effort on for us, and for his very serious focus on making mobile security a bit more fun. If you would like to chat with me my "nathan(a)guardianproject.info" email is a valid XMPP jid, so feel free to add me as a buddy, contact, collaborator or confident, in your XMPP/OTR client of choice. +Nathan -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/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

HMAC?
by Perry E. Metzger 06 Jul '18

06 Jul '18

So the question now arises, is HMAC using any of the broken hash functions vulnerable? I can't answer that myself yet since I haven't given it a good enough think, but I'll will point people at the original HMAC paper at: http://www.research.ibm.com/security/keyed-md5.html The paper itself is at: http://www.research.ibm.com/security/bck2.ps Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- 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

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

HMAC?
by Perry E. Metzger 06 Jul '18

06 Jul '18

So the question now arises, is HMAC using any of the broken hash functions vulnerable? I can't answer that myself yet since I haven't given it a good enough think, but I'll will point people at the original HMAC paper at: http://www.research.ibm.com/security/keyed-md5.html The paper itself is at: http://www.research.ibm.com/security/bck2.ps Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- 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