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 shamr...@cypherpunks.towrote: -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
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] 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] 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
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 i...@iang.org wrote: On 17/09/13 23:52 PM, John Kemp wrote: On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker hal...@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. 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,
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
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 9/18/13 5:50 PM, Viktor Dukhovni cryptogra...@dukhovni.org 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] The Case for Formal Verification
Perry E. Metzger perry at 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 19 Sep 2013 19:11, Bill Frantz fra...@pwpconsult.com 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] 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
