Re: [Cryptography] Today's XKCD is on password strength.

2011-08-10 Thread Chad Perrin
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

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

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: ]

Description: PGP signature
The cryptography mailing list

Re: [IP] Malware kills 154

2010-08-24 Thread Chad Perrin
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,
  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: ]

Description: PGP signature

Re: unintended?

2008-11-14 Thread Chad Perrin
On Fri, Nov 14, 2008 at 01:26:29PM +, [EMAIL PROTECTED] wrote:
 (snicker)  from the local firefox 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:

Do you perhaps have some kind of malicious redirection going on there?

Chad Perrin [ content licensed PDL: ]
John Kenneth Galbraith: If all else fails, immortality can always be
assured through spectacular error.

Description: PGP signature

Re: The perils of security tools

2008-05-27 Thread Chad Perrin
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: ]
Baltasar Gracian: A wise man gets more from his enemies than a fool from
his friends.

Description: PGP signature