September 2013 - cypherpunks - lists.cpunks.org

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

21 Sep '13

----- Forwarded message from John Sullivan <johns(a)fsf.org> ----- Date: Fri, 20 Sep 2013 15:04:14 -0400 From: John Sullivan <johns(a)fsf.org> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Blibbet <blibbet(a)gmail.com> writes: >> (We call the bad version of Secure Boot, where the user does not have >> the ability to modify the set of trusted keys or disable the system, >> Restricted Boot.) >> >> We have discussed the idea of trying to become a root key holder for >> Secure Boot, working with OEMs to by default trust GNU/Linux distro keys >> signed by us, but have been told that the cost of complying with the >> requirements would be in the millions. We're still interested, if anyone >> has funding. > > Can you please point to the source of this "millions" comment? I see > UEFI Forum membership as being $2500/yr max for an org, and free for > an individual. The latter can't influence codebase and has a 3 page > license, the former can impact codebase and has a 9 page license. > http://www.uefi.org/join > Those are the costs for being just a member of UEFI -- what you were suggesting originally was being a root key holder, able to sign developer keys which can then be used to sign operating systems to boot under Secure Boot equipped firmwares that ship recognizing that root key. This would be nice, because then people wouldn't be so dependent on Microsoft's Certificate Authority. But, this comes with the kinds of costs you might expect from a secure operation to keep certs safe -- insurance, audits, running the process of signing developer keys, etc. I don't know where all of the costs come from but I can see how they build up quickly. > So, has FSF looked at working with an IBV or a PC OEM, about doing a > proper UEFI-based system with a proper Secure Boot feature that works > with Linux? > Some -- resources for all of this are an issue. Also depends if by "proper" you mean that it comes enabled and preloaded with trusted keys, in which case see above. >> In the meantime, we would love to receive any reports of x86 systems >> purchased with Secure Boot that actually have Restricted Boot. > > BTW, here's latest status from Intel UEFI w/r/t Linux, a talk from > last week's IDF: > > http://uefi.blogspot.com/2013/09/uefi-at-idf13-part-2-uefi-secure-boot.html > > The speaker of that talk will be at a UEFI training event at a local > hackerspace, answering questions on UEFI. If anyone has some good > questions to ask him, I'll be happy to relay. One thing that would make this whole mess better would be if drivers could effectively be signed by more than one key. That would help lessen some of the dependency on Microsoft, because drivers could be signed by smaller party keys without having to drop Microsoft. I think this is allowed for by policy and signing format but is not being implemented. -john -- John Sullivan | Executive Director, Free Software Foundation GPG Key: 61A0963B | http://status.fsf.org/johns | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at <http://www.fsf.org/register_form?referrer=8096>. -- 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

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