Re: [Cryptography] RSA equivalent key length/strength
On 26/09/13 02:24 AM, Peter Fairbrother wrote: On 25/09/13 17:17, ianG wrote: On 24/09/13 19:23 PM, Kelly John Rose wrote: I have always approached that no encryption is better than bad encryption, otherwise the end user will feel more secure than they should and is more likely to share information or data they should not be on that line. The trap of a false sense of security is far outweighed by the benefit of a "good enough" security delivered to more people. We're talking multiple orders of magnitude here. The math that counts is: Security = Users * Protection. No. No. No. Please, no? No. Nonononononono. It's Summa (over i) P_i.I_i where P_i is the protection provided to information i, and I_i is the importance of keeping information i protected. I'm sorry, I don't deal in omniscience. Typically we as suppliers of some security product have only the faintest idea what our users are up to. (Some consider this a good thing, it's a privacy quirk.) With that assumption, the various i's you list become some sort of average. This is why the security model that is provided is typically one-size-fits-all, and the most successful products are typically the ones with zero configuration and the best fit for the widest market. Actually it's more complex than that, as the importance isn't a linear variable, and information isn't either - but there's a start. Increasing i by increasing users may have little effect on the overall security, if the protecting the information they transmit isn't particularly valuable. Right, and you know that, how? (how valuable each person's info is, I mean.) And saying that something is secure - which is what people who are not cryptographers think you are doing when you recommend that something - tends to increase I_i, the importance of the information to be protected. 2nd order effects from the claim of security, granted. Which effects they are, is again subject to the law of averages. And if the new system isn't secure against expensive attacks, then overall security may be lessened by it's introduction. Even if Users are increased. Ah, and therein lies the rub. Maybe. This doesn't mean it will. Typically, the fallacy of false sense of security relies on an extremely unusual or difficult attack (aka acceptable risk). And then ramps up that rarity to a bogeyman status. So that everyone is scared of it. And we must, we simply must protect people against it! Get back to science. How risky are these things? I have about 30 internet passwords, only three of which are in any way important to me - those are the banking ones. I use a simple password for all the rest, because I don't much care if they are compromised. But I use the same TLS for all these sites. Now if that TLS is broken as far as likely attacks against the banks go, I care. I don't much care if it's secure against attacks against the other sites like my electricity and gas bills. (You'll see this play out in phishing. Banks are the number one target for attacks on secure browsing.) I might use TLS a lot more for non-banking sites, but I don't really require it to be secure for those. I do require it to be secure for banking. You are resting on taught wisdom about TLS, which is oriented to a different purpose than security. In practice, a direct attack against TLS is very rare, a direct attack against your browser connection to your bank is very rare, and a direct attack against your person is also very rare. This is why for example we walk the streets without body armour, even in Nairobi (this week) or the Beltway (11 years ago). This is why there are few if any (open question?) reported breaches of banks due to the BEAST and other menagerie attacks against TLS. We can look at this many ways, but one way is this: the margin of fat in TLS is obscene. If it were sentient, it would be beyond obese, it would be a circus act. We can do some dieting. And I'm sure that some people would like TLS to be secure against the NSA for, oh, let's say 10 years. Which 1024-bit DHE will not provide. Well, right. So, as TLS is supposed to be primarily (these days) focussed on protecting your bank account access, and as its auth model fails dismally when it comes to phishing, why do we care about something so exotic as the NSA? Get back to basics. Let's fix the TLS so it actually does the client - webserver auth problem first. 1024 is good enough for that, for now, but in the meantime prepare for something longer. (We now have evidence of some espionage spear phishing that bothered to crunch 512. Oh happy day, some real evidence!) As for the NSA, actually, 1024 works fine for that too, for now. As long as we move them from easy decryption to actually having to use a lot of big fat expensive machines, we win. They then have to focus, rather than harvest. Presumably they have not forgotten how to do that. If you re
Re: [Cryptography] RSA recommends against use of its own products.
On 26/09/13 02:32 AM, Peter Gutmann wrote: ianG writes: Well, defaults being defaults, we can assume most people have left it in default mode. I suppose we could ask for research on this question, but I'm going to guess: most. “Software Defaults as De Facto Regulation: The Case of Wireless APsâ€�, Rajiv Shah and Christian Sandvig, Proceedings of the 33rd Research Conference on Communication, Information and Internet Policy (TPRC’07), September 2005, reprinted in Information, Communication, and Society, Vol.11, No.1 (February 2008), p.25. Peter. Nice. Or, as I heard somewhere, there is only one mode, and it is secure. http://www-personal.umich.edu/~csandvig/research/Shah-Sandvig--Defaults_as_de_facto_regulation.pdf Today’s internet presumes that individuals are capable of configuring software to address issues such as spam, security, indecent content, and privacy. This assump- tion is worrying – common sense and empirical evidence state that not everyone is so interested or so skilled. When regulatory decisions are left to individuals, for the unskilled the default settings are the law. This article relies on evidence from the deployment of wireless routers and finds that defaults act as de facto regu- lation for the poor and poorly educated. This paper presents a large sample beha- vioral study of how people modify their 802.11 (‘Wi-Fi’) wireless access points from two distinct sources. The first is a secondary analysis of WifiMaps.com, one of the largest online databases of wireless router information. The second is an original wireless survey of portions of three census tracts in Chicago, selected as a diversity sample for contrast in education and income. By constructing lists of known default settings for specific brands and models, we were then able to ident- ify how people changed their default settings. Our results show that the default settings for wireless access points are powerful. Media reports and instruction manuals have increasingly urged users to change defaults – especially passwords, network names, and encryption settings. Despite this, only half of all users change any defaults at all on the most popular brand of router. Moreover, we find that when a manufacturer sets a default 96–99 percent of users follow the suggested behavior, while only 28–57 percent of users acted to change these same default settings when exhorted to do so by expert sources. Finally, there is also a suggestion that those living in areas with lower incomes and levels of education are less likely to change defaults, although these data are not conclusive. These results show how the authority of software trumps that of advice. Consequently, policy-makers must acknowledge and address the power of software to act as de facto regulation. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
On 25/09/13 21:12 PM, Jerry Leichter wrote: On Sep 25, 2013, at 12:31 PM, ianG wrote: ... My conclusion is: avoid all USA, Inc, providers of cryptographic products. In favor off ... who? Ah well, that is the sticky question. If we accept the conclusion, I see these options: 1. shift to something more open. 2. use foreign providers. 3. start writing. 4. get out of the security game. We already know that GCHQ is at least as heavily into this monitoring business as NSA, so British providers are out. The French ... Right, scratch the Brits and the French. Maybe AU, NZ? I don't know. Maybe the Germans / Dutch / Austrians. It's a really, really difficult problem. For deterministic algorithms, in principle, you can sandbox ... If you are referring to testing a provider's product for leaks, I think that's darn near impossible. (If referring to the platform and things like leakage, that is an additional/new scope.) For probabilistic algorithms - choosing a random number is, of course, the simplest example - it's much, much harder. You're pretty much forced to rely on some mathematics and other analysis - testing can't help you much. As I have said, if you care, you write your own collector/mix/DRBG. If not, then you're happy reading /dev/random. (for the rest, all agreed.) iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] forward-secrecy >=2048-bit in legacy browser/servers? (Re: RSA equivalent key length/strength)
Adam Back writes: >Is there a possibility with RSA-RSA ciphersuite to have a certified RSA >signing key, but that key is used to sign an RS key negotiation? Yes, but not in the way you want. This is what the 1990s-vintage RSA export ciphersuites did, but they were designed so you couldn't use them to provide strong security. >I imagine that ciphersuite is widely disabled at this point. That'd be the other problem :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] forward-secrecy >=2048-bit in legacy browser/servers? (Re: RSA equivalent key length/strength)
On 25/09/13 13:25, Adam Back wrote: On Wed, Sep 25, 2013 at 11:59:50PM +1200, Peter Gutmann wrote: Something that can "sign a new RSA-2048 sub-certificate" is called a CA. For a browser, it'll have to be a trusted CA. What I was asking you to explain is how the browsers are going to deal with over half a billion (source: Netcraft web server survey) new CAs in the ecosystem when "websites sign a new RSA-2048 sub-certificate". This is all ugly stuff, and probably < 3072 bit RSA/DH keys should be deprecated in any new standard, but for the legacy work-around senario to try to improve things while that is happening: Is there a possibility with RSA-RSA ciphersuite to have a certified RSA signing key, but that key is used to sign an RS key negotiation? At least that was how the export ciphersuites worked (1024+ bit RSA auth, 512-bit export-grade key negotation). And that could even be weakly forward secret in that the 512bit RSA key could be per session. I imagine that ciphersuite is widely disabled at this point. But wasnt there also a step-up certificate that allowed stronger keys if the right certificate bits were set (for approved export use like banking.) Would setting that bit in all certificates allow some legacy server/browsers to get forward secrecy via large, temporary key negotiation only RSA keys? (You have to wonder if the 1024-bit max DH standard and code limits was bit of earlier sabotage in itself.) A couple of points: all the big CAs will give you a new certificate with a new key for free (but revocation is your baby) - while it isn't something they do, can't they issue say two years worth of one-day certs for perhaps a little more than the price of a two-year cert? In the UK we have a law called RIPA, part of which allows Plod to demand keys. They can demand keys used for encryption and for key setup - but they can't demand keys used only for authentication. I don't think they routinely demand keys from TLS/SSL webservers. The point is that in an ordinary TLS session the RSA key is used for both secrecy and authentication - in any future TLS these functions should be split. Also, Dan Boneh was talking at this years RSA cryptographers track about putting some sort of quantum-computer-resistant PK into browsers - maybe something like that should go into TLS2 as well? You need to get the browser makers - Apple, Google, Microsoft, Mozilla - and the webservers - Apache, Microsoft, nginx - together and get them to agree "we must all implement this" before writing the RFC. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
ianG writes: >Well, defaults being defaults, we can assume most people have left it in >default mode. I suppose we could ask for research on this question, but I'm >going to guess: most. âSoftware Defaults as De Facto Regulation: The Case of Wireless APsâ, Rajiv Shah and Christian Sandvig, Proceedings of the 33rd Research Conference on Communication, Information and Internet Policy (TPRCâ07), September 2005, reprinted in Information, Communication, and Society, Vol.11, No.1 (February 2008), p.25. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 25/09/13 17:17, ianG wrote: On 24/09/13 19:23 PM, Kelly John Rose wrote: I have always approached that no encryption is better than bad encryption, otherwise the end user will feel more secure than they should and is more likely to share information or data they should not be on that line. The trap of a false sense of security is far outweighed by the benefit of a "good enough" security delivered to more people. We're talking multiple orders of magnitude here. The math that counts is: Security = Users * Protection. No. No. No. Please, no? No. Nonononononono. It's Summa (over i) P_i.I_i where P_i is the protection provided to information i, and I_i is the importance of keeping information i protected. Actually it's more complex than that, as the importance isn't a linear variable, and information isn't either - but there's a start. Increasing i by increasing users may have little effect on the overall security, if the protecting the information they transmit isn't particularly valuable. And saying that something is secure - which is what people who are not cryptographers think you are doing when you recommend that something - tends to increase I_i, the importance of the information to be protected. And if the new system isn't secure against expensive attacks, then overall security may be lessened by it's introduction. Even if Users are increased. I have about 30 internet passwords, only three of which are in any way important to me - those are the banking ones. I use a simple password for all the rest, because I don't much care if they are compromised. But I use the same TLS for all these sites. Now if that TLS is broken as far as likely attacks against the banks go, I care. I don't much care if it's secure against attacks against the other sites like my electricity and gas bills. I might use TLS a lot more for non-banking sites, but I don't really require it to be secure for those. I do require it to be secure for banking. And I'm sure that some people would like TLS to be secure against the NSA for, oh, let's say 10 years. Which 1024-bit DHE will not provide. If you really want to recommend 1024-bit DHE, then call a spade a spade - for a start, it's EKS, ephemeral key setup. It doesn't offer much in the way of forward secrecy, and it offers nothing at all in the way of perfect forward secrecy. It's a political stunt to perhaps make trawling attacks by NSA more expensive (in cases where the website has given NSA the master keys [*]) - but it may make targeted attacks by NSA cheaper and easier. And in ten years NSA *will* be able to read all your 1024-bit DHE traffic, which it is storing right now against the day. [*] does anyone else think it odd that the benefit of introducing 1024-bit DHE, as opposed to 2048-bit RSA, is only active when the webserver has given or will give NSA the keys? Just why is this being considered for recommendation? Yes, stunt. -- Peter Fairbrother iang ___ 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] RSA recommends against use of its own products.
=?iso-8859-1?Q?Kristian_Gj=F8steen?= writes: >(For what it's worth, I discounted the press reports about a trapdoor in >Dual-EC-DRBG because I didn't think anyone would be daft enough to use it. I >was wrong.) +1. It's the Vinny Gambini effect (from the film My Cousin Vinny): Judge Haller: Mr. Gambini, didn't I tell you that the next time you appear in my court that you dress appropriately? Vinny: You were serious about dat? And it's not just Dual-EC-DRBG that triggers the "You were serious about dat?" response, there are a number of bits of security protocols where I've been... distinctly surprised that anyone would actually do what the spec said. (Having said that, I've also occasionally been pleasantly surprised when, by unanimous unspoken consensus among implementers, everyone ignored the spec and did the right thing). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
