July 2018 - cypherpunks-legacy

[bitcoin-list] Bitcoin 0.3.19 is released
by Satoshi Nakamoto 06 Jul '18

06 Jul '18

This is a minor release to add some DoS protection. Changes: - Added some DoS limits, though it's still far from DoS resistant. - Removed "safe mode" alerts. http://www.bitcoin.org/smf/index.php?topic=2228.0 Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/ ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ bitcoin-list mailing list bitcoin-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list ----- 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

[bitcoin-list] Bitcoin 0.3.19 is released
by Satoshi Nakamoto 06 Jul '18

06 Jul '18

This is a minor release to add some DoS protection. Changes: - Added some DoS limits, though it's still far from DoS resistant. - Removed "safe mode" alerts. http://www.bitcoin.org/smf/index.php?topic=2228.0 Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/ ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ bitcoin-list mailing list bitcoin-list(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list ----- 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: [liberationtech] Exactly how are satellite transmissions tapped/intercepted, in Syria and elsewhere?
by Enrique Piraces 06 Jul '18

06 Jul '18

Thanks Matt. Indeed there seems to be a significant number of options to intercept, for example, Thuraya. For those interested, a few sample results of a quick google search: "The L-3 TRL Thuraya Monitoring System that passively intercepts C-band and L-band downlinks from the Thuraya satellites. The TMS monitors transmissions from the Thuraya handset to the network via the satellite at C-band, and monitors transmissions from the network to the Thuraya handset at L-band. This provides full duplex interception and recording for all calls passing through the seven spotbeams centered on the installed system" More on this: http://www.trltech.co.uk/app/webroot/files/L-3%20TRL%20TMS%20Brochure(1).pdf Other: http://www.interceptors.com/intercept-solutions/Thuraya-Satellite-Intercept… http://www.stratign.com/communication_intelligence.asp Brian, I'd be interested in learning more about the product of your research. Best, Enrique On Nov 29, 2011, at 12:44 PM, Matt Mackall wrote: On Tue, 2011-11-29 at 16:43 +0000, Enrique Piraces wrote: Hi all, thanks for the detailed responses on this thread. I'm trying to understand how weak BGAN, Thuraya, Iridium encryption could be. For example one of them claims in its site that "Thuraya's integrated satellite communication solutions are rapidly deployable, employ the highest level of encryption, and are proven in meeting exacting security standards for use in the field." A security self-evaluation by a company's marketing department isn't worth much. Beyond the ability that some may have to detect the location of a call/connection and log their calls, how true is that their encryption can protect the contents of the information transmitted? Is the risk the same for each voice/data/text? Thuraya is a telecom company, which means the default assumption should be that they: - use poorly-implemented crypto that can be defeated by sophisticated third parties - have built-in "lawful intercept capability" - have extensive logging and data retention - will hand this data over to authorities at the slightest provocation The past decade has shown us the above is true of basically all terrestrial providers, and there's no good reason to think satellite is different. And there's no reason to think they've done a better job with their crypto tech than the industry groups that created WEP and GSM. Is part of the solution to use encryption modules like http://www.shoghicom.com/thuraya-encryption.html? No. The first two bullet points above (at least!) probably apply. The only way for a private citizen to get assurances that are better than marketing copy is to use open source tools that have survived the close public scrutiny of the security community. -- Mathematics is the supreme nostalgia of our time. _______________________________________________ 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

Re: [ZS] Bitcoin Seeks New Life In Africa
by Bryce Lynch 06 Jul '18

06 Jul '18

On Wed, Mar 21, 2012 at 12:19, Gary Mulder <flyingkiwiguy(a)gmail.com> wrote: > One key feature of Bitcoin is that a transaction is non-revocable. Once you > send Bitcoins to a Bitcoin wallet address, the Bitcoins are irrevocably Incidentally, and this is something that needs to be said out of due dilligence, this is what helped kill e-cash in the 90's when some of the cypherpunks came in from the cold and started their own e-cash ventures. We can't forget that chargebacks are how banks make a lot of money, and they still don't know how to act when that's not possible. > Therefore nobody accepts PayPal for Bitcoin purchases. Credit cards also Paypal also started locking the accounts of people who were accepting currency in exchange for Bitcoins. So far as I know, those accounts are still locked out and the funds in them are still frozen. > have identical issues. Also, get the destination Bitcoin address wrong and > the Bitcoins sent can never be recovered by anyone That is a huge, huge problem. On the desktop/laptop side that's mitigated by cut-and-paste. It's also a good argument for escrow of funds - to catch that problem. On the mobile side, I know a few people are working on QRcodes for exchange of Bitcoin account codes. > If you want to confirm GBP into Bitcoins you need to use a Bitcoin exchange. > The guys at http://www.intersango.com accept SEPA and bank transfers to > their Lloyds TSB account. The funds usually show up in your exchange account > around 1 business day later. I know the guys running Intersango, and they > are legit. and are based in London and Poland. Having said that they've had > to change from HSBC to Lloyds as HSBC was giving them a lot of problems, so > don't make any large deposits. http://www.mtgox.com is the other large > exchange which is based in France and Japan. The major weakness in Bitcoin Also remember that MTgox got pwned but good a couple of weeks ago. Confidence in them tanked as a result. > are the exchanges, as they're they interface between normal currencies and > the Bitcoin ecosystem, and so suffer all the problems and risks of both > systems, i.e. regulation, security, and technical issues. On the less legitimate side, there are a number of people out there with fairly high reputation scores on darknet fora who convert one-time-use Greendot codes into Bitcoins in an anonymous manner. They're pretty highly ranked on the Silk Road. On the Third Black Market, not so much, but time will show who's good at it and who's not. What I'm curious about (though I probably shouldn't be) is how the exchangers in question are cashing out their Greendot and Moneypak cards because (in the US at least) they have to be tied to a government acknowledged identity, which torpedos anonymity. > Caveat emptor - this is the Wild Wild West of currency. Yee-haw. -- The Doctor [412/724/301/703] https://drwho.virtadpt.net/ "I am everywhere." -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- 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: [liberationtech] Exactly how are satellite transmissions tapped/intercepted, in Syria and elsewhere?
by Enrique Piraces 06 Jul '18

06 Jul '18

Thanks Matt. Indeed there seems to be a significant number of options to intercept, for example, Thuraya. For those interested, a few sample results of a quick google search: "The L-3 TRL Thuraya Monitoring System that passively intercepts C-band and L-band downlinks from the Thuraya satellites. The TMS monitors transmissions from the Thuraya handset to the network via the satellite at C-band, and monitors transmissions from the network to the Thuraya handset at L-band. This provides full duplex interception and recording for all calls passing through the seven spotbeams centered on the installed system" More on this: http://www.trltech.co.uk/app/webroot/files/L-3%20TRL%20TMS%20Brochure(1).pdf Other: http://www.interceptors.com/intercept-solutions/Thuraya-Satellite-Intercept… http://www.stratign.com/communication_intelligence.asp Brian, I'd be interested in learning more about the product of your research. Best, Enrique On Nov 29, 2011, at 12:44 PM, Matt Mackall wrote: On Tue, 2011-11-29 at 16:43 +0000, Enrique Piraces wrote: Hi all, thanks for the detailed responses on this thread. I'm trying to understand how weak BGAN, Thuraya, Iridium encryption could be. For example one of them claims in its site that "Thuraya's integrated satellite communication solutions are rapidly deployable, employ the highest level of encryption, and are proven in meeting exacting security standards for use in the field." A security self-evaluation by a company's marketing department isn't worth much. Beyond the ability that some may have to detect the location of a call/connection and log their calls, how true is that their encryption can protect the contents of the information transmitted? Is the risk the same for each voice/data/text? Thuraya is a telecom company, which means the default assumption should be that they: - use poorly-implemented crypto that can be defeated by sophisticated third parties - have built-in "lawful intercept capability" - have extensive logging and data retention - will hand this data over to authorities at the slightest provocation The past decade has shown us the above is true of basically all terrestrial providers, and there's no good reason to think satellite is different. And there's no reason to think they've done a better job with their crypto tech than the industry groups that created WEP and GSM. Is part of the solution to use encryption modules like http://www.shoghicom.com/thuraya-encryption.html? No. The first two bullet points above (at least!) probably apply. The only way for a private citizen to get assurances that are better than marketing copy is to use open source tools that have survived the close public scrutiny of the security community. -- Mathematics is the supreme nostalgia of our time. _______________________________________________ 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

Re: [ZS] Bitcoin Seeks New Life In Africa
by Bryce Lynch 06 Jul '18

06 Jul '18

On Wed, Mar 21, 2012 at 12:19, Gary Mulder <flyingkiwiguy(a)gmail.com> wrote: > One key feature of Bitcoin is that a transaction is non-revocable. Once you > send Bitcoins to a Bitcoin wallet address, the Bitcoins are irrevocably Incidentally, and this is something that needs to be said out of due dilligence, this is what helped kill e-cash in the 90's when some of the cypherpunks came in from the cold and started their own e-cash ventures. We can't forget that chargebacks are how banks make a lot of money, and they still don't know how to act when that's not possible. > Therefore nobody accepts PayPal for Bitcoin purchases. Credit cards also Paypal also started locking the accounts of people who were accepting currency in exchange for Bitcoins. So far as I know, those accounts are still locked out and the funds in them are still frozen. > have identical issues. Also, get the destination Bitcoin address wrong and > the Bitcoins sent can never be recovered by anyone That is a huge, huge problem. On the desktop/laptop side that's mitigated by cut-and-paste. It's also a good argument for escrow of funds - to catch that problem. On the mobile side, I know a few people are working on QRcodes for exchange of Bitcoin account codes. > If you want to confirm GBP into Bitcoins you need to use a Bitcoin exchange. > The guys at http://www.intersango.com accept SEPA and bank transfers to > their Lloyds TSB account. The funds usually show up in your exchange account > around 1 business day later. I know the guys running Intersango, and they > are legit. and are based in London and Poland. Having said that they've had > to change from HSBC to Lloyds as HSBC was giving them a lot of problems, so > don't make any large deposits. http://www.mtgox.com is the other large > exchange which is based in France and Japan. The major weakness in Bitcoin Also remember that MTgox got pwned but good a couple of weeks ago. Confidence in them tanked as a result. > are the exchanges, as they're they interface between normal currencies and > the Bitcoin ecosystem, and so suffer all the problems and risks of both > systems, i.e. regulation, security, and technical issues. On the less legitimate side, there are a number of people out there with fairly high reputation scores on darknet fora who convert one-time-use Greendot codes into Bitcoins in an anonymous manner. They're pretty highly ranked on the Silk Road. On the Third Black Market, not so much, but time will show who's good at it and who's not. What I'm curious about (though I probably shouldn't be) is how the exchangers in question are cashing out their Greendot and Moneypak cards because (in the US at least) they have to be tied to a government acknowledged identity, which torpedos anonymity. > Caveat emptor - this is the Wild Wild West of currency. Yee-haw. -- The Doctor [412/724/301/703] https://drwho.virtadpt.net/ "I am everywhere." -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- 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] "Meet the groundbreaking new encryption app set to revolutionize privacy..."
by Jon Callas 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am separating this from my previous as I went into a rant. As we were designing Silent Text, we talked to a lot of people about what they needed. I don't remember who told me this anecdote, but this person went over to a colleague's office after they'd been texting to just talk. They walked into the colleagues office and noticed their phone open with a conversation plainly visible with someone else. A third party who was their mutual colleague was texting about that meeting. In short: Alice goes to Bob's office for a meeting and sees texts from Charlie about that meeting, including comments about Alice. There wasn't anything untoward about the texting. No insults about Alice or anything, but there was an obvious privacy loss here. What if it *had* been included an intemperate comment about our Alice? Alice said nothing about it to Bob, but I got an earful. That earful included the opinion that the threat of accidental disclosure of messages within a group of people is greater than either the messages "being plucked out of the air" or seizure and forensic groveling over the device. Alice's opinion was that when people have a secure communications channel, they loosen up and say things that are more dramatic than they would be otherwise. It's not that they're more honest, they're less honest. They're exaggerated to the point of hyperbolic at times. Alice said that she knew that she'd texted some things to Bob that she really wouldn't want the person she'd said them about to see them. They were said quickly, in frustration, and so on. It's not that they'd be taken out of context, it's that they'd be taken *in* context. It's interesting underlying the story, Alice suddenly saw Bob not as an ally in snark, but a threat -- the sort of person who leaves their phone unlocked on their desk. Bob, of course, would say something like that if the texts had been potentially offensive, he'd have locked his phone. This explanation would thus convince Alice that Bob is *really* not to be trusted with snark. This is incredibly perceptive, that the greatest security threat is not the threat from outside, it's the threat from inside. It is exactly Douglas Adams's point about the babelfish that by removing barriers to communication, it created more and bloodier wars than anything else. That's where "Burn Notice" came from. It's a safety net so that when Charlie texts Bob, "I'm tired of Alice always..." it goes away. What I find amusing is the reaction to it all around. There's a huge manic-depressive, bimodal reaction. Lots of people get ahold of this and they're like girls who've gotten ahold of makeup for the first time. ZOMG! You mean my eyelids can be PURPLE and SPARKLY? This is the same thing that happens when people discover font libraries or text-to-speech systems. For a couple of days that someone gets the new app, there's nothing but text messages that are self-destructing, purple, sparkly eyelids with font-laden Tourette's Syndrome with the Mission Impossible theme song playing in the background. (Note, if you are using Silent Text, you can't actually make the text purple, nor sparkly, nor change fonts. You need to put all of that in a PDF or an animated GIF -- and you will. This is a metaphor, not a requirements document.) The next thing that happens is that they are so impressed with some particularly inspired bit self-desctructing childishness that they take a screen shot. As they gaze at the screen shot, or sometimes just as they take the screen shot, light dawns. Oh. You mean.... Oh. Then the depressive phase kicks in. Back in the dark ages, PGP had the "For Your Eyes Only" feature. This is pretty much the ancestor of Burn Notice. Simultaneously useful and worthless. It's useful because it signals to your partner that this is not only secret but sensitive and does something to stop accidental disclosure. It is utterly ineffective against a hostile partner for many of the same reasons. We did all sorts of silly things with FYEO that included an anti-TEMPEST/Van Eck font, and other things. Silent Text actually has an FYEO feature that isn't exposed, thank heavens. I mention all of that because once you're in the depressive phase, it's easy to go down the same rathole we did with FYEO. I spent time researching if you can prevent screen shots on iOS (you can't). I did this while telling people that it was dumb because I can take a picture of my iPhone with my iPad. I held up my phone to video chat and said, "Here, see this? This is what you can do!" Sanity prevailed, but I think that fifteen years of FYEO helped a lot. When you stare into self-destructing messages, trying to figure out how make them really go away flawlessly, they stare back. You will end up trying to figure out how to do a destructive two-phase commit, what class libraries need to be patched so those that non-mutable strings inherit from mutable strings (not the other way around), all while a nagging voice whispers in the back of your head about how brave freedom fighters are gonna die because of this. After the depressive phase comes the patronizing, retributive phase in which it's clear that letting people delete potentially embarrassing messages is bad, because it's imperfect. Imperfect security is worse than plaintext. People have to learn self-control. Cue the Kalil Gibran quotes. People can't just say any old thing on a secure chat program because that leads to purple eyeshadow and thus inevitably to brave freedom fighters having their phones seized at borders, and then people will die -- all because we let them delete their incriminating messages. This phase makes so little sense that it's hard for me even to mock it. But the gist of that objection really is that it's bad to let people delete sensitive things because that will cause seizure of sensitive things. Otherwise sane people have said this to me, and they don't seem to see how funny they are. Nonetheless, there's two things that happen. On the one hand, there are people who think this cute, simple feature is the second coming of sliced bread. The other hand is the people who insist it must be impossible (because they've over-thought it) or evil (because security shouldn't be fun, let alone purple). There is a small point to the dour, greyfaced side of this, I admit. You cannot solve human problems with technology. Technology often just shuffles around the brilliance that humans have at shooting themselves in the foot. I'm well aware of Laotse's snarky comment that the invention of locks created burglary, and I often agree with him. But I think there has to be fun with security. We talk a lot about how security has to be usable, but I think fun is up there, too. If it's fun, people will use it. They make their mistakes cheaply, and in a reasonably safe environment. Most of all, they'll actually use it. That's been the challenge of the last couple decades, getting people to use it. People use things that they play with. I think thus that play is part of security, too. What's "groundbreaking" in what we're doing is that we're having fun and encouraging others to do so, too. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFRFfWQsTedWZOD3gYRAmYJAKDJ8exiTiWgzMy11mp/FKEN8TXpUACdHTPW dHbRrgTqwb3R5oPHvWEC8Pg= =b3gk -----END PGP SIGNATURE----- _______________________________________________ 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

Pseudonymity for tor: nym-0.1
by Jason Holt 06 Jul '18

06 Jul '18

Per the recent discussion regarding tor and wikipedia, I've hacked together an implementation of the basic system from Chaum, Fiat and Naor's 1990 "Untraceable Electronic Cash" paper. This system allows CAs to blindly issue tokens (or "coins") which can then be "spent" elsewhere. It runs in perl, and comprises a CA, nym-maker, client application and auth checker (for the server). The tarball is here: http://www.lunkwill.org/src/nym/ Of course, it's useless at the moment since it gives out tokens indiscriminately (and probably has massive bugs), but if anyone actually cares about this idea, it will be (more or less) easy to do the following: * Put up a sample CA and server that people can use (potentially as hidden services). * Make the CA issue only one token per email address, or one token per IP address, one per computational puzzle, one for every $20 mailed in... * Automatically expire CA keys and generate new ones on a regular basis (rather than bothering with CRLs) * Instead of randomly generated tokens, have the CA sign an actual X.509 cert request, which will then become a perfectly valid X.509 cert useful as a client-side cert in unmodified browsers and web servers * Create some sort of aid for maintaining server-side (or CA) blacklists of improperly behaving users * Check to see if the protocol is actually still secure and properly implemented. Comments welcome. -J ----- 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

Hacker strikes through student's router
by Thomas Hardly 06 Jul '18

06 Jul '18

http://www.rose-hulman.edu/Users/groups/Thorn/HTML/ http://www.rose-hulman.edu/Users/groups/Thorn/HTML/current/frontpage/1.html Hacker strikes through student's router Alex Clerc Earlier this week, a hacker infiltrated the website of a company in France, defacing the site and using it to send vulgar emails. The hacker was not a Rose-Hulman student. But through a router maintained by a Rose-Hulman student, the hacker was able to do this anonymously. The student, senior computer science major David Yip, was maintaining a router on his computer called a Tor onion router. What Tor basically does is enable anonymous communications over the internet. Yip downloaded and installed Tor on his computer about two months ago. His machine became a Tor exit node on September 4, 2005. Early Thursday morning, the French company traced the hacker back to Yip's computer and contacted IAIT. IAIT took action by freezing Yip's Kerberos account; he is unable to access the Internet, email, Angel, or Banner. His case will be considered by the Computer Use Committee and a recommendation will be made to Pete Gustafson, the Dean of Students if disciplinary action is deemed appropriate. Staff members at IAIT were unwilling to comment on the circumstances, as was Gustafson. In an interview, Yip made it clear that he read the policy for responsible use of Rose-Hulman computing facilities and took the "due diligence" it demands for students setting up networks. As a precaution against people using his machine for malicious activity, Yip disabled the ability to send mail, use peer-to-peer programs, and use internet relay chat (IRC). He also limited the transfer quota to 800 megabytes per day. "The services I left open are generally considered to be benign," he said. Yip stated that he saw nothing specifically banning Tor nodes in the Rose-Hulman internet policy. Yip does not know who has been using his Tor node or what it has been used for. "That's the point," he said. "Being able to communicate anonymously is very important. I feel there are certain ideas in certain contexts that cannot be expressed unless they are expressed anonymously." "I also find [Tor] interesting from a research standpoint. It's a neat research project," Yip added. Tor was originally developed by the U.S. Naval Research Laboratory and has been facilitated by the Electronic Frontier Foundation (EFF) for the last year and a half. According to Fred von Lohmann, a staff attorney at the EFF, Yip's case is the first case ever involving potential disciplinary action for the use of Tor. "If this is something that was done by a third party, the student shouldn't be held responsible," he said. Assistant Professor of Computer Science Larry Merkle disagreed: "I can definitely see there being a case against [Yip] because he used bandwidth for non-academic purposes." Merkle added, "? but I know [Yip] fairly well and I don't think he had any malicious intentions." What Tor enables ? anonymous online communications ? raises ethical questions that are yet to be settled. By allowing anonymous communications to anyone, it offers equal protection to both good and bad users. Van Lohmann said, "Before we start questioning the right to anonymous speech, we need to ask if the [French] website's security had a flaw." Professor of Computer Science David Mutchler added, "I think anonymous communication over the Internet is critical. There are many places in the world where free speech is not protected. Anonymous communication allows that free speech to exist." On its website, the EFF lists many beneficial applications of Tor, including socially sensitive communications (such as chat rooms for victims of rape, abuse, or illnesses) and journalistic communications with whistleblowers and dissidents. Law enforcement groups can use Tor for data sting operations and the U.S. Navy uses it for open source intelligence gathering. Merkle warned, "The [EFF] makes a good case for the reasons to use it, but completely ignores the reasons why providing it might be bad for society." Situations involving improper Internet use are usually first detected by IAIT and then passed to Student Affairs. If an expert opinion is needed, the case is presented to the Computer Use Committee. Pete Gustafson makes the final decision. The last incident in which the Computer Use Committee was consulted was a case in the '03-'04 school year. The case involved a student hacking in to the computer of an employee of the admissions office. The student then attempted to send an all campus email claiming that one of the Olsen twins decided to attend Rose-Hulman. The Computer Use Committee recommended that the student be suspended; Pete Gustafson followed through on this recommendation. "The single best thing that can come of this," concluded Mutchler, "would be if students read the policy at www.rose-hulman.edu/TSC/policies/computer_use and discuss with faculty and administration any parts of the policy that they think are not right." -- ..o: It's 12 o'clock - do you know where your data is? :o... ----------------------------------------------------------------------------- -------------- Hardening Your Macintosh - http://members.lycos.co.uk/hardapple/ pgp key fingerprint: 0F02 99D5 1D23 E445 22C9 9C90 8F24 FDBA B618 33C4 ----- 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

Pseudonymity for tor: nym-0.1
by Jason Holt 06 Jul '18

06 Jul '18

Per the recent discussion regarding tor and wikipedia, I've hacked together an implementation of the basic system from Chaum, Fiat and Naor's 1990 "Untraceable Electronic Cash" paper. This system allows CAs to blindly issue tokens (or "coins") which can then be "spent" elsewhere. It runs in perl, and comprises a CA, nym-maker, client application and auth checker (for the server). The tarball is here: http://www.lunkwill.org/src/nym/ Of course, it's useless at the moment since it gives out tokens indiscriminately (and probably has massive bugs), but if anyone actually cares about this idea, it will be (more or less) easy to do the following: * Put up a sample CA and server that people can use (potentially as hidden services). * Make the CA issue only one token per email address, or one token per IP address, one per computational puzzle, one for every $20 mailed in... * Automatically expire CA keys and generate new ones on a regular basis (rather than bothering with CRLs) * Instead of randomly generated tokens, have the CA sign an actual X.509 cert request, which will then become a perfectly valid X.509 cert useful as a client-side cert in unmodified browsers and web servers * Create some sort of aid for maintaining server-side (or CA) blacklists of improperly behaving users * Check to see if the protocol is actually still secure and properly implemented. Comments welcome. -J ----- 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