July 2018 - cypherpunks-legacy

[Dgcchat] AxiomaticTokenizer 2.5
by George Hara 06 Jul '18

06 Jul '18

AxiomaticTokenizer 2.5 has been released. Main features ------------- Multi-service support. Multi-currency support. Actions for online payment services: Create account, Modify account passphrase, Add inheritor, Remove inheritor, Login account, Make payment. Asymmetric encryption (RSA) for sending the user's "passphrase" to the service. Customizable token hash size. This is meant to reduce the amount of characters which users need to type. Optional spy protection for tokens. The disadvantage of this protection is that it increases significantly the size of tokens. Private account names. By simply adding "#" at the end of an account name, the account name sent to the service is actually a mix of the written account name and of the service's name, in a way which effectively hides the written account name from the service. Color themes. Multi-language support. Table with mappings between two dice and characters. This is meant to help users to generate truly random passphrases. Multi-platform: Firefox, InternetExplorer, InternetExplorer Mobile, Opera, Safari. Easy to check HTML and JavaScript open source code. Token example: "AT1; AT; MP; 20071206; 174853; AkulaAlice; BobBonkers; AUG; 100; C28-BA3-86C-E87-434-B;" http://www.gardenerofthoughts.org/ideas/emoney/ tokens.htm#AxiomaticTokenizer _______________________________________________ Dgcchat mailing list Dgcchat(a)dgcchat.com http://mail.dgcchat.com/mailman/listinfo/dgcchat_dgcchat.com

1 0

[IP] more on Simson Garfinkel analyses Skype - Open Society Institute -- interesting set of comments djf
by David Farber 06 Jul '18

06 Jul '18

------ Forwarded Message From: David Pollak <dpp(a)athena.com> Date: Sun, 30 Jan 2005 07:44:21 -0800 To: <dave(a)farber.net> Cc: <slg(a)ex.com> Subject: Re: FW: [IP] more on Simson Garfinkel analyses Skype - Open Society Institute Dave, I've been following the Simson/Skype thread on IP and I've read the Columbia analysis of the Skype protocol (http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cuc s-039-04.pdf) I've known Simson for 14 or so years and have a ton of respect for his technical skills. However, I think there are some significant Skype vulnerabilities and associated legal ramifications that Simson did not discuss in his article. Security is based on trust of the parties exchanging information that they are who they claim and that the data exchanged appears to be random to an untrusted observer. While Skype's use of encryption supports the second part of the definition, it does not support the first. Because it does not support the first, it is very easy to use the Skype network to intercept communications between any user or to pose as any user. This presents a problem as against both third parties and governmental agencies. A critical part of the Skype network is the "super-nodes." According to the Columbia paper, super-nodes perform 3 functions: * Designating the login authority * Media packet forwarding * Routing user search requests Super-nodes appear to "volunteer" to perform the function. Or put another way, they are nodes that are not under the control of Skype, but they perform all the routing functions necessary to discover a user and exchange information with the user. Super nodes run on any machine running the Skype program and the machines under Skype control have no way to determine if the super nodes are running unmodified Skype code. If one were skilled in reverse engineering x86 code and one were willing to violate Skype's user agreement, one could create a Skype node that volunteered to be a super-node. It would appear to all other Skype nodes as a normal super-node. It would perform all the functions of a Skype super-node. However, it would do a little bit more. Let's call one of these super-nodes a "bad seed." The bad seed could point users to another authentication server. Thus, the user would exchange username and authentication information with a "bad relay proxy" rather than the Skype server. That permits the "bad relay proxy" to deny Skype access to a user that I designate. Okay a denial of service attack is not great stuff, but for businesses that rely of Skype (http://news.com.com/No-cost+Skype+strikes+chord+with+businesses/2100-7352_3 -5553053.html ), having the prospect of a DoS attack could be an issue. Further, the "bad relay proxy" could collect username/password challenge (I'm assuming that Skype's not sending the actual password, but performing a challenge/response method of verifying the password) data and do dictionary attacks on the passwords. This isn't a hardcore vulnerability you say. Yep... I agree. The bad seed routes some of the media requests if the two peers cannot see each other directly. Skype claims that because the packets are encrypted, the super-nodes are just routing agents. This is true unless the bad seed is part of the key exchange (see the next paragraph.) If the bad seed is part of the exchange of private AES keys that are used to encrypt the voice data, then they are able to decrypt the audio or text streams. Yikes. If a bad seed was a man in the middle of the private key exchange, then the bad seed could record your conversation with another user. Okay, that's not good. Given that any Skype node can become a super-node just by raising its hand and a skilled hacker can re-engineer a Skype node to perform bad acts, then if you connect to the Skype network, you don't know which nodes are listening in on your conversation. But wait, you say, the requirement for the above bit of scariness is doing a man-in-the-middle attack on the encryption key exchange. You're right. And here's where the Skype network is totally insecure. One function of the super-node in the Skype network is to route and respond to user search requests. If I want to connect to "other_dude" on the Skype network, my client sends out search requests to a series of super-nodes. The super-nodes either respond with the address of "other_dude" or forward the requests to other super-nodes. If one of the super-nodes is "bad seed", that node can respond that it is "other_dude." Because there is no cryptographic trust or any form of trust authority in the Skype network, any super node that returns the information about "other_dude" is trusted by my node. An aside... SSL certificates are signed by a trusted third party. That third party validates that the certificate is held by the organization that claims to hold the certificate. Using SSL insures that the party that I'm communicating with is the party that they claim to be within the bounds that I trust the signer of the SSL certificate *and* that once the connection is established that no one can understand the data exchanged with this party. That initial trust of the signed certification is a critical part of the security of the overall communication. If I do a session key exchange with an unknown party, the communication is *not* secure. This is the case with Skype. The Skype network relies on trusting the super-node. A bad seed can perform a man in the middle attack during the session key exchange by posing as the party being contacted (or forwarding the information of another compromised node) to a caller. So, my bad seed is able to route call requests to an untrusted node and do a man-in-the-middle during the key exchange and snoop into my call. The only question is how many bad seeds to you need in order to capture a significant percentage of the routing requests that go over the Skype network. My guess is that the number is in the hundreds. So, with a hundred machines located around the world, I could intercept any Skype call and record it. Pretty scary. The PSTN primarily uses pairs of copper wires to transmit voice communications from my house to the phone company central office. I can gain physical access to those copper pairs very easily as long as I have physical proximity to the location of the person I want to snoop on. It's not hard to do. Yeah, you have to paint a white van with "Verizon" or "SBC" so the police don't hassle you. But you can do it. If the government wants to do it, it's somewhat harder. The government has to get a warrant to listen to your phone conversations. Once they obtain a warrant, they present it to the phone company which makes an entry into their switch to record the call or send a real-time copy of it to the government. SIP is different. SIP supports encryption, but most SIP providers do not make use of it. The Microsoft SIP client libraries have the option of communicating with the SIP server via TLS (TLS is like SSL, but uses the same IP port for both encrypted and unencrypted traffic.) Additionally, the media portion of a SIP call can be encrypted by setting a flag in the media descriptor. While most SIP providers do not use this functionality, it's part of the SIP spec and can be turned on. Note that the machines that could play man-in-the-middle with an encrypted SIP call are controlled by your SIP provider (rather than any machine running Skype.) Thus, you can trust the security of your call as much as you trust your SIP provider. With unencrypted SIP calls, if you are able to intercept packets, then you can tap the call. Anybody on your LAN can listen into your call. This level of security is no different than anyone in your house can listen in on your phone calls and anyone in your office can probably do the same. Anyone who can intercept the packet stream outside your LAN can also listen in on the conversation. This is more of a challenge. UDP packets (the stuff that the media stream goes over) may or may not be routed through the same backbone during all parts of the conversation. There is a certain amount of security with the packets going over the backbone. The ability to snoop on an unencrypted SIP call is marginally more difficult that snooping on a PSTN call. For the government, it's more of a challenge. Because the media portion of a SIP call goes directly between the end points without going through the SIP providers network. This raises an interesting issues: http://news.com.com/2100-7352-5296417.html This is interesting for two reasons. First, SIP "telephone" companies like Vonage will have to provide a flag to allow them to intercept the media stream and decode it if the government has a warrant. Second, the government has acknowledged that SIP callers have the same expectation of privacy that copper-pair PSTN callers have. This is really important. Users of peer-to-peer file sharing programs don't have an expectation of privacy in their use of P2P programs. That's why so many folks are being sued (http://news.com.com/RIAA+files+754+new+file-swapping+suits/2110-1027_3-5494 259.html?tag=nl ) Skype touts themselves as a P2P voice communications system (http://skype.com/products/explained.html ) That means that if you use Skype, you have the same expectation of privacy as a P2P user. Given that the government has the resources to build bad seeds and that P2P users have no expectation of privacy, you can bet that there are government run Skype nodes looking for Skype communications between Osama911 and Sleeper_in_Seattle and that the government doesn't have a warrant for these activities. To conclude my long rant, the Skype network is radically insecure because it relies on untrusted super-nodes to perform trusted functions, most notably user look-up. It's easy to build a compromised super-node (a bad seed.) With a limited number of bad seeds, the communications between any users can be intercepted or denied. It's something that a person with the resources to rent 100 servers in collocation facilities around the world could do (that's about $10,000 per month investment.) Given that Skype is a P2P network and users such networks are not afforded the same expectation of privacy that users of the PSTN and other telephone networks are afforded, the government could use such a mechanism to listen to Skype-based calls and have a reasonable legal argument that they do not need a warrant to do so. That's my 2 cents. Thanks, David PS -- I was CTO and VP Engineering for an Internet security company for a number of years and I'm a member of the Rhode Island bar. Annette Hurst wrote: > > > -----Original Message----- > From: owner-ip(a)v2.listbox.com [mailto:owner-ip@v2.listbox.com] On Behalf Of > David Farber > Sent: Saturday, January 29, 2005 2:11 AM > To: Ip > Subject: [IP] more on Simson Garfinkel analyses Skype - Open Society Institute > > > > ------ Forwarded Message > From: "Jonathan S. Shapiro" <shap(a)eros-os.org> <mailto:shap@eros-os.org> > Date: Fri, 28 Jan 2005 22:03:48 -0500 > To: <dave(a)farber.net> <mailto:dave@farber.net> > Subject: Re: [IP] I more on Simson Garfinkel analyses Skype - Open Society > Institute > > I'm going to attempt to chime in on this, because I think Brad is saying > something that I feel is badly wrong. > > > The most important element of an encryption scheme is that there must be some > well-founded basis for a well-defined degree of confidence. The encryption may > be well done or poorly done. It may be sufficiently protective or it may not. > The thing is that the user has a right and a need to know where on the > spectrum it falls. > > The other alternative is ignorance. The first problem with this is that > *your* bad choices can have the effect of disclosing things that have negative > consequences for someone else! The second problem is that it describes the > majority of real users. > > In the case of Skype, the argument Brad is making is simply absurd. The > question is not whether something is better than nothing. The question is why > Skype chose to implement an undocumented and unqualified proprietary > encryption scheme at considerable expense rather than use one of the many > existing schemes that are well known, well characterized, and free for the > taking. > > When viewed from a business perspective, the only plausible rationale is > immediately apparent. Skype's objective isn't to protect conversations. It is > to render Skype users a captive audience by impeding interoperability. > > It is hardly a new precedent. I seem to remember AT&T trying to use allegedly > proprietary interfaces to impede the attachment of Tom Carter's Hush-a-Phone > in 1956 or so. Different method, same basic strategy. > > > Jonathan Shapiro > > On Fri, 2005-01-28 at 20:53 -0500, David Farber wrote: > > >> >> ------ Forwarded Message >> From: Brad Templeton <btm(a)templetons.com> <mailto:btm@templetons.com> >> Organization: http://www.templetons.com/brad >> Date: Fri, 28 Jan 2005 17:22:29 -0800 >> To: David Farber <dave(a)farber.net> <mailto:dave@farber.net> >> Cc: <daw(a)cs.berkeley.edu> <mailto:daw@cs.berkeley.edu> , <adam(a)shostack.com> >> <mailto:adam@shostack.com> , >> <simsong(a)csail.mit.edu> <mailto:simsong@csail.mit.edu> >> Subject: Re: [IP] Simson Garfinkel analyses Skype - Open Society Institute >> >> >> >>> >>> I'm sorry to pick nits, but I have to stand by my statement. No >>> matter how atrociously bad other systems may be, I don't see any >>> basis for saying that Skype is any better. It might be better, or >>> it might be just as bad. We don't know. >>> >>> >> >> While I fully agree that one can have much more confidence in a >> security system which can be independently analysed and verified as >> secure, it is exactly the attitude above, common in the security >> community, which I believe has stopped us from deploying security. >> >> "Some" security, even things like DES (which our own foundation proved >> can be crackable), poorly chosen keys, algorithms with flaws, >> protocols that are vulnerable to men in the middle, and proprietary >> encryption systems -- all of these are often declared to be "no >> better" than having no encryption at all. >> >> And so, people, buying that argument, often give us no encryption at >> all, because encryption is hard to do well, and if people keep telling >> you that you have to do it perfectly or you might as well not bother >> -- then people don't bother. >> >> The trut is, most people's threat models are not the same as a security >> consultants. They accept that if the NSA wants to man-in-the-middle >> them, the NSA is going to succeed. >> >> Skype has resisted basic efforts by skilled reverse engineers to look >> at its protocols. That doesn't mean they are secure, but it does mean >> they are secure from basic efforts. If I wanted to listen in your >> your skype call and had a tap on your ethernet, I would at least have >> to put a lot of work into it, and possibly could not do it >> at all. That is a _lot_ more than what is true with in-the-clear SIP, >> where I could slap a packet sniffer on your net and hear your call >> fairly trivially, and with certainty that I would succeed. >> >> This is, in fact, a huge difference. Encryption is really about how >> hard you make it for the attacker. Because above a certain level of >> hardness there are a lot of easier ways into your network and >> computer. >> >> So yes, let's decry that we can't verify Skype's encryption and must >> take their word that it is resistent to attack. But let's not promote >> this attitude that it is no better than nothing. >> >> ------ End of Forwarded Message >> >> >> ------------------------------------- >> You are subscribed as shap(a)cs.jhu.edu >> To manage your subscription, go to >> http://v2.listbox.com/member/?listname=ip >> >> Archives at: >> http://www.interesting-people.org/archives/interesting-people/ >> >> > > > > ------ End of Forwarded Message > > > ------------------------------------- > You are subscribed as annette(a)lostlake.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 of Forwarded Message ------------------------------------- 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> ______________________________________________________________ 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

RE: [Geowanking] E911 // cellular trilateration accuracy
by roger＠sylvanascent.com 06 Jul '18

06 Jul '18

I think this is a great question. I talked to a gentleman from South Africa last year at Where 2 who claimed to be a GSM expert. He said that GSM can locate you within something like 3 meters with no GPS support just using the towers, and that this was built into the GSM spec. He spoke of a case in South Africa where they located some sort of criminal using the GSM records. He said that CDMA on the other hand, cannot locate so precisely. So, to me, A-GPS was designed to make CDMA users locatable to the same degree as GSM. As an aside, does anyone know which type of cell phones are more lethal? Roger Original Message: ----------------- From: Ian | Urban Mapping ian(a)urbanmapping.com Date: Mon, 10 Apr 2006 01:42:23 -0400 To: geowanking(a)lists.burri.to Subject: [Geowanking] E911 // cellular trilateration accuracy At the risk of asking (another) obvious question, I continue my naove streak on this listserv Ive heard very different reports of how accurate cellphone tracking isthe FAA mandates something like 50% of calls must be traceable to within a range of 30m but Ive heard some mobile pros say theyve heard of it getting as good as several feet. Obviously this varies depending on geography (urban, rural, topography), but does anybody have any idea how the US wireless carriers stack up? And how does this compare to phones with GPS? Ian White :: Urban Mapping LLC :: <mailto:ian@urbanmapping.com> ian(a)urbanmapping.com 120 West 45th Street 20th Floor :: New York NY 10036 Tel.212.242.8267 :: Fax.866.385.8266 :: www.urbanmapping.com -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ Geowanking mailing list Geowanking(a)lists.burri.to http://lists.burri.to/mailman/listinfo/geowanking ----- 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

Re: [tor-talk] Tor virus
by Philipp Winter 06 Jul '18

06 Jul '18

On Tue, Aug 14, 2012 at 12:29:05AM +0200, HardKor wrote: > Is it possible to connect to Tor from Ethiopia ? Is there any blocking > strategy ? The standard TBB does not work because Ethiopia is currently fingerprinting and dropping both, the TLS client and server hello. More details are available here: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki/Censo… However, there are slightly modified bridges which can circumvent this block and make Tor usable from within Ethiopia. (You'll get such a bridge by writing to "help at rt.torproject.org".) Philipp _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- 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

[dgc.chat] Crowne Gold Update
by Sean Trainor 06 Jul '18

06 Jul '18

To all for worldwide delivery. Update: Crowne Gold I wanted to brief the Gold community on the situation at Crowne Gold and apologize for the delay in coming back on-line after recent events. Crownes staff is available and working even though servers have not been accessible. Heres a brief overview of what happened and where we are: Crowne Gold was attacked by hackers who attempted to hijack U.S. $7 million but failed. They failed in part because members of the digital gold community quickly offered assistance to thwart their assault. The level of cooperation was excellent. Hackers managed to breach part of the Crowne Gold system due to a key-logging program not recognized by the most up-to-date anti-virals that came in attached to an email directed to a customer service person. The email was sent and received outside the normal encrypted email system provided within the Crowne Gold program. This was not a frontal attack on the server but rather a carefully orchestrated process that engaged direct email interaction between the hackers (under alias) and a customer service person from their own workstation. By getting an administrator to respond directly to email, the hackers gained access to a computer half a world away from the front-end server and eventually captured administrative logons. The primary server system was not attacked until Carnival was in full swing in the Caribbean from whence Crowne Gold customer service functions are provided. When it was discovered that hackers had penetrated the system, IP addresses were put under trace and the information gained was submitted to Interpol. Crowne elected to shutdown servers including front-end, back-up, and double mirror-backup systems in order to ascertain the extent of the penetration. Even the customer service network was shutdown until IT personnel arrived on site and made changes to secure these normally benign networks. The hackers were both clever and to some extent lucky, on the other hand, and as already pointed out, they failed to make even a single dollar out of the entire exercise. However, we have been led to believe that they have attempted to blackmail other digital gold providers based on their ability to force the temporary shutdown of Crowne Gold. So where are we now? As you may be aware, Crowne Gold absorbed the former 3PGold whose front-end server was located at Havenco at the Principality of Sealand. Havenco is physically secure but when the hackers accessed Crowne Golds equipment at the Havenco server farm, there was no one on location at Havenco to support the several IT persons on the Crowne Gold side who desperately needed on site assistance. It took several days for Havenco staff to respond to calls for assistance and then it became immediately apparent that those in communication were nowhere near the actual Havenco platform. Hence Havenco is now a backup server in the new server structure, at least until Havenco is able to provide 24/7 support on-site. Considerable changes have been made which required the server systems to remain down longer than we would have liked but safe rather than sorry has been pretty much the by-line of the entire event. There are a host of technology enhancements now taking place, both hardware and software, but to say more than this would probably be unwise. Again we apologize for the delay. We have been rudely educated. Yet as things go it has been a dramatic wake-up call and probably the best time possible for us to live through this experience. To our customers, the digital gold community, and new users, we apologize for this huge inconvenience. Rest assured we will be back online soon and with a system that is better suited for our future success together. I can be reached at sean(a)crowne-gold.com for further details regarding our position. Best regards, Sean Trainor Sean Trainor Crowne-Gold The worlds easiest way to buy, sell, hold and use gold as money. WWW.Crowne-Gold.com sean(a)crowne-gold.com 727-418-4905 subscribe: send blank email to dgcchat-join(a)lists.goldmoney.com unsubscribe: send blank email to dgcchat-leave(a)lists.goldmoney.com digest: send an email to dgcchat-request(a)lists.goldmoney.com with "set yourname(a)yourdomain.com digest" in the message body --- 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

[i2p] 0.5 is available
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, After 6 months of work on the 0.4 series, we've implemented and deployed the new streaming library, integrated and tested bittorrent, mail, and naming apps, fixed a bunch of bugs, and learned as much as we could from real world users. We now have a new 0.5 release which reworks the tunnel routing algorithms, improving security and anonymity while giving the user more control of their own performance related tradeoffs. In addition, we've bundled susi23's susimail client, upgraded to the latest Jetty (allowing both symlinks and CGI), and a whole lot more. This new release is not backwards compatible - you must upgrade to get anything useful done. There has been a lot of work going on since 0.4.2.6 a month and a half ago, with contributions by smeghead, duck, Jhor, cervantes, Ragnarok, Sugadude, and the rest of the rabid testers in #i2p and #i2p-chat. I could write for pages describing whats up, but instead I'll just direct you to the change log at http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD For the impatient, please review the install and update instructions up at http://www.i2p.net/download Please note that since this new release updates the classpath, the update process will require you to start up the router again after it finishes. Any local modifications to the wrapper.config will be lost when updating, so please be sure to back it up. In addition, even though this new release includes the latest Jetty (5.1.2), if you want to enable CGI support, you will need to edit your ./eepsite/jetty.xml to include: <Call name="addContext"> <Arg>/cgi-bin/*</Arg> <Set name="ResourceBase">./eepsite/cgi-bin</Set> <Call name="addServlet"> <Arg>Common Gateway Interface</Arg> <Arg>/</Arg> <Arg>org.mortbay.servlet.CGI</Arg> <Put name="Path">/usr/local/bin:/usr/ucb:/bin:/usr/bin</Put> </Call> </Call> adjusting the Path as necessary for your OS/distro/tastes. New users have it easy - all of this is done for them. While the docs on the website haven't been updated to reflect the new tunnel routing and crypto changes yet, the nitty gritty is up at http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HE… There will be another release in the 0.5 series beyond this one, including more options for allowing the user to control the impact of predecessor attacks on their anonymity. There will certainly be performance and load balancing improvements as well, using the feedback we get deploying the new tunnel code on a wider network. Until the UDP transport is added in 0.6, we will want to continue to be fairly low key, as we've already run into the default limits on some braindead OSes (*cough*98*cough*). There is much we can improve upon while the network is small though, and while I know we all want to go out and show the world what I2P can do, another two months waiting won't hurt. Anyway, thats that. The new net is up and running, squid.i2p and other services should be up, you know where to get the goods, so get goin'! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCFc3OGnFL2th344YRAszOAKCfTh/OOAAyonRmKoRF/iw5BwRkZACgpGp4 qHMJkSo2mzjHTHRf98fsvdM= =Vfl3 -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- 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

Re: [IP] Bank Transactions?
by Barry Steinhardt 06 Jul '18

06 Jul '18

Dave, I don't think we know for certain what access the NSA has to financial information, but the Federal Government has a financial center known as FinCen to which the banks and other institutions report millions of financial transactions. FinCen has a staggering amount of financial data about Americans. Below you will find a short description of FinCen from Privicilla.org. A big outstanding question about the NSA is the extent to which they data mine or otherwise use the communications data they have obtained from the "program", in conjunction with other data, including financial data, that is in the hands of the Federal Government or is available from the commercial sector. You may recall that the Pentagon's (DARPA's) Total Information Awareness Program (TIA) sought to analyze a vast quantity of public and private data about Americans to identify and profile suspects. http://www.aclu.org/privacy/spying/14956res20040116.html The Congress shut down the public version of TIA run by Admiral John Poindexter, but allowed significant portions of it to continue to operate applying to non-US persons. That view includes the power to troll through the communications records of hundreds of millions of Americans looking for clues to contact with "foreign terrorists". The NSA may well have a piece of the TIA action or may be a part of a larger effort within the Pentagon to continue the work of TIA. When asked about this in a Senate hearing by Senator Ron Wyden, General Hayden said he could not respond in public. All these matters are classified and we don't know what, if anything ,he told Senator Wyden in private, but this question needs to be very carefully examined. Barry Steinhardt ACLU >From Privicilla.org: "FinCEN," the Financial Crimes Enforcement Network, is a network of databases and financial records maintained by the U.S. federal government. Housed within the Treasury Department, FinCEN handles more than 140 million computerized financial records compiled from 21,000 depository institutions and 200,000 nonbank financial institutions. Banks, casinos, brokerage firms and money transmitters all must file reports with FinCEN on cash transactions over $10,000. And FinCen is the repository for "Suspicious Activity Reports" which must be filed by financial institutions under the Bank Secrecy Act. FinCEN also uses a variety of law enforcement databases, including those operated by the Drug Enforcement Agency and the Defense Department, in addition to commercial databases of public records. FinCEN may also use databases held by the Central Intelligence Agency, the National Security Agency, and the Defense Intelligence Agency. FinCEN shares information with investigators from dozens of agencies, including the Bureau of Alcohol, Tobacco, and Firearms; the Drug Enforcement Administration; the Federal Bureau of Investigation; the U.S. Secret Service; the Internal Revenue Service; the Customs Service; and the the U.S. Postal Inspection Service. Agents from all these agencies can investigate names, addresses, and Social Security numbers through FinCEN. Field agents and state and local law enforcement can access data from FinCEN remotely. On 5/13/06 7:42 AM, "David Farber" <dave(a)farber.net> wrote: > > >Begin forwarded message: > >From: anitaclaremadsen(a)netscape.net >Date: May 13, 2006 7:16:38 AM EDT >To: dave(a)farber.net >Subject: Bank Transactions? > > >Anyone know if the NSA also is collecting/data mining customer bank/ >credit card records under the historic, "Follow the Money" advice >give to Woodward by Deep Throat? > > >___________________________________________________ >Try the New Netscape Mail Today! >Virtually Spam-Free | More Storage | Import Your Contact List >http://mail.netscape.com > > > >------------------------------------- >You are subscribed as bsaclu(a)earthlink.net >To manage your subscription, go to > http://v2.listbox.com/member/?listname=ip > >Archives at: http://www.interesting-people.org/archives/interesting- >people/ ------------------------------------- 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] more on Bank Transactions?
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[dgc.chat] Crowne Gold Update
by Sean Trainor 06 Jul '18

06 Jul '18

To all for worldwide delivery. Update: Crowne Gold I wanted to brief the Gold community on the situation at Crowne Gold and apologize for the delay in coming back on-line after recent events. Crownes staff is available and working even though servers have not been accessible. Heres a brief overview of what happened and where we are: Crowne Gold was attacked by hackers who attempted to hijack U.S. $7 million but failed. They failed in part because members of the digital gold community quickly offered assistance to thwart their assault. The level of cooperation was excellent. Hackers managed to breach part of the Crowne Gold system due to a key-logging program not recognized by the most up-to-date anti-virals that came in attached to an email directed to a customer service person. The email was sent and received outside the normal encrypted email system provided within the Crowne Gold program. This was not a frontal attack on the server but rather a carefully orchestrated process that engaged direct email interaction between the hackers (under alias) and a customer service person from their own workstation. By getting an administrator to respond directly to email, the hackers gained access to a computer half a world away from the front-end server and eventually captured administrative logons. The primary server system was not attacked until Carnival was in full swing in the Caribbean from whence Crowne Gold customer service functions are provided. When it was discovered that hackers had penetrated the system, IP addresses were put under trace and the information gained was submitted to Interpol. Crowne elected to shutdown servers including front-end, back-up, and double mirror-backup systems in order to ascertain the extent of the penetration. Even the customer service network was shutdown until IT personnel arrived on site and made changes to secure these normally benign networks. The hackers were both clever and to some extent lucky, on the other hand, and as already pointed out, they failed to make even a single dollar out of the entire exercise. However, we have been led to believe that they have attempted to blackmail other digital gold providers based on their ability to force the temporary shutdown of Crowne Gold. So where are we now? As you may be aware, Crowne Gold absorbed the former 3PGold whose front-end server was located at Havenco at the Principality of Sealand. Havenco is physically secure but when the hackers accessed Crowne Golds equipment at the Havenco server farm, there was no one on location at Havenco to support the several IT persons on the Crowne Gold side who desperately needed on site assistance. It took several days for Havenco staff to respond to calls for assistance and then it became immediately apparent that those in communication were nowhere near the actual Havenco platform. Hence Havenco is now a backup server in the new server structure, at least until Havenco is able to provide 24/7 support on-site. Considerable changes have been made which required the server systems to remain down longer than we would have liked but safe rather than sorry has been pretty much the by-line of the entire event. There are a host of technology enhancements now taking place, both hardware and software, but to say more than this would probably be unwise. Again we apologize for the delay. We have been rudely educated. Yet as things go it has been a dramatic wake-up call and probably the best time possible for us to live through this experience. To our customers, the digital gold community, and new users, we apologize for this huge inconvenience. Rest assured we will be back online soon and with a system that is better suited for our future success together. I can be reached at sean(a)crowne-gold.com for further details regarding our position. Best regards, Sean Trainor Sean Trainor Crowne-Gold The worlds easiest way to buy, sell, hold and use gold as money. WWW.Crowne-Gold.com sean(a)crowne-gold.com 727-418-4905 subscribe: send blank email to dgcchat-join(a)lists.goldmoney.com unsubscribe: send blank email to dgcchat-leave(a)lists.goldmoney.com digest: send an email to dgcchat-request(a)lists.goldmoney.com with "set yourname(a)yourdomain.com digest" in the message body --- 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

[i2p] 0.5 is available
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, After 6 months of work on the 0.4 series, we've implemented and deployed the new streaming library, integrated and tested bittorrent, mail, and naming apps, fixed a bunch of bugs, and learned as much as we could from real world users. We now have a new 0.5 release which reworks the tunnel routing algorithms, improving security and anonymity while giving the user more control of their own performance related tradeoffs. In addition, we've bundled susi23's susimail client, upgraded to the latest Jetty (allowing both symlinks and CGI), and a whole lot more. This new release is not backwards compatible - you must upgrade to get anything useful done. There has been a lot of work going on since 0.4.2.6 a month and a half ago, with contributions by smeghead, duck, Jhor, cervantes, Ragnarok, Sugadude, and the rest of the rabid testers in #i2p and #i2p-chat. I could write for pages describing whats up, but instead I'll just direct you to the change log at http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD For the impatient, please review the install and update instructions up at http://www.i2p.net/download Please note that since this new release updates the classpath, the update process will require you to start up the router again after it finishes. Any local modifications to the wrapper.config will be lost when updating, so please be sure to back it up. In addition, even though this new release includes the latest Jetty (5.1.2), if you want to enable CGI support, you will need to edit your ./eepsite/jetty.xml to include: <Call name="addContext"> <Arg>/cgi-bin/*</Arg> <Set name="ResourceBase">./eepsite/cgi-bin</Set> <Call name="addServlet"> <Arg>Common Gateway Interface</Arg> <Arg>/</Arg> <Arg>org.mortbay.servlet.CGI</Arg> <Put name="Path">/usr/local/bin:/usr/ucb:/bin:/usr/bin</Put> </Call> </Call> adjusting the Path as necessary for your OS/distro/tastes. New users have it easy - all of this is done for them. While the docs on the website haven't been updated to reflect the new tunnel routing and crypto changes yet, the nitty gritty is up at http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HE… There will be another release in the 0.5 series beyond this one, including more options for allowing the user to control the impact of predecessor attacks on their anonymity. There will certainly be performance and load balancing improvements as well, using the feedback we get deploying the new tunnel code on a wider network. Until the UDP transport is added in 0.6, we will want to continue to be fairly low key, as we've already run into the default limits on some braindead OSes (*cough*98*cough*). There is much we can improve upon while the network is small though, and while I know we all want to go out and show the world what I2P can do, another two months waiting won't hurt. Anyway, thats that. The new net is up and running, squid.i2p and other services should be up, you know where to get the goods, so get goin'! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCFc3OGnFL2th344YRAszOAKCfTh/OOAAyonRmKoRF/iw5BwRkZACgpGp4 qHMJkSo2mzjHTHRf98fsvdM= =Vfl3 -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- 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