July 2018 - cypherpunks-legacy

AOL search logs: law enforcement implications
by Richard Wiggins 06 Jul '18

06 Jul '18

Dave, For IP if you wish: Imagine how law enforcement at all levels is reacting to the AOL search log exposure. Now there is a searchable database of the search logs: See http://www.aolsearchdatabase. You can quickly locate people who may be planning crimes. We find, for instance, 43,206 people searched for "child porn." Now, do a new search, filtering only by a user number. You'll see all the searches that person did over a three month period. Here's what's going to happen: law enforcement officers at every level are mining this data right now for unsavory searches. When they find a pattern of worrisome searches -- user 2150654 seems very interested in how to make meth -- they'll search for clues to the identities of these searchers. If they can't find a person's identities in the search logs, they'll pursue a subpoena to make AOL cough up the screen name. In many cases, this will lead to arrests and probably successful prosecutions. And then watch law enforcement at all levels demand the ability to fish through search logs indiscriminately anytime they want. /rich ------------------------------------- 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] AOL search logs: law enforcement implications
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [cryptography] "Combined" cipher modes
by coderman 06 Jul '18

06 Jul '18

On Tue, Apr 3, 2012 at 12:02 PM, Wyss, Felix <Felix.Wyss(a)inin.com> wrote: >... > Maybe being conservative is warranted: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fergu… don't use GCM wrong? short tags are bad. changing tag lengths are bad. use 128bit tags. reminds me of CTR mode arguments... _______________________________________________ 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

AOL search logs: law enforcement implications
by Richard Wiggins 06 Jul '18

06 Jul '18

Dave, For IP if you wish: Imagine how law enforcement at all levels is reacting to the AOL search log exposure. Now there is a searchable database of the search logs: See http://www.aolsearchdatabase. You can quickly locate people who may be planning crimes. We find, for instance, 43,206 people searched for "child porn." Now, do a new search, filtering only by a user number. You'll see all the searches that person did over a three month period. Here's what's going to happen: law enforcement officers at every level are mining this data right now for unsavory searches. When they find a pattern of worrisome searches -- user 2150654 seems very interested in how to make meth -- they'll search for clues to the identities of these searchers. If they can't find a person's identities in the search logs, they'll pursue a subpoena to make AOL cough up the screen name. In many cases, this will lead to arrests and probably successful prosecutions. And then watch law enforcement at all levels demand the ability to fish through search logs indiscriminately anytime they want. /rich ------------------------------------- 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] AOL search logs: law enforcement implications
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [cryptography] "Combined" cipher modes
by coderman 06 Jul '18

06 Jul '18

On Tue, Apr 3, 2012 at 12:02 PM, Wyss, Felix <Felix.Wyss(a)inin.com> wrote: >... > Maybe being conservative is warranted: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fergu… don't use GCM wrong? short tags are bad. changing tag lengths are bad. use 128bit tags. reminds me of CTR mode arguments... _______________________________________________ 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

Re: [liberationtech] Efficient digital one-way communication
by Jens Christian Hillerup 06 Jul '18

06 Jul '18

On Mon, Mar 4, 2013 at 4:40 PM, Michael Rogers <michael(a)briarproject.org> wrote: > Last year I spent some time playing with audio encoding of data for > transmission over handheld radios. The state of the art here is dialup > modems - on a good day they can get 56,000 bits per second over a > channel designed for voice, but that requires advanced modulation and > error correction techniques. The radio hams have packet radio (AX.25 > and APRS) running at 1,200-9,600 bps over long distances using simple > modulation and no error correction. Some early home computers used > audio cassettes for storage (300-1,200 bps, CUTS or Kansas City Standard). Nice information, thanks. Would it be wrong to assume larger data rates to be attainable on an FM "link" than over the telephone line? For music etc. FM has far superior sound quality in any case. > If you want to support purely one-way communication (no acks), you'll > need to forward error correct the data. Hamming codes and parity > checks are simple to implement but they'll eat a lot of your > bandwidth; Reed-Solomon codes are more bandwidth-efficient but also > more complex. Yes, I thought of that too in September. Luckily I've taken courses in abstract algebra and error-correcting codes at my university; I think I'd be able to write a working RS implementation from my theory books. Another thing I didn't tell in my first mail is that I've been wanting to design a protocol for metadata, too, since it doesn't really make sense to decode and save half files anyway. It would also make it possible to send the file names and file sizes beforehand so the receiver can know how much of the file s/he has already received. And yes, I want this to be truly one-way -- no acks. The idea is that I want the receiving end to need as little hardware as possible: one FM radio and one computer with a sound card (and this software). The sender obviously has access to an FM transmitter (or whatever becomes the sound carrier). This modulation algorithm should not provide authenticity of the sender, instead cryptographic signing of the data should happen at higher levels of the stack. > Some Java code for modulation, framing and error correction is here if > you're interested: > > http://briar.git.sf.net/git/gitweb.cgi?p=briar/sandpit;a=tree;f=src/net/sf/… > http://briar.git.sf.net/git/gitweb.cgi?p=briar/sandpit;a=tree;f=src/net/sf/… Thanks a lot! I'll have a look at it soon. JC -- 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

[liberationtech] 'Internet in a Suitcase' ready for field testing
by Joel Harding 06 Jul '18

06 Jul '18

'Internet in a Suitcase' ready for field testing Posted By John Reed Monday, November 5, 2012 - 6:38 PM http://killerapps.foreignpolicy.com/posts/2012/11/05/internet_in_a_suitcase… When will rebels, dissidents, and activists be able to safely voice dissent and coordinate their activities online in the face of a government equipped with Western technology designed to snoop on all types of electronic communications? Maybe in as little as a year, according to Sascha Meinrath of the New America Foundation's Open Technology Institute, the man leading the effort to field the so-called Internet in a Suitcase. Internet in a Suitcase is basically a software program aimed at giving people in conflict or disaster zones the ability to establish a secure, independent wireless network over their computers and cell phones. While the system (which, despite its name, involves neither hardware nor a suitcase) is being tested and is usable right now, Meinrath and his team of developers around the globe are holding off on releasing it to groups like the Syrian rebels until they are confident that it can resist large-scale hacking by governments. What "we're now working on is the due diligence and doing an international deployment, not in the world's hot spots but rather in a post-conflict sort of area, maybe a Libya or an Egypt or another location where the benefits would be very great, but the risk to users in case, say, one of the authentication systems or part of the security mechanisms failed, would not be great," said Meinrath during a Nov. 2 interview with Killer Apps. This will allow the system to be used in the wild and expose any potential weaknesses without exposing users to the wrath of a state security agency. "Once we [feel] comfortable that the system [is] decently secure, then and only then would we be looking at deploying it to one of the world's hot spots; so a Syria or a North Korea or a China, or a Tehran kind of scenario, that kind of work, and that's probably still a year out from now, "said Meinrath. "Our focus first and foremost is, do no harm." This means that in the not-too-distant future, rebels, dissident groups, and even disaster workers will be able to use the secure wireless network designed to resist government eavesdropping. Internet in a Suitcase received a lot of attention earlier this year when it was listed as one of several U.S. government funded projects aimed at providing wireless communications networks for people in conflict zones or places rife with government monitoring of the Internet. "It's a series of software packages that can run on things like laptops or cell phones, whatever devices happen to be available on the ground -- wifi routers, whatever -- and allows them to communicate directly and securely," said Meinrath. "Instead of having to go through existing infrastructure" that could be downed by a disaster or monitored by a government "you can create alternate infrastructure." Downloading the project's software would let a rebel or activist use their cell phone or laptop to communicate directly to other users' machines via the devices' wifi chips. Since these ad hoc wifi networks feature no central control system or administrator, they are much more difficult to monitor, according to Meinrath. "This is a completely ad hoc network, there's no dependency of any device on any other device and that eliminates a central point for command and control surveillance and monitoring," said Meinrath. "We also have authentication between each hop on the network and encryption across each hop." Basically, data being transmitted is passed through a number of different machines on a network before it reaches its destination. Each of those machines asks the data for information saying that it is trustworthy. Each time the data moves, it is encrypted at multiple levels to protect against someone eavesdropping on the airwaves over which the data moves. This type of encryption is important since "we assume that a malfeasant power would be able to compromise [a device on the network] or put up their own node into a network of this sort, " said Meinrath. These mini Internets -- that, in some places where they already exist span entire metro regions -- can host a number of locally developed apps that can do everything from video and audio file sharing to tracking where vehicles and people are. "Inside that network, things are incredibly fast, often an order of magnitude faster than most people's Internet connections, and the latency is very low, so you can do all sorts of really interesting big broadband kind of services and applications if they're housed locally" on members' computers, smart phones or even a USB stick, said Meinrath. Even better, all of that connectivity is free since it is completely independent of any Internet or telecomm provider. "The killer app that I talk with a lot of folks about is, if you have a system like this, there's no reason you would ever need to pay for local phone calls again" once you've downloaded the software allowing your device to join the wifi network, "because you're just pinging machine to machine over a local network," said Meinrath. Joel Harding Information Operations Holistic Organizer (IOHO) http://toinformistoinfluence.com (703) 362-8582 -- Unsubscribe, change to digest, or change password 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

Re: [liberationtech] Bitcoin and The Public Function of Money
by Gregory Maxwell 06 Jul '18

06 Jul '18

On Tue, Oct 30, 2012 at 9:51 PM, StealthMonger <StealthMonger(a)nym.mixmin.net> wrote: > Yes, Bitcoin liberates trade from "public" extortion ("taxation"). It does no such thing. Under US law, for example, Barter in Bitcoins is just as taxable as bartering with coal or cows and share many similar properties (also with cash). Adding 'bit' to the name of something doesn't somehow make it magically invisible to authorities. I'm happy that Bitcoin is interesting technology that inspires fascinating political and technical discussions from people with all kinds of backgrounds and political persuasions. At the same time I'm disappointed (I used to be shocked, but that has long since worn off) by the callousb and I believe very short sighted and non-pragmaticb politics of a vocal few promote. This advocacy of dog-eat-dog and everyman as his own militia as an ultimate ideal is not a phenomena unique to Bitcoin. Many Bitcoin users I know are kind and thoughtful people and all of the developers I know are. The fact that people with vastly different views can find the system compelling is just one of its attractions and challenges. Dmytri's views don't sound incompatible with mine. I just wanted to speak up so that people wouldn't reject considering Bitcoin for something off-hand because they, like I, find StealthMonger's politics distasteful. Tying it back to the list topic. There are some interesting challenges int the context of anonymity systems 9in particular) which I think that Bitcoin, and technologies from its ecosystem, can contribute to improving. Generally preventing denial of service from resource starvation or spam is frustrated when participants are anonymous. Expensive pseudonymity can help, but making those pseudonyms expensive can be tricky (especially as computers will eventually better than humans at captha solving, already I find I have to retry stronger captchas myself several times). If Bitcoin becomes widely used then it can be an option for making pseudonyms costly in a way which may be more anonymous and equal in access than other options. (and of course, making a pseudonym _cost_ no matter in what form disenfranchises people who are poorer; which is unfortunate. Socially prudent technology uses that kind of measure as a last resort and in the least impacting form. I'm personally not a fan of web-of-trust systemsb they're strongly anti-privacy and second-order or higher trust must have complicated heuristics to avoid abuse which I fear may result in kafkaesque outcomes. It may be unjust to allow money to govern our actions, but it can be more just than the deranged correlations of a bayesian classifier.) Another point here is that Bitcoin is more than a simple 1:1 value transfer system. Bitcoins can be specified with complex rules for the criteria under which they can be redeemed. For example, I can write a transaction which can be redeemed by anyone publishing a first-preimage of a specified hash; or only according to a quorum of signers. These kinds of zero or low trust mechanismsb especially when coupled with other not yet existing infrastructureb can potentially restore the freedom to safely make transactions for people in places where the traditional methods of contract enforcement are dysfunctional or are unavailable for political or privacy reasons; or can simply be used to make strong enforcement available when it otherwise would be too expensive. From a liberty perspective I think that strongly cheat proof/resistant systems are generally preferable to post-hoc enforcementb its better to build systems that cant be cheated than to have the costs and risks of enforcement and fails for people who do cheat. Bitcoin provides underling infrastructure for building these such systems when they depend on the transferring value. So I hope that thoughtful technology people continue thinking of Bitcoin as a potential tool, and just ignore the politics of other people who like Bitcoin for different (and sometime misguided) reasons. -- Unsubscribe, change to digest, or change password 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

[tahoe-dev] notes from the Tahoe-LAFS Weekly Dev Call, 2012-09-11
by Zooko Wilcox-O'Hearn 06 Jul '18

06 Jul '18

Folks: As usual, I'm not taking the time to contextualize and vet all these notes. Caveat lector! Also, I've maintained my tradition of adding some of my own thoughts that weren't actually expressed out loud in the discussion. (In particular the advocacy for adding padding and the ideas about how to do so.) in attendance: Brian, David-Sarah, Andrew, Zooko (scribe) b" topic: The compression attack on HTTPS. (Not really relevant to Tahoe-LAFS, but interesting.) Brian says one possible defense against this is to move your secrets from cookies to the URL. This makes the attack impossible unless your secrets are sharing a compression context with the attack. Does anyone actually use TLS compression? Is it turned off by default? Does anyone configure it on? A similar attack is possible on HTTP encryption, if the higher-layer protocol includes attacker-controlled data in the payload. This would be relevant to Tahoe-LAFS if we added compression. However, even if we added compression, we would never mix attacker-controlled data with attacker-unknown data in the same file. However, a higher-layer protocol might mix them. One caveat: convergent encryption could allow compression between attacker-controlled and attacker-unknown data! In fact, there is a deep connection between the adaptive-chosen-plaintext-compression- violates-confidentiality ("CRIME") attack and the drewp "learn the remaining information" attack! The drewp defense -- the Added Convergence Secret -- is exactly the thing that creates independent compression contexts in order to limit the scope for attack. Zooko and (perhaps to a lesser degree) Brian are uncomfortable with the fact that LAFS currently exposes the length of your plaintext, to the byte level of precision. Zooko wants to add padding. That would probably help against the convergent-encryption-based CRIME attack which currently exists in hazy nascent form in Zooko's mind. Also, it enhances general privacy, for example an attacker might be able to recognize what files you are storing and reading just from the lengths of the files. Padding could help against that. Padding out to fixed boundary (e.g. to the next 16 bytes, or to the next 4096 bytes, or whatever) helps but the information can still leak if there are a number of files. For example, suppose you're browsing or downloading a directory containing hundreds of files of varying lengths. The attacker knows the lengths of some files that he suspects you might be browsing. Even if the ciphertext is padded out to fixed sizes, thus "coarsening" or discretizing the information, he might still be able to recognize the pattern. A better defense is to add a random amount of padding, where the random amount is determined by the (possibly convergently generated) encryption key. b" topic: engineering tools and practices We talked about usage of git. David-Sarah likes git-gui. Andrew asked if he should rebase patches when submitting pull requests and Brian said yes. Brian said always first rebase -- bring everything up to trunk -- and then rerecord it as a set of logical commits. It is not necessary to squash it all down into a single commit, unless that's what makes sense. Definitely squash out ephemeral stuff like "Oops, made a typo, oops test didn't pass, let me go back and fix that.". It often makes sense to make four patches: First refactor the code so that there is no actual functional changes, second cosmetic changes like whitespace, third update the unit tests, fourth the new code. Ideally, the revision history tells a story. b" topic: When do we kill off darcs? David-Sarah still has some patches that need to be darcs pushed. But they could diff-and-patch those to git. At some point soon we'll all agree to stop pushing patches into darcs. LeastAuthority.com's Cloud Backend is currently in darcs. We are scheduled to merge the cloud backend to trunk within three weeks. There is still the question of how to handle hyperlinks into https://tahoe-lafs.org that point at darcs patches and history. b" topic: Will Cloud Backend, leasedb, and accounting go into Tahoe-LAFS v1.11? _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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