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] MITM source patching [was Schneier got spooked]
re: git, signed commits, log verification, etc Monotone supports a good bit of PKI within it... http://monotone.ca/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Specification: Prism Proof Email
On 9/20/13 at 11:59 AM, hal...@gmail.com (Phillip Hallam-Baker) wrote: As someone who has seen the documents said to me this week, given a choice between A and B, the NSA does both. We have to do the same. Rather than have a pointless argument about whether Web 'o Trust or PKIX is the way to go, let everyone do both. Let people get a certificate from a CA and then get it endorsed by their peers: belt and braces. This approach certainly meets my requirements. As a UI designer/user I want it to JFW (Just ... Work) invisibly under the covers. As a boarder-line paranoid, I want a indicator of which methods passed. :-) Let's add to the list of methods the SSH method of, "The same key used the last time". I assume users of the CA method would register with the CA in some maner which would probably cost money. (How the CA separates me from Bill Frantz, the professional photographer in Illinois is not going to be cheap.) I understand there is still a trademark dispute between the US beer Budwiser and the German beer of the same name. In the WoT case, having your key fingerprint written on a QR code is a neat hack. Put it on the back of your business card[1]. I think CAs will be most useful for businesses while WoT will be most useful for individuals. Everyone will be more comfortable when the SSH test passes. Cheers - Bill [1] Back in days of yore, I needed to send some company private data to my home computer. I didn't have the fingerprint of my key at work, but I did have Carl Ellison's business card with the fingerprint of his key. He had signed my key which was available on a key server, so I had good enough reason to trust that the key was actually mine. --- Bill Frantz| Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The Case for Formal Verification
> The CompCert people are claiming a formally verified compiler and I > think this claim is very misleading to say the least. I don't find it misleading at all and I think perhaps the confusion is your notion of what formally verified means. >> And to suggest that such a project is misguided because it places >> blind trust in coq (and because it is written in ocaml?!) shows a >> misunderstanding of the proof tools. There is a very small core of >> trust that you need to have faith in and it is backed by solid theory > > Yes, the axioms. These need to be small in number and 'obviously' > correct; something that cannot be said of the source code of coq. > The nearest I can think of is the Lisp subset written in itself in > under a 100 lines (my memory is vague on this point) What I am saying is that you do not need to trust the coq code. There is actually very little of the coq tool that you do need to trust. That is the part of coq that performs type checking. The type checker is what verifies proofs. It is a small part of coq and most of coq is not trusted and generates terms that still must pass the type checker. Neither do you need to put a lot of faith in the ocaml compiler, the cpu or spend a lot of time worrying about cosmic rays flipping the bits during computation. Yes, some flaw could potentially lead to an incorrect computation on a certain cpu or a certain memory bit in a certain machine during a certain computation. But the coq type checker has been compiled on many machines and with many versions of the ocaml library and the odds of a random error behaving in a way that just happens to validate an invalid proof term more miniscule (as in, I would be more worried about your spontaneously tunneling into my livingroom due to quantum effects to resume the rest of this conversation). There is a small part of coq that you DO have to trust. If this part is incorrect it could invalidate all of the proofs. However, this part of coq is backed by strong theory and has had many eyes on it. And while it is possible that an error here could lead to a bad proof, it is by no means assured. > Derek M. Jones tel: +44 (0) 1252 520 667 -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On Sep 19, 2013, at 5:21 PM, Phillip Hallam-Baker wrote: > Criminals circumvent the WebPKI rather than trying to defeat it. If they did > start breaking the WebPKI then we can change it and do something different. If criminals circumvent the PKI to steal credit card numbers, this shows up as fraud and is noticed without any need for a Snowden. Eavesdropping doesn't show up in such an obvious way. > But financial transactions are easier than protecting the privacy of > political speech because it is only money that is at stake. The criminals are > not interested in spending $X to steal $0.5X. We can do other stuff to raise > the cost of attack if it turns out we need to do that. Also, criminals find it harder to spend a few million up front before they get the first payoff. Nor can they appeal to patriotism or compel compliance via the law. > If we want this to be a global infrastructure we have 2.4 billion users to > support. If we spend $0.01 per user on support, that is $24 million. It is > likely to be a lot more than that per user. It has to pay for itself ultimately, at least as well as email does. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The Case for Formal Verification
> 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/ With all due respect, most of the points you make are ridiculous. For example, you point out that the certified C compiler will not make any guarantees about code that relies on undefined behavior. Well, of course! Being certified doesn't magically fix your specification! Certified just says the implementation matches the specification! And to suggest that such a project is misguided because it places blind trust in coq (and because it is written in ocaml?!) shows a misunderstanding of the proof tools. There is a very small core of trust that you need to have faith in and it is backed by solid theory and is a much more solid foundation for building on than just about any other software we have in computer science. I don't see how in any way you can compare the f2c translator to this effort. -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] What is Intel® Core™ vPro™ Technology Animation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hah hah hah. Uh, reading between the lines, color me *skeptical* that this is really what it claims to be, given the current understanding of things... http://www.intel.com/content/www/us/en/enterprise-security/what-is-vpro-technology-video.html - --- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSPlBtAAoJEDMbeBxcUNAe5RIH/iIG/149Nbaho+v8ni2lMr2T CD0VRErhdcYbqedBgHvP6cCTtErS9u2EeeVKA2yOHtZJg4FXgTWGsxGGA8vTkUYK 6NhK+HJqt7g4s0x+xSdE2nAmD0ib/94PubSOqgG1suyziqai2iRLoi9XkMaNQuX0 rIdnq6ieVA2aXCB+zK1mYWrn4ugoF9xsijlkoYm2kYkUA0a1/HlyVx880mKj2BGz b0aJNZeL3+EDubZ2tcsc93azeREethJesqBRDjAuY8StHWEaxFjqtlqqLGZbowUE hRbxOQ9vsrhy/9W4CCN3TIwT1RSh+5NjJ6JSq8GNkcPzYeZjsYSLmcHBKiGNbJE= =xwfm -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 9/14/13 11:38 AM, Adam Back wrote: Tin foil or not: maybe its time for 3072 RSA/DH and 384/512 ECC? I'm inclined to agree with you, but you might be interested/horrified in the "1024 bits is enough for anyone" debate currently unfolding on the TLS list: http://www.ietf.org/mail-archive/web/tls/current/msg10009.html and there was a similar discussion on the OpenSSL list recently, with GnuTLS getting "blamed" for using the ECRYPT recommendations rather than 1024: http://www.mail-archive.com/openssl-users@openssl.org/msg71899.html --Patrick ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
