Re: [Cryptography] Today's XKCD is on password strength.
On Wed, Aug 10, 2011 at 07:12:07AM -0700, Perry E. Metzger wrote: Today's XKCD is on password strength. The advice it gives is pretty good in principle... . . . unless the person trying to crack the password treats the password as a passphrase like the user does, and uses combinations of common words rather than strings of random letters to try to crack the password. The problem is that ~44 bits of entropy here assumes the person trying to crack the password is using the simplest possible means of brute force cracking, and is not clever enough to consider the possibility that there may be patterns of character selection based on terms in the English language. The correct horse battery staple example imposes patterns on password generation that do not exist in, say, gCac2 RY9%sK%/3Q2!P}p2?'H1q?. I find it frankly shocking that most of the people in the world trying to come up with a clever trick to get around using strong passwords simply do not think about the fact that when the characters in your password have predictable relationships to one another (e.g., Y9%sK as a pattern appears in no natural language word, but horse certainly does appear, and is a predictable relationship between characters), that cuts into the effective randomness of the string of characters you use. A collection of words does *not* produce as many bits of entropy as people seem to think. I also find it frankly shocking that it seems like nobody in the world has heard of a password manager. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpL4IG0kw4R2.pgp Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [IP] Malware kills 154
On Tue, Aug 24, 2010 at 06:44:02PM -0400, Steven Bellovin wrote: On Aug 24, 2010, at 12:32 19PM, Chad Perrin wrote: On Mon, Aug 23, 2010 at 03:35:45PM -0400, Steven Bellovin wrote: And the articles I've seen do not say that the problem caused the crash. Rather, they say that a particular, important computer was infected with malware; I saw no language (including in the Google translation of the original article at http://www.elpais.com/articulo/espana/ordenador/Spanair/anotaba/fallos/aviones/tenia/virus/elpepiesp/20100820elpepinac_11/Tes, though the translation has some crucial infelicities) that said because of the malware, bad things happened. It may be like the reactor computer with a virus during a large blackout -- yes, the computer was infected, but that wasn't what caused the problem. The problem was evidently a couple of maintenance technicians who didn't do their jobs correctly. The computer comes into the matter because one of its jobs was to activate an alarm if a critical system whose failure *was* the proximate cause of the crash was not working properly. It didn't activate the alarm, which would have led to the aircraft being prohibited from taking off, because of the malware. What I have not seen are any statements attributed to the investigating agency that support your last conclusion: that the malware is what caused the alarm failure. I saw a very good summary of the official findings; I'll ask permission to repost them. I'd love to see it. I don't for the life of me remember which articles I saw from which I got that impression of events; if you have better sources, I'd love to know about it. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpW0QF5sQrBw.pgp Description: PGP signature
Re: unintended?
On Fri, Nov 14, 2008 at 01:26:29PM +, [EMAIL PROTECTED] wrote: (snicker) from the local firefox en-us.add-ons.mozilla.com:443 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) What does Perspectives have to say? What installation of Firefox did you use? I don't have that problem when I visit: https://addons.mozilla.org/en-US/firefox/ Do you perhaps have some kind of malicious redirection going on there? -- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] John Kenneth Galbraith: If all else fails, immortality can always be assured through spectacular error. pgpmgpO99DbkE.pgp Description: PGP signature
Re: The perils of security tools
On Mon, May 26, 2008 at 11:22:18AM +0200, Simon Josefsson wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool. I believe a much better approach would be if /dev/urandom was a fast and secure PRNG, with perfect-forward-secrecy properties, and /dev/random was a slow device with real entropy (whatever that means..) gathered from the hardware. The two devices would share little or no code. The /dev/urandom PRNG seed could be fed data from /dev/random from time to time, or from other sources (like kernel task switching timings). I believe designs like this have been proposed from time to time, but there hasn't been any uptake. My understanding of the situation is that the way you get secure use of a PRNG is by feeding it real entropy, and the way you get fast use of a PRNG is by feeding it whatever seeds you have on-hand, regardless of real randomness -- or just don't feed it any seeds at all, if you don't have any on-hand. Thus, the reason /dev/urandom is fast is that it doesn't actually *require* real entropy, and the reason /dev/random is cryptographically secure is that it *does* require real entropy, which of course means that it slows down a lot when you run out of real entropy in the pool. Assuming I am not mistaken in my understanding of the operation of the two randomness devices, you could probably get reasonable security and speed overall for /dev/urandom by limiting how quickly and often it accesses the entropy pool, hitting it once in a while at (pseudo)random intervals within a reasonable range to seed the PRNG. This would make it fast unless you're taxing the entropy pool so badly with multiple processes using /dev/urandom or some /dev/random use that there literally is no entropy left in the pool for /dev/urandom to use at all when it tries to hit the pool. It would not provide perfect forward secrecy, however, because there would be brief intervals (between hits to the entropy pool) during which knowing the PRNG algorithm and its current state would allow someone to predict further PRNG output until the end of the current entropy interval. The length of the interval, however, could conceivably be (effectively) unknowable. Ultimately, I think the reason nobody has implemented a /dev/urandom that allows for fast, secure PRNG operation with perfect forward secrecy is that it's kind of a pick n-1 situation, such as with the old saw, Fast good, cheap; pick two. To get cryptographically strong randomness, you need entropy, which taxes the entropy pool. An additional entropy pool would need more places to *get* entropy, of course. Essentially, giving the characteristics of cryptographically useful randomness and perfect forward secrecy to /dev/urandom would ultimately mean you turned it into a duplicate of /dev/random. It looks like you're suggesting just changing the way /dev/urandom receives its entropy so that it happens periodically, similarly to how I described limiting it from exhausting the entropy pool above -- but that won't solve the problem of giving /dev/urandom strong security and perfect forward secrecy characteristics. . . . or is there something I missed? -- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] Baltasar Gracian: A wise man gets more from his enemies than a fool from his friends. pgp0tGmcL1okT.pgp Description: PGP signature
