Jim Starkey wrote:

> [...] If it were possible to compute the key from a finite
> number of { plaintext, cryptotext } pairs, then you would
> have an argument. But since it is near universally regarded
> that this isn't possible, you are on thinner ice.

I'm not going to argue the details of how possible or not
it is to extract the key given plaintext/ciphertext pairs,
the truth is that I don't have the expertise for that.
(Although I would suggest that "near universally regarded" is
something of an overstatement given the number or articles
available about exactly this process.)


My previous posts were trying to highlight two main points:

1. Poor implementation choices can give away a lot of
information about what you are protecting without ever having
to do anything so difficult as brute-force the key. (Exactly
how much depends on exactly what you're protecting.)

My overly simplistic analysis suggests that it may even, for
example, be possible to extract (still encrypted) blobs from
a database encrypted with ECB. If those blobs were images
then this link:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
shows you one possibility of what ECB may have revealed,
there are lots of others.

(All hypothetical but why allow this risk when when there are
excellent alternatives.)


2. Poor implementation choices can be avoided _IF_ you
bother to learn something about encryption and the best ways
to implement it in particular circumstances.
Given your assertion that "And, no, a developer doesn't have
to understand the crypto to use it," it seemed a relevant
point to make - especially since you were offering to mentor
others in this area.


--
Geoff Worboys
Telesis Computing