Re: [Cryptography] Johns Hopkins round table on NSA and Crypto
* Perry E. Metzger schrieb am 2013-09-17 um 23:26 Uhr: > Matthew Green tweeted earlier today that Johns Hopkins will be hosting > a roundtable at 10am EDT tomorrow (Wednesday, September 18th) to > discuss the NSA crypto revelations. > Livestream will be at: https://connect.johnshopkins.edu/jhuisicrypto/ Is there somewhere a recording of this session? -- Jens Kubieziel http://www.kubieziel.de Ich bin nicht auf die Welt gekommen, um das Leben zu genießen, sondern um anderen Menschen Freude zu bereiten. Franz Lehár signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 19 Sep 2013 19:11, "Bill Frantz" wrote: > > On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote: > >>> I know I would be a lot more comfortable with a way to check the mail against a piece of paper I >> >> received directly from my bank. >> >> I would say this puts you in the sub 1% of the populace. Most people want to do things online because it is much easier and "gets rid of paper." Those are the systems we need to secure. Perhaps another way to look at it: how can we make out-of-band verification simpler? > > > Do you have any evidence to support this contention? Remember we're talking about money, not just social networks. > > I can support mine. ;-) > > If organizations like Consumers Union say that you should take that number from the bank paperwork you got when you signed up for an account, or signed up for online banking, or got with your monthly statement, or got as a special security mailing and enter it into your email client, I suspect a reasonable percentage of people would do it. It is, after all a one time operation. As with other themes though, one size does not fit all. The funny thing being that banks are actually extremely adept at doing out of band paper verification. Secure printing is born out of financial transactions, everything from cheques to cash to PIN notification. I think it was Phillip who said that other trust models need to be developed. I'm not as down on the Web of trust as others are but I strongly believe that there has to be an ordered set of priorities. Usability has to be right up there as a near-peer with overall system security. Otherwise as we've seen a real attack in this context is simply to dissuade people to use it and developers, especially of security oriented systems can do that of their own accord. If you want to get your systems users to help with out of band verification get them 'talking' to each other. Perry said that our social networks are great for keeping spam out of our mailboxes yet were busy trying to cut out the technology that's driven all of this. Out of band for your banking might mean security printing techniques and securing your email, phoning your friends. > > Cheers - Bill > > --- > Bill Frantz| If the site is supported by | Periwinkle > (408)356-8506 | ads, you are the product.| 16345 Englewood Ave > www.pwpconsult.com | | Los Gatos, CA 95032 > > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 18 September 2013 21:47, Viktor Dukhovni wrote: > On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote: > > > > This is only realistic with DANE TLSA (certificate usage 2 or 3), > > > and thus will start to be realistic for SMTP next year (provided > > > DNSSEC gets off the ground) with the release of Postfix 2.11, and > > > with luck also a DANE-capable Exim release. > > > > What's wrong with name-constrained intermediates? > > X.509 name constraints (critical extensions in general) typically > don't work. > No. They typically work. As usual, Apple are the fly in the ointment. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On Wed, Sep 18, 2013 at 5:50 PM, Viktor Dukhovni wrote: > On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote: > > > On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote: > > > > > > This is only realistic with DANE TLSA (certificate usage 2 or 3), > > > > and thus will start to be realistic for SMTP next year (provided > > > > DNSSEC gets off the ground) with the release of Postfix 2.11, and > > > > with luck also a DANE-capable Exim release. > > > > > > What's wrong with name-constrained intermediates? > > > > X.509 name constraints (critical extensions in general) typically > > don't work. > > And public CAs don't generally sell intermediate CAs with name > constraints. Rather undercuts their business model. > > This is no longer the case. Best Practice is now considered to be to use name constraints but not mark them critical. This is explicitly a violation of PKIX which insists that a name constraint extension be marked critical. Which makes it impossible to use name constraints as they will break in Safari and a few other browsers. The refusal to make the obvious change is either because people do not understand the meaning of the critical bit or the result of some of that $250 million being felt in the PKIX group. As I pointed out at RSA, the use of name constraints might well have prevented the FLAME attack working. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The Case for Formal Verification
Perry E. Metzger piermont.com> writes: > CompCert is a fine counterexample, a formally verified C compiler: > http://compcert.inria.fr/ > It works by having a formal spec for C, and a formal spec for the > machine language output. The theorem they prove is that the The claim of CompCert being a formally verified C compiler is wildly overstated: http://shape-of-code.coding-guidelines.com/2013/03/10/verified-compilers-and-soap-powder-advertising/ It is a good start, but they still have lots of work to do. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 9/18/13 5:50 PM, "Viktor Dukhovni" wrote: >On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote: > >> On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote: >> >> > > This is only realistic with DANE TLSA (certificate usage 2 or 3), >> > > and thus will start to be realistic for SMTP next year (provided >> > > DNSSEC gets off the ground) with the release of Postfix 2.11, and >> > > with luck also a DANE-capable Exim release. >> > >> > What's wrong with name-constrained intermediates? >> >> X.509 name constraints (critical extensions in general) typically >> don't work. > >And public CAs don't generally sell intermediate CAs with name >constraints. Rather undercuts their business model. The inability to constrain trust anchors doesn't help matters much either. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
Phillip Hallam-Baker writes: >I have not spent a great deal of time looking at the exact capabilities of >PRISM vs the other programs involved because from a design point they are >irrelevant. The objective is to harden/protect the infrastructure from any >ubiquitous, indiscriminate intercept capability like the one Gen Alexander >appears to have constructed. Precisely. I made the same point recently in an interview about PRISM, that a well-designed, well-engineered protocol will be NSA-proof (or at least as NSA- proof as you can get within reason). It'll also be Russian mafia-proof, Chinese-government-proof, and your-mother-proof. There isn't some exotic class of protocol or mechanism that's needed to resist the NSA, anything well- designed and implemented can do it. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote: I know I would be a lot more comfortable with a way to check the mail against a piece of paper I received directly from my bank. I would say this puts you in the sub 1% of the populace. Most people want to do things online because it is much easier and "gets rid of paper." Those are the systems we need to secure. Perhaps another way to look at it: how can we make out-of-band verification simpler? Do you have any evidence to support this contention? Remember we're talking about money, not just social networks. I can support mine. ;-) If organizations like Consumers Union say that you should take that number from the bank paperwork you got when you signed up for an account, or signed up for online banking, or got with your monthly statement, or got as a special security mailing and enter it into your email client, I suspect a reasonable percentage of people would do it. It is, after all a one time operation. Cheers - Bill --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Cryptographic mailto: URI
I am in mid design here but I think I might have something of interest. Let us say I want to send an email to al...@example.com securely. Now obviously (to me anyway) we can't teach more than a small fraction of the net to use any identifier other than the traditional email address. So we need some sort of directory infrastructure to allow discovery of those email addresses and it would be good to be able to reuse existing directories if at all possible. But how do we insert the email addresses into a directory like LinkedIn? Well you can add a URI into your account. So what if the URI is of the form: ppid:al...@example.com:example.net: Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM Where al...@example.com is Alice's email address for secure communications example.net is a server which will resolve the reference by means of a simple HTTP query using the pattern http:///.well-known/ppid/ "Syd...NWM" is the Base64 hash of OID-SHA256 + SHA256(X) X is a public key that signs a document (probably JSON) that specifies: * X * Alice's certificate(s) * Alice's email receipt policy whether to always encrypt, what message formats are supported * links to whatever additional advice information might help convince a relying party the key is genuine like a CT log. * reliance policy (is this key for public use or restricted) * reporting policy (for future changes) So to use this as a mechanism for ghetto key distribution receivers would add the URI into their account. Or let their PKI discovery agent do it for them. Senders would enable their PKI discovery agent to access their LinkedIn account. It would slurp down the data once a day (say) and keep it in a cache for use by that user alone unless it is marked public when any user of the PKI discovery agent can make use of it. It would attempt to validate the information obtained, possibly resulting in a report if it detected a change in a previously registered key that had not been properly countersigned by the old. The validated info would then be used to encrypt the outbound mail according to the specified policy. Notes: 1) This is only about key discovery, not validation. 2) Better to send email encrypted under a key that is not validated than in the clear. 3) A MUA should offer the option 'force encryption' however. And in that case it would barf if the key provided didn't meet the validation criteria. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
Hi John, (I think we are in agreement here, there was just one point below where I didn't make myself clear.) On 18/09/13 23:45 PM, John Kemp wrote: On Sep 18, 2013, at 4:05 AM, ianG wrote: On 17/09/13 23:52 PM, John Kemp wrote: On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker 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. The technical work always needs doing. It's not that we shouldn't do our best to improve cryptographic protection. It's more that one can always bypass cryptographic protection by getting to the cleartext before it is encrypted. Right. So the amount of effort we should put in should not be dictated (solely) by received wisdom about perfect security, but (also) by how quickly we can push the bulk of the attackers elsewhere. Thus releasing our costly resources for 'elsewhere'. I wrote about this tradeoff many moons ago. I called the preferred target Pareto-secure as a counterpoint to the expected 100% secure, which I defined as a point where there is no Pareto-improvement that can be made, because the attacker is already pushed elsewhere. The other side of the coin is to have a gentler attitude to breaches. When a breach is announced, we also need to consider whether anyone has actually lost anything, and whether the ones that weren't attacked have got good service. A protocol is rarely broken for the user, even if the cryptographic world uses the word 'broken' for a few bits. E.g., if one looks at the TLS changes of the last 5 years due to a series of attacks, there isn't much of a record of actual hacks to users. 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. My point was that "mass passive surveillance" is possible with or without breaking SSL/TLS (for example, but also other technical attacks), and that it is often simpler to pay someone to create a backdoor in an otherwise well-secured system. Or to simply pay someone to acquire the data in cleartext form prior to the employment of any technical protections to those data. Other kinds of technical protections (not really discussed here so far) might be employed to protect data from such attacks, but they would still depend on the possibility for an attacker to acquire the cleartext before such protections were applied. To some extent, mass passive surveillance is entirely possible because SSL/TLS is so poorly employed. I haven't looked for a while, but it was always about 1% of web traffic. This is the motive behind HTTPS Everywhere - All The Time. Let's make SSL the norm not the exception. Then we've got some security against passive surveillance, then we force the attacker to other attacks, which are typically much more expensive. I would point out that it was historically the case that the best espionage was achieved by paying (or blackmailing) people close to the source of the information to retrieve the necessary information. The idea of the "mole". That would seem to still be possible. "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. If you yourself the systems provider, or a "bad" employee i
Re: [Cryptography] A lot to learn from "Business Records FISA NSA Review"
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@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
> On Wed, Sep 18, 2013 at 08:47:17PM +, Viktor Dukhovni wrote: > > On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote: > > > > This is only realistic with DANE TLSA (certificate usage 2 or 3), > > > > and thus will start to be realistic for SMTP next year (provided > > > > DNSSEC gets off the ground) with the release of Postfix 2.11, and > > > > with luck also a DANE-capable Exim release. > > > > > > What's wrong with name-constrained intermediates? > > > > X.509 name constraints (critical extensions in general) typically > > don't work. Which is why the CAB Forum and Mozilla made the pragmatic move to promote the use of X.509 name constraints as a non-critical extension. > > And public CAs don't generally sell intermediate CAs with name constraints. > Rather undercuts their business model. > Public CAs are starting to offer name-constrained intermediate CAs to suitable customers. Why wouldn't we? - It doesn't undercut our business model any more than selling a wildcard certificate. > -- > Viktor. Robin Alden Comodo ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
> I know I would be a lot more comfortable with a way to check the mail against > a piece of paper I received directly from my bank. I would say this puts you in the sub 1% of the populace. Most people want to do things online because it is much easier and "gets rid of paper." Those are the systems we need to secure. Perhaps another way to look at it: how can we make out-of-band verification simpler? -- Principal Security Engineer Akamai Technology Cambridge, MA ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] RSA equivalent key length/strength
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Lucky Green wrote: > Moti Young and others wrote a book back in the 90's (or perhaps) > 80's, that detailed the strength of various RSA key lengths over > time. I am too lazy to look up the reference or locate the book on my > bookshelf. Moti: help me out here? :-) Can't help out with that. But I think that the ECRYPY Yearly Reports on keylengths and algorithms are a great source for these kinds of questions. The latest (from 2012) can be found here: http://www.ecrypt.eu.org/documents/D.SPA.20.pdf Unfortunately ECRYPY II has come to an end and I'm not certain the report will be updated anymore. Would be a loss since having updated estimates on keys and what algorithms to use is really helpful (IMHO). - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlI6onIACgkQZoPr8HT30QGuSgCgq31OzxzE5u931sIpY/XMs5Ry dwAAniAkW7jGfLnakNqGnjhhm37vfELm =Iqvv -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On Wed, Sep 18, 2013 at 5:23 PM, Lucky Green wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-09-14 08:53, Peter Fairbrother wrote: > > > I get that 1024 bits is about on the edge, about equivalent to 80 > > bits or a little less, and may be crackable either now or sometime > > soon. > > Moti Young and others wrote a book back in the 90's (or perhaps) 80's, > that detailed the strength of various RSA key lengths over time. I am > too lazy to look up the reference or locate the book on my bookshelf. > Moti: help me out here? :-) > > According to published reports that I saw, NSA/DoD pays $250M (per > year?) to backdoor cryptographic implementations. I have knowledge of > only one such effort. That effort involved DoD/NSA paying $10M to a > leading cryptographic library provider to both implement and set as > the default the obviously backdoored Dual_EC_DRBG as the default RNG. > > This was $10M wasted. While this vendor may have had a dominating > position in the market place before certain patents expired, by the > time DoD/NSA paid the $10M, few customers used that vendor's > cryptographic libraries. > > There is no reason to believe that the $250M per year that I have seen > quoted as used to backdoor commercial cryptographic software is spent > to any meaningful effect. > The most corrosive thing about the whole affair is the distrust it has sewn. I know a lot of ex-NSA folk and none of them has ever once asked me to drop a backdoor. And I have worked very closely with a lot of government agencies. Your model is probably wrong. Rather than going out to a certain crypto vendor and asking them to drop a backdoor, I think they choose the vendor on the basis that they have a disposition to a certain approach and then they point out that given that they have a whole crypto suite based on EC wouldn't it be cool to have an EC based random number generator. I think that the same happens in IETF. I don't think it very likely Randy Bush was bought off by the NSA when he blocked deployment of DNSSEC for ten years by killing OPT-IN. But I suspect that a bunch of folk were whispering in his ear that he needed to be strong and resist what was obviously a blatant attempt at commercial sabotage etc. etc. I certainly think that the NSA is behind the attempt to keep the Internet under US control via ICANN which is to all intents a quango controlled by the US government. For example, ensuring that the US has the ability to impose a digital blockade by dropping a country code TLD out of the root. Right now that is a feeble threat because ICANN would be over in a minute if they tried. But deployment of DNSSEC will give them the power to do that and make it stick (and no, the key share holders cannot override the veto, the shares don't work without the key hardware). A while back I proposed a scheme based on a quorum signing proposal that would give countries like China and Brazil the ability to assure themselves that they were not subjected to the threat of future US capture. I have also proposed that countries have a block of IPv6 and BGP-AS space assigned as a 'Sovereign Reserve'. Each country would get a /32 which is more than enough to allow them to ensure that an artificial shortage of IPv6 addresses can't be used as a blockade. If there are government folk reading this list who are interested I can show them how to do it without waiting on permission from anyone. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography