Encryption and risk

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org)]

> On Tue, Oct 6, 2009 at 7:57 AM,  <markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org> wrote:
>> I was thinking about this over night, and it really is both funny *and*
>> instructive for those with little security experience.
>
> precisely
>
>> There is practically no way to come up with a usable 100% secure system.
>
> True. The A1 certified Honeywell-Bull SCOMP was as secure and as
> usable with power on or off.

Funny
>
>> There will always be an exploit. If not through the encryption algorithm
>> itself, through the implementation.
>
> not exactly, that makes it sound pointless to strive for improvement

No not at all, just because it is "true" that there will always be an
exploit, something is "safe" until it isn't. When it isn't, you fix what's
broken. Then you have another period of "safe." That mind set really gets
to security people, but it is a zen thing. We try for the best, but humans
are imperfect thus everything we make, no matter how good, is imperfect.

>
> even a secure algorithm can be (a) badly implemented, or (b) embedded
> in a way that uses it wrong, picking wrong mode or inputs.
>
> using a quality peer-reviewed implementation of the crypto primitives
> protects you against (a).
>
> using a quality peer-reviewed implementation of use-case protocols
> (PKSI SSL etc) protects you against (b)
>
> even so, sometimes a bug is found and we all have to scurry -- one
> inglorious example was the debian not-so-random prng entropy seed that
> caused a large number of ssh keys to be identical.

Would you now argue that as computers become more and more powerful, that
brute force cracking becomes far less time consuming?

Sure, there are bugs, but anything that can be decrypted can be cracked
given a reasonable amount of CPU and delta T.


>
>> Take AES, and while my info may be dated, I still assume that it has not
>> been breeched algorithmically,
>
> correct, not even theoretically, although AES256 may not have enough
> rounds to be more secure than AES128, which some had feared.
>
>> but the breaches that have been sesen have
>> been around implementations.
>
> true, proof of concept implementations aren't armored, and need to be
> for production use.
>
>> The end result is the same, of course.
>
> no, same impact to one victim perhaps, but very different impact to
> the community. a cipher breach would potentially expose everything
> ever stored under AES protection, an implementation hack exposes the
> connection that is jimmied into.
>
>> MD5 has been broken. That was always mathematically possible, just
>> highly
>> improbable. GHZ processors make improbable somewhat more "likely."
>
> and some mental ghz multipliers too, some conceptual breakthrus have
> allowed efficacious application of the GHz .
>
>> If someone has custody of encrypted data for any non-trivial length of
>> time, you have to assume it can be broken.
>
> not unless non-trivial is measured in decades. DES was secure for a
> decade or more, as was 3DES, and AES128 should be -- provided not used
> in simple block substitution ECB mode

But....

"decades" is an interesting measure. Computers are how much faster than
they were a couple decades ago? Parallelism? Seriously, how much would to
cost to execute a ten year old "decades" worth of computing? The mid 80s
computers with almost laughable compared to todays systems.

The processing on old 8088 or 80286, hell even an old 80386 running for a
decade on a problem could be replicated how quickly on a modern quad core
system with lots of RAM and fast disk?



> http://en.wikipedia.org/wiki/Electronic_codebook#Electronic_codebook_.28ECB.29
>  which is just a 64bit Caesar cipher.
>
>  Important -
>   * key size allows for moores law and secrecy period required
>   * appropriate Mode for use
>   * key handling
>   * protocol avoids Man-in-the-middle (hard) and trojan-in-browser
> (harder)
>   * not reusing keys so the collected data isn't cumulative.

>
> --
> Bill
> n1vux-WYrOkVUspZo at public.gmane.org bill.n1vux-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
>