Encryption and risk

[Bill Ricker]

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.

> 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

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.

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