- cypherpunks - lists.cpunks.org

Mailtap
by Rich Jones 21 Sep '13

21 Sep '13

Did a quick little write-up about the USPS response to my MICT FOIA, thought you might be interested. Thanks to Cryptome for posting the LEO spy forms orignally! https://openwatch.net/i/248/mailtap-usps-documents-expose-how-local-police-a Can anybody spot me $500,000? ————————————— Rich Jones * OpenWatch <https://openwatch.net>* is a global citizen news network. Download OpenWatch for iOS<https://itunes.apple.com/us/app/openwatch-social-muckraking/id642680756?ls=…>and for Android<https://play.google.com/store/apps/details?id=org.ale.openwatch&hl=en> !

4 3

Fw: [Cryptography] FISA court releases its "Primary Order" re telephone metadata
by Jim Bell 20 Sep '13

20 Sep '13

>From: Eugen Leitl <eugen(a)leitl.org> >To: cypherpunks(a)al-qaeda.net; info(a)postbiota.org; zs-p2p(a)zerostate.is >Sent: Friday, September 20, 2013 5:10 AM >Subject: [Cryptography] FISA court releases its "Primary Order" re telephone metadata >----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- >Date: Tue, 17 Sep 2013 18:02:27 -0700 >From: John Gilmore <gnu(a)toad.com> >To: cryptography(a)metzdowd.com, gnu(a)toad.com >Subject: [Cryptography] FISA court releases its "Primary Order" re telephone metadata >The FISA court has a web site (newly, this year): > http://www.uscourts.gov/uscourts/courts/fisc/index.html >Today they released a "Memorandum Opinion and Primary Order" in >case BR 13-109 ("Business Records, 2013, case 109"), which lays >out the legal reasoning behind ordering several telephone companies >to prospectively give NSA the calling records of every subscriber. >That document is here: > http://www.uscourts.gov/uscourts/courts/fisc/br13-09-primary-order.pdf >I am still reading it... > John Armed with my nearly 12 years of daily visits to prison law libraries, I can report that this "Memorandum Opinion and Primary Order" contains many legal errors and false representations and assumptions, and indeed the facts have changed mightily since the issuance of the 1979 "Smith v. Maryland" Supreme Court decision that supported the use of 'pen registers', which provided (only) the phone number called by a given telephone line. One is that in 1979, there was only one phone company, or at least one per geographic area, that fact having been changed by the 1983 breakup of the telephone monopoly by Judge Green. The assumption can no longer be made that modern telephone companies WANT to share metadata with the government; prior to 1979 it would have been virtually assumed that they were willing to so share. The Smith case, above, merely supported the practice of a phone company voluntarily giving information to the government, without the government obtaining a warrant: It didn't require that these phone companies share that information without a warrant. Today, a company may simply be unwilling to share that data, or can be convinced to declare that unwillingness now (after the Snowden/NSA revelations) and the public can be expected to want its chosen phone companies to refuse. Another difference (or reality) is that these warrants refer repeatedly to 'business records': Ostensibly, because this metadata is a 'business record', somehow the phone co. can be expected to provide it. While there may not have been any reason for phone companies to keep telephone calling records ('metadata') in 1979, there is certainly no need for such records today. In 1979, long-distance telephone calls were billed by time, and by distance to the called party, and they generally kept the full phone number as part of the record.. Today, it is common to have unlimited LD contracts, which disregard the distance of the call or its duration, or both, at least within the US, making it entirely unnecessary for the phone company to keep records on calls. (Or, simply the duration of a phone call could be recorded, if the total time is billed.) In principle, therefore, a phone company could announce that it was ceasing keeping such metadata, as a matter of business records. Or, it could keep metadata, and X-out the last four digits of all called-telephone numbers, making those records virtually useless for any large-scale investigational use. Yet another way for a phone co. to fight back would be to provide that metadata to the government, printed out on paper, in tiny "captcha"-type font, or perhaps in some kind of pseudo-randomized cursive font, so that it would be readable, yet it would also be virtually impossible for the government to return that information to an electronically-accessible font. Sure, that tactic might result in yet another court-order, but that will amount to a further reason to challenge that court: "The government is getting the information it requested, it may simply not be getting it in the form it wants." Another attack is suggested by both the Smith case and this primary order url'ed above: The assertion that there is no 'expectation of privacy' in phone numbers given by the user to the phone company(ies). This could be challenged simply if the phone co's declared to its customers, "We will keep your telephone metadata secret except if given a warrant providing individualized suspicion against you: A general warrant asking for all telephone metadata will not be honored and in fact will be publicized by means of leak or otherwise. Further, we will no longer retain the last four digits of numbers you call, in your records, or the last four digits of your telephone number, in records of calls to you." At that point, the 'expectation of privacy' declared non-existent by the 1979 Smith decision will return. Jim Bell

1 0

Linus Torvalds admits he was asked to insert a backdoor into GNU/Linux
by CypherPunk 20 Sep '13

20 Sep '13

This shouldn't really surprise anyone. Of course they'd at least give it a try. http://www.eweek.com/developer/linus-torvalds-talks-linux-development-at-li…

7 7

Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Wed, 18 Sep 2013 11:05:46 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] PRISM-Proofing and PRISM-Hardening User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 17/09/13 23:52 PM, John Kemp wrote: > On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker <hallam(a)gmail.com >> I am sure there are other ways to increase the work factor. > > I think that "increasing the work factor" would often result in > switching the kind of "work" performed to that which is easier than > breaking secrets directly. Yes, that's the logical consequence & approach to managing risks. Mitigate the attack, to push attention to easier and less costly attacks, and then start working on those. There is a mindset in cryptography circles that we eliminate entirely the attacks we can, and ignore the rest. This is unfortunately not how the real world works. Most of risk management outside cryptography is about reducing risks not eliminating them, and managing the interplay between those reduced risks. Most unfortunate, because it leads cryptographers to strange recommendations. > That may be good. Or it may not. If other attacks are more costly to defender and easyish for the attacker, then perhaps it is bad. But it isn't really a common approach in our security world to leave open the easiest attack, as the best alternative. Granted, this approach is used elsewhere (in warfare for example, minefields and wire will be laid to channel the attack). If we can push an attacker from mass passive surveillance to targetted direct attacks, that is a huge win. The former scales, the latter does not. > "PRISM-Hardening" seems like a blunt instrument, or at least one which > may only be considered worthwhile in a particular context (technical > protection) and which ignores the wider context (in which such technical > protections alone are insufficient against this particular adversary). If I understand it correctly, PRISM is or has become the byword for the NSA's vacuuming of all traffic for mass passive surveillance. In which case, this is the first attack of all, and the most damaging, because it is undetectable, connects you to all your contacts, and stores all your open documents. From the position of a systems provider, mass surveillance is possibly the most important attack to mitigate. This is because: we know it is done to everyone, and therefore it is done to our users, and it informs every other attack. For all the other targetted and active attacks, we have far less certainty about the targetting (user) and the vulnerability (platform, etc). And they are very costly, by several orders of magnitude more than mass surveillance. iang _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] The paranoid approach to crypto-plumbing
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from John Kelsey <crypto.jmk(a)gmail.com> ----- Date: Wed, 18 Sep 2013 00:42:47 -0400 From: John Kelsey <crypto.jmk(a)gmail.com> To: Sandy Harris <sandyinchina(a)gmail.com> Cc: Cryptography <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] The paranoid approach to crypto-plumbing X-Mailer: iPad Mail (10B329) For hash functions, MACs, and signature schemes, simply concatenating hashes/MACs/signatures gives you at least the security of the stronger one. Joux multicollisions simply tell us that concatenating two or more hashes of the same size doesn't improve their resistance to brute force collsion search much. The only thing you have to be sure of there is that the MAC and signature functions aren't allowed access to each others' secret keys or internal random numbers. Otherwise, MAC#1 can always take the value of MAC#2's key. This is just message, signature 1, signature 2 where the signatures are over the message only. For encryption algorithms, superencryption works fine. You can first encrypt with AES-CBC, then encrypt with Twofish-CFB, then with CAST5 in CFB mode. Again, assuming you are not letting the algorithms know each others' internal state or keys, if any of these algorithms are resistant to chosen plaintext attacks, then the combination will be. This doesn't guarantee that the combination will be any stronger than the strongest of these, but it will be no weaker. (Biham and later Wagner had some clever attacks against some chaining modes using single-DES that showed that you wouldn't always get anything stronger than one of the ciphers, but if any of these layers is strong, then the whole encryption is strong. An alternative approach is to construct a single super-block-cipher, say AES*Twofish*SERPENT, and use it in a standard chaining mode. However, then you are still vulnerable to problems with your chaining mode--the CBC reaction attacks could still defeat a system that used AES*Twofish*SERPENT in CBC mode, but not AES-CBC followed by Twofish-CFB followed by SERPENT-CTR. For key-encryption or transport, I think it's a little more complicated. If I need six symmetric keys and want to use three public key methods (say ECDH, NTRU, RSA) to transport the key, I've got to figure out a way to get the benefit from all these key exchange mechanisms to all six symmetric keys, in a way that I'm sure will not leak any information about any of them. Normally we would use a KDF for this, but we don't want to trust any one crypto algorithm not to screw us over. I think we can get this if we assume that we can have multiple KDFs that have secrets from one another. That is, I compute KDF1( key1, combined key exchange input) XOR KDF2( key2, combined key exchange input) The reason the two KDFs need keys that are secret from each other is because otherwise, KDF1 could just duplicate KDF2 and we'd get an all-zero set of keys. If KDF2 is strong, then KDF1 can't generate an output string with any relationship to KDF2's string when it doesn't know all the input KDF2 is getting. I agree with Perry that this is probably padlocking a screen door. On the other hand, if we want to do it, we want to make sure we guard against as many bad things as possible. In particular, it would be easy to do this in such a way that we missed chaining mode/reaction type attacks. --John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[Cryptography] FISA court releases its "Primary Order" re telephone metadata
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Tue, 17 Sep 2013 18:02:27 -0700 From: John Gilmore <gnu(a)toad.com> To: cryptography(a)metzdowd.com, gnu(a)toad.com Subject: [Cryptography] FISA court releases its "Primary Order" re telephone metadata The FISA court has a web site (newly, this year): http://www.uscourts.gov/uscourts/courts/fisc/index.html Today they released a "Memorandum Opinion and Primary Order" in case BR 13-109 ("Business Records, 2013, case 109"), which lays out the legal reasoning behind ordering several telephone companies to prospectively give NSA the calling records of every subscriber. That document is here: http://www.uscourts.gov/uscourts/courts/fisc/br13-09-primary-order.pdf I am still reading it... John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [coreboot] [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from Patrick Georgi <patrick(a)georgi-clan.de> ----- Date: Fri, 20 Sep 2013 13:49:49 +0200 From: Patrick Georgi <patrick(a)georgi-clan.de> To: coreboot(a)coreboot.org Subject: Re: [coreboot] [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption User-Agent: Roundcube Webmail/0.9.2 Am 2013-09-20 11:51, schrieb Eugen Leitl: > The Intel Atom-based MinnowBoard is a new UEFI dev platform, and it's > Linux-based, and targets hackers; it uses Intel's definition of "Open > Hardware", mainly meaning no NDAs involved. It is much cheaper and > smaller than the above box. > http://minnowboard.org/ > http://uefidk.intel.com/content/minnowboard-uefi-firmware To wit, its download page is guarded by a long, non-free EULA: http://uefidk.intel.com/content/minnowboard-uefi-firmware-eula Some of the components also seem to be binary-only. > Both of these boxes let you reflash your system firmware with your > custom build of BSD-licensed TianoCore UEFI. BSD-licensed TianoCore + heaps of binary modules that are currently only available under NDA. They'd also require some additional code (probably binary only?) to make Tiano resembling something like a complete and secure implementation. > <soapbox> > There is a large OEM/ODM/IBV/IHV/ISV ecosystem that currently runs the > hardware, and it is UEFI-centric. IMO, focusing only on fringe > Lemote/Coreboot technology is not a good bet. coreboot is your only bet on x86 if you aim for open source firmware. It can be combined with TianoCore to provide the UEFI APIs to the user (read: Operating System), but TianoCore alone won't do since it lacks hardware initialization drivers (that coreboot provides). > Personally, I wish EFF/FSF and other open/free tech groups would form > a Linaro-like firmware group and produce their own UEFI firmware > image, as an option for OEMs. Personally, I wish people wouldn't wish for someone else to start groups, but do it themselves for a change. However that brings the risk of seeing that things aren't quite as simple and might ultimately fail. Of course, soapboxes and arm chairs are much more comfortable and comparably risk-free. > There needs to be some Free Boot alternative to Secure Boot, with > certs from EFF/FSF/etc and the open source distro vendors, not just > OEMs/MSFT in the firmware, and it needs to target booting from a > handful of main open source distros, not just 1 commercial OS. Else, > UEFI will turn Personal Computers into Windows PCs, ending the era of > General Purpose computing. "main open source distros" is not enough since it creates a gatekeeper model. "Secure Boot" (which is really a Verified Boot) without physical user override doesn't cut it. ChromeBooks, using coreboot, provide a mostly* Open Source Verified Boot model with physical user override (with two override modes: safe via dev mode switch, and complete via jumper). * (blame Intel) tl;dr: Comparing coreboot, Lemote, UEFI and Tianocore isn't as easy as people seem to believe. Regards, Patrick -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [liberationtech] Random number generation being influenced - rumors
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from Maxim Kammerer <mk(a)dee.su> ----- Date: Fri, 20 Sep 2013 10:56:45 +0300 From: Maxim Kammerer <mk(a)dee.su> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Random number generation being influenced - rumors Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Sat, Sep 7, 2013 at 6:21 PM, Maxim Kammerer <mk(a)dee.su> wrote: > Personally, I wouldn't trust an embedded engineer to > implement bubble sort correctly, and see no reason to trust them with > security-critical implementations, even if one assumes no malice or > subversion of production process. By the way, that Android PRNG fiasco? Intel's job, originally. Meet Yuri: https://issues.apache.org/jira/browse/HARMONY-872 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] A lot to learn from "Business Records FISA NSA Review"
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from Ray Dillinger <bear(a)sonic.net> ----- Date: Thu, 19 Sep 2013 10:02:35 -0700 From: Ray Dillinger <bear(a)sonic.net> To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] A lot to learn from "Business Records FISA NSA Review" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130828 Icedove/17.0.8 On 09/16/2013 07:58 AM, Perry E. Metzger wrote: > Well, we do know they created things like the (not very usable) > seLinux MAC (Multilevel Access Control) system, so clearly they do > some hacking on security infrastructure. SeLinux seems to be targeted mostly at organizational security, whereas the primary need these days is not organizational, but uniform. That is to say, we don't in practice see many situations where different levels and departments of an organization have complex and different rules for how and whether they can access each other's information and complex requirements for audit trails. What we see is simpler; we see systems used by people who have more or less uniform requirements and don't much need routine auditing, except for one or two administrators. More useful than the complexity of SeLinux would be a relatively simple system in which ordinary Unix file permissions were cryptographically enforced. If for example read permissions on a file are exclusive to some user or some group, then that file should be encrypted so that no one else, even if the bytes are accessible to them by some means, should be able to make sense of it, and the configuration options should include not storing the key to it anywhere in the system -- let the user plug a USB stick in to give the key for his session, and let the user remove it to take that key away again whenever he's not using it, rather than leave it around on the hard drive somewhere potentially to be accessed by someone else at some other time. We have spent years learning to protect the operating system from damage by casual mistakes and even from most actual attacks, because for years control of the computer itself was the only notable asset that needed to be protected. It is still true that control of the computer is always at least as valuable as everything else that it could be used to compromise, but with unencrypted files it can compromise far too much. And the value of what is stored in individual accounts has gotten far too high to *NOT* give protecting them at least as much thought as protecting root's access rights. Photographs, banking records, schedules, archived mail going back for years, browser histories, "wallets" that contain many other keys, etc, etc. This is far different from old days when what was on a user's account was basically a few programs the user used and some text or code that the user had written. We need to catch up. Bear _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[Cryptography] prism proof email, namespaces, and anonymity
by Eugen Leitl 20 Sep '13

20 Sep '13

----- Forwarded message from John Kelsey <crypto.jmk(a)gmail.com> ----- Date: Fri, 13 Sep 2013 16:55:05 -0400 From: John Kelsey <crypto.jmk(a)gmail.com> To: "cryptography(a)metzdowd.com List" <cryptography(a)metzdowd.com> Subject: [Cryptography] prism proof email, namespaces, and anonymity X-Mailer: iPad Mail (10B329) Everyone, The more I think about it, the more important it seems that any anonymous email like communications system *not* include people who don't want to be part of it, and have lots of defenses to prevent its anonymous communications from becoming a nightmare for its participants. If the goal is to make PRISM stop working and make the email part of the internet go dark for spies (which definitely includes a lot more than just US spies!), then this system has to be something that lots of people will want to use. There should be multiple defenses against spam and phishing and other nasty things being sent in this system, with enough designed-in flexibility to deal with changes in attacker behavior over tome. If someone can send participants in the system endless spam or credible death threats, then few people are going to want to participate, and that diminishes the privacy of everyone remaining in the system, along with just making the system a blight in general. If nonparticipants start getting spam from the system, it will either be shunned or shut down, and at any rate won't have the kind of reputation that will move a lot of people onto the system. An ironclad anonymous email system with 10,000 users is a whole lot less privacy-preserving than one with 10,000,000 users. As revelations of more and more eavesdropping come out, we might actually see millions of users want to have something really secure and anonymous, but not if it's widely seen as a firehose o' spam. A lot of the tools we use on the net everyday suffer from having been designed without thinking very far ahead into how they might be exploited or misused--hence spam, malware in PDF files, browser hijacking sorts of attacks, etc. My thought is that we should be thinking of multiple independent defenses against spamming and malware and all the rest, because parasites adapt to their environment. We can't count on "and then you go to jail" as a final step in any protocol, and we can't count on having some friendly utility read millions of peoples' mail to filter the spam if we want this to be secure. So what can we count on to stop spam and malware and other nastiness? Some thoughts off the top of my head. Note that while I think all these can be done with crypto somehow, I am not thinking of how to do them yet, except in very general terms. a. You can't freely send messages to me unless you're on my whitelist. b. This means an additional step of sending me a request to be added to your whitelist. This needs to be costly in something the sender cares about--money, processing power, reputation, solving a captcha, rate-limits to these requests, whatever. (What if the system somehow limited you to only, say, five outstanding requests at a time?). c. Make account creation costly somehow (processing, money, solving a captcha, whatever). Or maybe make creating a receive-only account cheap but make it costly to have an account that can request to communicate with strangers. d. Make sending a message in general cost something. Let receiver addresses indicate what proof of payment of the desired cost they require to accept emails. e. Enable some kind of reputation tracking for senders? I'm not sure if this would work or be a good idea, but it's worth thinking about. f. All this needs to be made flexible, so that as attackers evolve, so can defenses. Ideally, my ppe (prism proof email) address would carry an indication of what proofs your request to communicate needed to carry in order for me to consider it. g. The format of messages needs to be restricted to block malware, both the kind that wants to take over your machine and the kind that wants to help the attacker track you down. Plain text email only? Some richer format to allow foreign language support? h. Attachments should become links to files in an anonymizing cloud storage system. Among other things, this will make it easier to limit the size of the emails in the system, which is important for ensuring anonymity without breaking stuff. What else? I see this as the defining thing that can kill an anonymous encrypted communications system--it can become a swamp of spam and malware and nutcases stalking people, and then nobody sensible will want to come within a hundred meters of it. Alternatively, if users are *more* in control of who contacts them in the prism-proof scheme than with the current kind of email, we can get a lot more people joining. Comments? --John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2