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: [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"
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: 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: 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: 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: 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: 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
Using TCPA
On Thu, Feb 03, 2005 at 11:51:57AM -0500, Trei, Peter wrote: > It could easily be leveraged to make motherboards > which will only run 'authorized' OSs, and OSs > which will run only 'authorized' software. [..] > If you 'take ownership' as you put it, the internal > keys and certs change, and all of a sudden you > might not have a bootable computer anymore. I have an application for exactly that behaviour. It's a secure appliance. Users don't run code on it. It needs to be able to verify that it's running the authorized OS and software and that new software is authorized. (it does it already, but a TCPA chip might do it better). So a question for the TCPA proponents (or opponents): how would I do that using TCPA? 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: 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: 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 K&R 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]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 04:32:41PM -0400, Thor Lancelot Simon wrote: > I trimmed OpenSSL down to just TLSv1 and only the FIPS-140 conformant > algorithms for a FIPS-140 conformance project at ReefEdge (and yes, [..] > The result was still several hundred kilobytes -- actually, I don't > have exact numbers handy but I believe it was more than a megabyte > in size. OpenSSL is not the TLS implementation I would use if I had > any other free option that offered reasonable performance. :-( For comparison purposes, I have a copy of an SSLv3/TLS client library I wrote in 1997. It's 56k of (Intel Linux) code for everything except RSA. That includes the ASN.1 and X.509 parser. Implementing the server-specific parts would add only another couple k. This was done for a handheld computer but runs on unix as well. OpenSSL is huge because it's also a general purpose crypto lib, supports a bunch of hardware and a bunch of algorithms, SSLv2 (ew), old apis, non-blocking, etc etc. Eric - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 11:53:13AM -0700, Eric Rescorla wrote:
> Ian Grigg <[EMAIL PROTECTED]> writes:
>
> > It's not just you. The field seems to be evenly
> > divided between those who view SSL as a mess, and
> > those who view it as the only sane choice because
> > so much attention has been put on it.
> I'm not sure why you think that these two views are
> inconsistent. Sure, SSL embodies lots of mistakes, and I'm hard on
> some of those in my book. However, my experience is that when people
> sit down and try to do a better job, they generally bungle it. Tom's
> attempt is only the latest example.
Attempts to do new stuff should not be discouraged.
But like home-made ciphers, they should be viewed as interesting
learning exercises rather than serious secure protocols.
> > The main thing that reduces SSL's applicability to
> > real world problems come down to the assumption of
> > certificates as part and parcel of the security
> > model.
> This is just wrong. There are extensions to SSL to support Kerberos,
> SRP, and even primitive shared keys (see Peter Gutmann's latest draft
> on this topic).
Unauthenticated Diffie-Hellman has been in SSLv3 since the beginning.
Rejecting SSL because it "uses certifictes" is either a result
of ignorance of the spec or an excuse for re-inventing.
> > It's definately not just you - but one of the reasons
> > that it feels like that is that the SSL supporters
> > tend to protect their franchise very aggresively.
> It's not just SSL. I've beaten up on people who were trying to
> reinvent S/MIME in this very forum. It's just that people seem to try
> to reinvent SSL about 5 times more often than they try to reinvent
> anything else. My guess is that that's because the channel security
> problem *looks* so simple and so it seems like it should be easy to do
> something simpler and better than SSL.
If you are into wheels, it's more fun to (re-)invent the wheel the wheel
than it is to use the existing wheels laying about. The posters here
are wheel geeks ("look, I can build a 12-spoke wheel!") who are not
interested in the reliabilty of the bicycles that the wheels are used on.
> > Nonsense. We aren't even up to being the C-team,
> > we don't make the team. And we won't ever until
> > we cast off the shackles of rote acceptance, and
> > start challenging SSL on its inadequacies.
If you start with the same assumptions you will wind up
with something that looks very similar to SSL. Once you have discovered
and addressed all the same holes and pitfalls that is.
While it's a fun learning exercise, it's not useful to the rest of
the world... SSL, because it has had more review than your protocol
will ever get, will be more secure.
The only way to end up with something significantly different
is to address a different set of requirements... and more different
than "no certificates".
A good place to start is Eric's _SSL and TLS_ book.
How can you make something better without understanding the mistakes
of the past?
Eric
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
On Wed, Jun 04, 2003 at 04:32:23PM +1200, Peter Gutmann wrote: > "James A. Donald" <[EMAIL PROTECTED]> writes: > > >I never figured out how to use a certificate to authenticate a client to a > >web server, how to make a web form available to one client and not another. > >Where do I start? > > There's a two-level answer to this problem. At an abstract level, doing > client certs isn't hard, there are various HOWTOs around for Apache, Microsoft > have Technet/MSDN papers on it for IIS, etc etc. At a practical level, it's > almost never used because it's just Too Hard. That's not the SSL client-cert > part, it's the using-X.509 part. It's the I part of PKI that's hard. That the assumptions built into X.509 (i.e. a rigid certificate hierarchy) don't work everywhere just makes it harder. And the obstinance of the standards organizations involved don't help. Too often people see something like Peter's statement above and say "oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine" which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the "human readable" argument is moot. Note that there isn't a real running global PKI using SPKI or PGP either. The largest problem with X.509 is that various market/political forces have allowed Verisign to dominate the cert market and charge way too much for them. There is software operable by non-cryptographers that will generate reasonable cert reqs (it's not standard Openssl) but individuals and corporations alike balk at paying $300-700 for each cert. (yes I know about the free "individual" certs, the failure of S/MIME is a topic for another rant). This is why lne.com's STARTTLS cert is self-signed. Verisign isn't getting any more of my money. Eric - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
On Mon, Jun 02, 2003 at 10:09:06AM -0400, Ian Grigg wrote: > A lot of the tools and blocks are too hard to > understand. "Inaccessible" might be the proper > term. This might apply to, for example, SSL, > and more so to IPSec. These have a lower survival > rate, simply because as developers look at them, > their eyes glaze over and they move on. I heard > one guy say that "you can read SSH in an hour > and understand what's going on, but not SSL." Some who can't understand SSL won't be able to do better. Especially since there is at least one very good book on it. > Also, a lot of cryptosystems are put together > by committees. SSH was originally put together > by one guy. He did the lot. The original SSH protocol had holes so large that you could drive a truck through them. Tatu posted it to various lists and got lots of advice on how to clean it up. It still had holes that were being found years later. SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was. Peer review is not "design by comittie". It is the way to get strong protocols. When I have to roll my own (usually because its working in a limited environment and I don't have a choice) I get it reviewed. The protocol designer usually misses something in his own protocol. > I'd say that conditions for Internet crypto system > success would include: 0. USE EXISTING SECURITY PRIMITIVES which allows you to > 4. Concentrate on the application, not the crypto. Rolling your own crypto is where 95% of crypto apps fail... the developers either take too much time on it to the detrimient of the useability because it is the sexy thing to work on, or they write an insecure algorithm/protocol/system.Usually they do both! Eric - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
