begin  quoting Tracy R Reed as of Fri, Sep 15, 2006 at 11:23:31AM -0700:
> John H. Robinson, IV wrote:
> >Ya know - people used to think this. Then they learned that having
> >encrypted (well, hashed) data out in the open was A Bad Thing. Now we
> >have /etc/shadow.
> 
> But that was not encrypted. It was only trivially hashed.

Um, no.

The has is generated by repeated applications of DES.

Not trivial then. It's only trivial now because of the resources
we have available to throww at the problem.

John's point is that computer power has grown enough to render the
UNIX hashed string susceptible to brute-force attacks.

> >Encryption slows the bad guys down, it does not stop them. Better
> >encryption slows them down further. The stronger the encryption, the
> >more dedicated you need to be.
> 
> I can understand why you would repeat this mantra as a security 
> professional and a purist which I am all in favor of but we have to be 
> realistic and start saying things like "For all practical purposes..." 
> at some point.

For all practical purposes, a decade seems sufficient time to crack
just about any encryption scheme.

> >When your laptop is stolen, do you know who stole it? Do you know how
> >dedicated they are? Are you certain you did not inadvertently make the
> >crytopgraphers job easier by choosing a passphrase that weakens the
> >algorithm? How do you know you did not?
> 
> No but it is far more likely to be stolen by clueless hoods than by the 
> feds or the Illuminati or some such group. In the highly unlikely event 
> that a cryptographer ever looks at something I have encrypted I use 
> passphrases with high entropy and choose algorithms which are less 
> vulnerable to that sort of thing.

Many assertions, little evidence.

And assuming your enemy is stupid is perhaps the most stupid thing you
can do.

I think it's far more likely that a laptop will be stolen either by
an identity thief, or that an identity theif will be the most willing
purchaser of a stolen laptop.

When evaluating risk, you don't just consider the liklihood. You need
to also consider the consequences.  Low-probability events can carry a
high risk, and high-probability events can carry low risk, depending on
the consequences.

> >Today's toughest encryption is tomorrow's quiant algorithm. CPU power
> >growse, and grows fast. Brute force attacks get easier. Attacks against
> >algorithms get more sophisticated.
> 
> This is true to a point. But there has to come a point where we say 
> "This crypto is the best I can do for now and it's better than nothing."

There's always better encryption, it just costs more.  You have to make
a tradeoff.  "This is the best I can do taking in account the keysize,
performance, bloat, general utility, recoverability, and the various
risks that affect the issue."

In time -- and generally less than you'd think -- there will be people
with the ability, resources, and interest in cracking your system. How
far in the future do you want that to be?

-- 
_ |\_
 \|


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to