Re: [Cryptography] RSA recommends against use of its own products.
BBN has created three ASN.1 code generators over time and even released a couple. (ASN.1 to C, C++, and Java). I believe that DER to support typical X.509 management is the easiest subset. I can check on status for release to open source if there is interest. It has been available as part of Certificate Management systems we've released to open source but obviously this is a very small COI indeed. I can read hex dumps of ASN.1 and choose not to develop similar skills for XML and other types. I'm getting too old for that kind of skill acquisition to be fun. But to forward reference in this chain (with apologies), I too would prefer a standard that that has Postel's principles as a touchstone. John Lowry Sent from my iPhone On Sep 30, 2013, at 0:28, James A. Donald jam...@echeque.com wrote: On 2013-09-29 23:13, Jerry Leichter wrote: BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is another story. For a comparison, look at the encodings Knuth came up with in the TeX world. Both dvi and pk files are extremely compact binary representations - but correct encoders and decoders for them are plentiful. DER is unintelligble and incomprehensible. There is, however, an open source complier for ASN.1 Does it not produce correct encoders and decoders for DER? (I have never used it) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography smime.p7s Description: S/MIME cryptographic signature ___ 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 2013-09-27 09:54, Phillip Hallam-Baker wrote: Quite, who on earth thought DER encoding was necessary or anything other than incredible stupidity? I have yet to see an example of code in the wild that takes a binary data structure, strips it apart and then attempts to reassemble it to pass to another program to perform a signature check. Yet every time we go through a signature format development exercise the folk who demand canonicalization always seem to win. DER is particularly evil as it requires either the data structures to be assembled in the reverse order or a very complex tracking of the sizes of the data objects or horribly inefficient code. But XML signature just ended up broken. We have a compiler that generates C code from ASN.1 code. Does it not generate code behind the scenes that does all this ugly stuff for us without us having to look at the code? I have not actually used the compiler, and I have discovered that hand generating code to handle ASN.1 data structures is a very bad idea, but I am told that if I use the compiler, all will be rainbows and unicorns. You go first. ___ 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 Sep 26, 2013, at 7:54 PM, Phillip Hallam-Baker wrote: ...[W]ho on earth thought DER encoding was necessary or anything other than incredible stupidity?... It's standard. :-) We've been through two rounds of standard data interchange representations: 1. Network connections are slow, memory is limited and expensive, we can't afford any extra overhead. Hence DER. 2. Network connections are fast, memory is cheap, we don't have to worry about them - toss in every last feature anyone could possibly want. Hence XML. Starting from opposite extremes, committees of standards experts managed to produce results that are too complex and too difficult for anyone to get right - and which in cryptographic contexts manage to share the same problem of multiple representations that make signing such a joy. BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is another story. For a comparison, look at the encodings Knuth came up with in the TeX world. Both dvi and pk files are extremely compact binary representations - but correct encoders and decoders for them are plentiful. (And it's not as if the Internet world hasn't come up with complex, difficult encodings when the need arose - see IDNA.) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
Phillip Hallam-Baker hal...@gmail.com writes: Quite, who on earth thought DER encoding was necessary or anything other than incredible stupidity? At least some X.500/LDAP folks thought they could do it. Mind you, we're talking about people who believe in X.500/LDAP here... Peter. ___ 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 2013-09-29 23:13, Jerry Leichter wrote: BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is another story. For a comparison, look at the encodings Knuth came up with in the TeX world. Both dvi and pk files are extremely compact binary representations - but correct encoders and decoders for them are plentiful. DER is unintelligble and incomprehensible. There is, however, an open source complier for ASN.1 Does it not produce correct encoders and decoders for DER? (I have never used it) ___ 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 Thu, 26 Sep 2013, ianG wrote: Right, scratch the Brits and the French. Maybe AU, NZ? I don't know. Maybe the Germans / Dutch / Austrians. At the risk of getting political, I'd recommend against AU (I live there). Our new gummint has already shown that it will put its own interests ahead of those of the people (cancelling the proposed National Broadband Network springs to mind). Switzerland, perhaps? They have a history of secrecy... -- Dave ___ 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?= kristian.gjost...@math.ntnu.no 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
Re: [Cryptography] RSA recommends against use of its own products.
ianG i...@iang.org 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 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 i...@iang.org 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] RSA recommends against use of its own products.
On 26/09/13 02:32 AM, Peter Gutmann wrote: ianG i...@iang.org 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 24 September 2013 17:01, Jerry Leichter leich...@lrw.com wrote: On Sep 23, 2013, at 4:20 AM, ianG i...@iang.org wrote: ... But they made Dual EC DRBG the default ... At the time this default was chosen (2005 or thereabouts), it was *not* a mistake. https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html Problems with Dual_EC_DRBG were first described in early 2006 With hindsight, it was definitely a mistake. The questions are whether they could or should have known it was a mistake at the time and whether the NSA played any part in the mistake, and whether they should have warned users and changed the default well before now. -- alan.bragg...@gmail.com http://www.chiark.greenend.org.uk/~armb/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
Hi Jerry, I appreciate the devil's advocate approach here, it has helped to get my thoughts in order! Thanks! My conclusion is: avoid all USA, Inc, providers of cryptographic products. Argumentation follows... On 24/09/13 19:01 PM, Jerry Leichter wrote: On Sep 23, 2013, at 4:20 AM, ianG i...@iang.org wrote: RSA today declared its own BSAFE toolkit and all versions of its Data Protection Manager insecure... Etc. Yes, we expect the company to declare itself near white, and the press to declare it blacker than the ace of spaces. Meanwhile, this list is about those who know how to analyse this sort of stuff, independently. So... Indeed. ... But they made Dual EC DRBG the default ... I don't see a lot of distance between choosing Dual_EC as default, and the conclusion that BSAFE user-systems are insecure. The conclusion it leads to is that *if used in the default mode*, it's (well, it *may be*) unsafe. 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. Therefore we could say that BSAFE is mostly unsafe, but as we don't know who is using it in default mode, I'm sure most cryptography people would agree that means unsafe, period. We know no more today about the quality of the implementation than we did yesterday. (In fact, while I consider it a weak argument ... if NSA had managed to sneak something into the code making it insecure, they wouldn't have needed to make a *visible* change - changing the default. So perhaps we have better reason to believe the rest of the code is OK today than we did yesterday.) Firstly, this is to suggest that quality of implementation is the issue. It isn't, the issue is whether the overall result is safe -- to end-users. In this case, it could be fantastic code, but if the RNG is spiked, then the fantastic code is approx. worthless. Reminds me of what the IRA said after nearly knocking off Maggie Thatcher: Today we were unlucky, but remember we only have to be lucky once. You will have to be lucky always. Secondly, or more widely, if the NSA has targetted RSA, then what can we conclude about quality of the rest of the implementation? We can only make arguments about the rest of the system if we assume this was a one-off. That would be a surprising thing to assume, given what else we know. The question that remains is, was it an innocent mistake, or were they influenced by NSA? a) How would knowing this change the actions you take today? * knowing it was an innocent mistake: well, everyone makes them, even Debian. So perhaps these products aren't so bad? * knowing it was an influenced result: USA corporations are to be avoided as cryptographic suppliers. E.g., JCE, CAPI, etc. Supporting assumptions: 1. assume the NSA is your threat model. Once upon a time those threatened were a small group of neerdowellers in far flung wild countries with exotic names. Unfortunately, this now applies to most people -- inside the USA, anyone who's facing a potential criminal investigation by any of the USA agencies, due to the DEA trick. So most of Wall Street, etc, and anyone who's got assets attachable for ML, in post-WoD world, etc. Outside the USA, anyone who's 2 handshakes from any neerdowellers. 2. We don't as yet have any such evidence from non-USA corps, do we? (But I ain't putting my money down on that...) 3. Where goes RSA, also follows Java's JCE (recall Android) and CAPI. How far behind are the rest? http://www.theregister.co.uk/2013/09/19/linux_backdoor_intrigue 4. Actually, we locals on this list already knew this to a reasonable suspicion. But now we have a chain of events that allows a reasonable person outside the paranoiac security world to conclude that the NSA has corrupted the cryptography delivery from a USA corp. http://financialcryptography.com/mt/archives/001446.html b) You've posed two alternatives as if they were the only ones. At the time this default was chosen (2005 or thereabouts), it was *not* a mistake. Dual EC DRBG was in a just-published NIST standard. ECC was hot as the best of the new stuff - with endorsements not just from NSA but from academic researchers. Dual EC DRBG came with a self-test suite, so could guard itself against a variety of attacks and other problems. Really, the only mark against it *at the time* was that it was slower than the other methods - but we've learned that trading speed for security is not a good way to go, so that was not dispositive. True, 2005 or thereabouts, such a story could be and was told, and we can accept for the sake of argument it might not have been a mistake given what they knew. That ended 2007. RSA was no doubt informed of the results as they happened, because they are professionals, now conveniently listed out by Mathew Greene:
Re: [Cryptography] RSA recommends against use of its own products.
24. sep. 2013 kl. 18:01 skrev Jerry Leichter leich...@lrw.com: At the time this default was chosen (2005 or thereabouts), it was *not* a mistake. Dual EC DRBG was in a just-published NIST standard. ECC was hot as the best of the new stuff - with endorsements not just from NSA but from academic researchers. Choosing Dual-EC-DRBG has been a mistake for its entire lifetime, because it is so slow. While some reasonable people seem to have a preference for cryptography based on number theory, I've never met anyone who would actually use Dual-EC-DRBG. (Blum-Blum-Shub-fanatics show up all the time, but they are all nutcases.) I claim that RSA was either malicious, easily fooled or incompetent to use the generator. I will not buy anything from RSA in the future. Were I using RSA products or services, I would find replacements. (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.) -- Kristian Gjøsteen ___ 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 22/09/13 16:43 PM, Jerry Leichter wrote: On Sep 20, 2013, at 2:08 PM, Ray Dillinger wrote: More fuel for the fire... http://rt.com/usa/nsa-weak-cryptography-rsa-110/ RSA today declared its own BSAFE toolkit and all versions of its Data Protection Manager insecure, recommending that all customers immediately discontinue use of these products Wow. You took as holy writ on a technical matter a pronouncement of the general press. Etc. Yes, we expect the company to declare itself near white, and the press to declare it blacker than the ace of spaces. Meanwhile, this list is about those who know how to analyse this sort of stuff, independently. So... ... But they made Dual EC DRBG the default ... I don't see a lot of distance between choosing Dual_EC as default, and the conclusion that BSAFE user-systems are insecure. The question that remains is, was it an innocent mistake, or were they influenced by NSA? We don't have much solid evidence on that. But we can draw the dots, and a reasonable judgement can fill the missing pieces in. iang ___ 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 Sep 20, 2013, at 2:08 PM, Ray Dillinger wrote: More fuel for the fire... http://rt.com/usa/nsa-weak-cryptography-rsa-110/ RSA today declared its own BSAFE toolkit and all versions of its Data Protection Manager insecure, recommending that all customers immediately discontinue use of these products Wow. You took as holy writ on a technical matter a pronouncement of the general press. And not just of the general press, but of RT, a Russian publication with a clear pro-Russian anti-American bias. (Not that they don't deliver useful information - I've read them in the past, along with Al Jazeera and, on the flip side, The Debka Files. They are all valid and useful members of the press, but their points of view, AKA biases, are hardly a secret.) The original article in Wired is still a bit sensationalistic, but at least it gets the facts right. BSAFE is a group of related libraries of crypto primitives that RSA has sold for many years. They generally implement everything in the relevant standards, and sometimes go beyond that and include stuff that seems to be widely accepted and used. Naturally, they also use the same libraries in some packaged products they sell. As far as I know, the BSAFE implementations have been reasonably well thought of over the years. In my experience, they are conservatively written - they won't be the fastest possible implementations, but they'll hold their own, and they probably are relatively bug-free. A big sales advantage is that they come with FIPS certifications. For whatever you think those are actually worth, they are required for all kinds of purposes, especially if you sell products to the government. I remember looking at BSAFE for use in a product I worked on many years ago. We ended up deciding it was too expensive and used a combination of open source code and some stuff we wrote ourselves. The company was eventually acquired by EMC (which also owns RSA), and I suspect our code was eventually replaced with BSAFE code. Since Dual EC DRBG was in the NIST standards, BSAFE provided an implementation - along with five other random number generators. But they made Dual EC DRBG the default, for reasons they haven't really explained beyond in 2004 [when these implementations were first done] elliptic curve algorithms were becoming the rage and were considered to have advantages over other algorithms I'd guess that no one remembers now, six or more years later, exactly how Dual EC DRBG came to be the default. We now suspect that a certain government agency probably worked to tip the scales. Whether it was directly through some contacts at RSA, or indirectly - big government client says they want to buy the product but it must be safe by default, and Dual EC DRBG is what our security guys say is safe - who knows; but the effect is the same. (If there are any other default choices in BSAFE, they would be worth a close look. Influencing choices at this level would have huge leverage for a non-existent agency) Anyway, RSA has *not* recommended that people stop using BSAFE. They've recommended that they stop using *Dual DC DRBG*, and instead select one of the other algorithms. For their own embedded products, RSA will have to do the work. Existing customers most likely will have to change their source code and ship a new release - few are likely to make the RNG externally controllable. Presumably RSA will also issue new versions of the BSAFE products in which the default is different. But it'll take years to clean all this stuff up. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
*1 Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin. -- John Von Neumann That said, it seems that most of these attacks on Pseudorandom generators some of which are deliberately flawed, can be ameliorated somewhat by using a known-good (if slow) Pseudorandom generator. If we were to take the compromised products, rip out the PRNG's, and replace them with Blum-Blum-Shub generators, we would have products that work more slowly -- spending something like an order of magnitude more time on the generation of Pseudorandom bits -- but the security of those bits would be subject to an actual mathematical proof that prediction of the next really is at least equal in difficulty to a known-size factoring problem. Factoring problems apparently aren't as hard as we used to think but they *are* still pretty darn hard. Slow or not, I think we do need to have at least one option available in most PRNG-using systems which comes with a mathematical proof that prediction is GUARANTEED to be hard. Otherwise it's too easy for people and businesses to be caught absolutely flatfooted and have no recourse when a flawed PRNG is discovered or a trust issue requires them to do something heroic in order to convince customers that the customers' data can actually be safe. We've been basing our notion of security on the idea that others don't know something we don't know -- which is sort of nebulous on its face and of course can never be provable. We can't really change that until/unless we can say something definite about P=NP, but we're a lot more sure that nobody else has anything definite to say about P=NP than we are about most crypto primitives. Do we know of anything faster than BBS that comes with a real mathematical proof that prediction is at least as hard as $SOME_KNOWN_HARD_PROBLEM ? Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
