Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 09/05/2013 01:57 PM, Perry E. Metzger wrote: and am not sure which international group is being mentioned. ISO. Not that narrows it down much. Eric ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
The NYT article is pretty informative: (http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html) Because strong encryption can be so effective, classified N.S.A. documents make clear, the agency’s success depends on working with Internet companies — by getting their voluntary collaboration, forcing their cooperation with court orders or surreptitiously stealing their encryption keys or altering their software or hardware. N.S.A. documents show that the agency maintains an internal database of encryption keys for specific commercial products, called a Key Provisioning Service, which can automatically decode many messages. If the necessary key is not in the collection, a request goes to the separate Key Recovery Service, which tries to obtain it. How keys are acquired is shrouded in secrecy, but independent cryptographers say many are probably collected by hacking into companies’ computer servers, where they are stored Also interesting: Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology, the United States’ encryption standards body, and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” “Eventually, N.S.A. became the sole editor,” the memo says. Anyone recognize the standard? Eric ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
Bruce Schneier explains the Dual_EC_DRBG attack: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: questions about RNGs and FIPS 140
On Thu, Aug 26, 2010 at 12:13:06PM -0400, Perry E. Metzger wrote: It is difficult to validate that a hardware RNG is working correctly. How do you know the bits being put off aren't skewed somehow by a manufacturing defect? How do you know that damage in the field won't cause the RNG to become less random? FIPS 140-1 did allow non-deterministic HW RNGs. If you used one then you had to run a boot-time self-test which, while not even close to an exhaustive RNG test, would hopefully detect a HW RNG that had failed. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: questions about RNGs and FIPS 140
On Thu, Aug 26, 2010 at 11:21:35AM -0500, Nicolas Williams wrote: Would it be possible to combine a FIPS 140-2 PRNG with a TRNG such that testing and certification could be feasible? Yes. (assuming you mean FIPS certification). Use the TRNG to seed the approved PRNG implementation. I'm thinking of a system where a deterministic (seeded) RNG and non-deterministic RNG are used to generate a seed for a deterministic RNG, which is then used for the remained of the system's operation until next boot or next re-seed. That is, the seed for the run-time PRNG would be a safe combination (say, XOR) of the outputs of a FIPS 140-2 PRNG and non-certifiable TNG. That won't pass FIPS. It's reasonable from a security standpoint, (although I would use a hash instead of an XOR), but it's not FIPS 140 certifiable. Since FIPS can't reasonably test the TRNG output, it can't be part of the output. FIPS 140 is about guaranteeing a certain level of security, not maximizing security. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote: Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. I completely agree. But HW RNGs are a pain in a lot of ways- modern chip design libraries don't include RNG modules. You have to make your own. Verification software won't verify it and considers it an error. When it runs it sucks a lot of power and generates a lot of heat. Not a problem for Intel, but if you're using a contract fab (TSMC) they probably won't guarantee that part of your chip will even work because according to chip design rules, it's wrong. Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So while I think it'd be great to have a decent RNG on chip (no more blocking on /dev/random!) I don't see it being much of a market advantage and would not be surprised if it never makes it in to a shipping product. Mixing the output with something else would address any lack of randomness either deliberate or accidental... but still wouldn't meet FIPS. BTW Intel isn't close to the first to put an RNG on a CPU chip. I worked for a company in the late 1990s that did it and I'm sure we wern't the first. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, Jul 12, 2010 at 03:37:45PM -0400, Paul Wouters wrote: On Mon, 12 Jul 2010, Eric Murray wrote: Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So you can do HWRNG - SWRNG - Fips ? Last FIPS cert I did (140-2, a couple years ago), it was SWRNG only. X9.62 or FIPS 186 or X9.31 or SP 800-90. I couldn't even use a HW RNG for the seed. /dev/random was acceptable. Also, the VIA PadLock already ships with an HWRNG on die. It's been shipping for years. True that. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: X.509 certificate overview + status
On Mon, Mar 02, 2009 at 05:35:20PM +0100, Marcus Brinkmann wrote: Travis wrote: Further, trying to dig into ASN.1 was extremely difficult. The specs are full of obtuse language, using terms like object without defining them first. Are there any tools that will dump certificates in human-readable formats? I would really like something that could take a PEM file of a cert and display it in XML or something of the sort. Ubuntu comes with dumpasn1. There are also quite a few libraries. openssl will print certs in a more human readable but slightly less complete format than dumpasn1: % openssl x509 -text cert dumpasn1 does not read PEM, so you need to do % openssl enc -d -c cert cert.der; dumpasn1 cert.der It's a little old but RFC3280 is the most concise and easiest to understand description of X.509 et. al. that I have found. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Monoculture
On Wed, Oct 01, 2003 at 04:48:33PM +0100, Jill Ramonsky wrote: I could do an implementation of SSL. Speaking as a programmer with an interest in crypto, I'm fairly sure I could produce a cleanly implemented and simple-to-use version. Yep. It's a bit of work, and more work to ensure that there are no programming bug type security holes, such as those recently announced, but it's not rocket science. But I would like to ask you to clarify something about SSL which has been bugging me. Allow me to present a scenario. Suppose: (1) Alice runs a web server. (2) Bob has a web client. (3) Alice and Bob know each other personally, and see each other every day. (4) Eve is the bad guy. She runs a Certificate Authority, which is trusted by Bob's browser, but not by Bob. Is it possible for Bob to instruct his browser to (a) refuse to trust anything signed by Eve, and (b) to trust Alice's certificate (which she handed to him personally)? (And if so, how?) Yes and yes. Most SSL/TLS implementations let the application designate a set of certs as trusted CA certs for purposes of authenticating SSL peers. If his client is programmed to let him, Bob can delete Eve's cert from the trusted CA list. Many browsers let you do this although it's often hard to find in the config menus. For (b), Bobs client would need to be able to mark Bob's copy of Alice's cert as trusted even though its not a self-signed CA cert. This is also just a matter of programming, but most browsers don't let you do this-- their programmers decided that in order to simplify operation, they would not allow browsers to mark non-selfsigned certs as trusted. The SSL/TLS spec is pretty quiet about what peers use to authenticate the certs that they receive. You'd be free to implement a PGP-style web of trust in your TLS implementation as long as the certs themselves are X.509 format. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Thu, Oct 02, 2003 at 12:06:40AM +0100, M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? No, it doesn't. If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. The non DH suites are there in the spec for use when your security model allows. Not many uses of TLS do. Last time I checked, which was a while ago now, very few deployed https servers offered anon DH suites. Which is appropriate since MITM breaks the https security model. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL
On Thu, Jul 10, 2003 at 12:04:33PM +0100, [EMAIL PROTECTED] wrote: Instead, I have a different question: Where can I learn about SSL? As in, could someone reccommend a good book, or online tutorial, or something, somewhere, that explains it all from pretty much first principles, and leaves you knowing enough at the end to be able to make sensible use of OpenSSL and similar? I'd recommend Eric Rescorla's _SSL And TLS_ book for learning about the protocol itself. It's a very good explanation of the protocol. A concise explanation of the basic protocol is in the original SSLv3 protocol spec from Netscape. It's short but must be read carefully. There's also a book on Openssl itself, that, from the parts I have looked at, seems pretty good. _Network Security with OpenSSL_ (Viega Messier Chandra). Like we've covered in this thread, Openssl has a whole lot of stuff that isn't needed for doing SSL. It's the last place you want to start trying to understand SSL. Instead, first get a basic understanding of the SSL protocol from Eric's book. Then look at Openssl. Unfortunately the simpler SSL implementations seem to not be freely available. If you do java, try Eric's 'pureTLS' java implementation. To start in Openssl, look at how the sample client and server apps work. Then step through them with a debugger. The way that Openssl is constructed with many macros and tables of pointers to functions makes it difficult to simply read until you come to recognize the names. Also, to be honest, the code is written in a style that makes it more difficult to understand than it should be. Nothing against Tim and Eric or the current Openssl crew, but anyone who uses that many single character variable names needs to be whacked on the butt with a rolled-up copy of KR C and be told NO in a very firm voice. Openssl is still changing and what little documentation they have is often stale. The openssl-users mailing list is quite active and is pretty good about answering questions. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
