Re: Security Problems

Brad Knowles (brad@his.com)
Tue, 5 Mar 1996 01:27:46 -0500 

At 2:22 PM 3/4/96, Terry Ritter wrote:

>  I want to start out with some default cipher such as Triple DES.
>  Then I want a state-machine to exist to support negotiation as
>  messages are exchanged.  This can occur in just two round-trips.

    Meanwhile, you do no secure mail?  Why?  If the user has their
public key registered, and you have access to that registry, why not
start sending secure mail with the first message?

    And how are you going to do Triple-DES in Russia or France, both
countries that have flat outlawed any and all encryption that is not
explicitly approved by law in those countries?  These are countries
where Big Brother really does want to guarantee that he can
near-trivially decrypt each and every single message that comes
across the wire....

>  The need for a registry is a BIG MISTAKE.  Ciphers should be
>  identified by a textual name.

    But the central registry is what determines that
application/pgp-mime is an officially approved content-type, while
application/x-pgp isn't.  The labels are textual, but there is still
a need for a central registry to determine what is officially
approved and what is not, otherwise you create chaos.


    This is, of course, totally irrespective of any registration of
public keys, or certificates, etc....

> >    That's an online transaction-processing model.  Email is not
> >online transaction-processing.  It is store and forward.  Therefore
> >this basic assumption fails.
>
>  E-mail can be a form of "transaction-processing" when seen over
>  several message exchanges.

    So, meanwhile you do nothing while you wait days for the
transaction to complete.  I don't think so.

>  Starting out with a known cipher resolves this issue.  This was
>  in my original text.

    You can't assume that you can start with a known cipher without a
central registry (I use PGP, Jim uses MOSS, Mike uses PGP-MIME,
etc...).  Otherwise, you build in a dependance on one encryption
technology that could potentially see a world-shattering breakthrough
at any time (no matter what that encryption technology is).

    Let's say that you decide to start with Triple-DES. Let's say
that the entire world starts doing multi-trillion dollar amounts of
business with this technology.  Let's now say that, because of this
intense financial incentive, that someone builds a single-purpose
quantum computer that can crack any implementation of the DES
algorithm (or any of its variants) in a matter of a few seconds.
Suddenly, you've got a very serious problem -- you've got to rip out
all the existing infrastructure literally overnight, and replace it
with something else.


    Now, if you have a central registry, people only have to worry
that all their current keys are instantly compromised and tomorrow
register new keys based on a different algorithm.

>  I do indeed want each side to provide a reasonable list of ciphers,
>  say ten.  Then, if agreement cannot be reached immediately, perhaps
>  a substantially larger list.  If no agreement, then fall back to
>  "Triple DES".

    You obviously don't come out of the security-paranoid military
type of environment.  Publishing a list of encryption algorithms that
you know is a serious leak of information.  Since the other side
cannot be assumed to be trustable, you cannot leak that kind of
information.  You can find out what they've got publicly registered,
and they can find out what you've got publicly registered.  But, if
through some out-of-band communication, you decide to use some sort
of alternative algorithm, you need good guarantees that the nature of
this algorithm is hidden from *everyone* but the people with whom you
use it to communicate securely.

>  The ability to perform a cipher is *not* secure information.
>  Anyone who gets the program can do it.

    They can perform the encryption, sure.  And if they've got the
necessary key(s) they can perform the decryption.  But you
fundamental flaw here is your trust model -- you can never assume the
other side to be trustable, and therefore you have to guarantee an
absolute minimum amount of information exchanged between you other
than what is publicly registered and that which is explicitly
communicated by the end users to each other.

--
Brad Knowles,                                  MIME/PGP: brad@his.com
    comp.mail.sendmail FAQ Maintainer     <http://www.his.com/~brad/>
        finger brad@his.com for my PGP Public Key and Geek Code
The comp.mail.sendmail FAQ is at <http://www.his.com/~brad/sendmail/>