Re: [Exim] OT: TLS encryption strength

> Richard Welty wrote:
> > On Mon, 10 Mar 2003 09:16:20 +0000 Giuliano Gavazzi <eximlists@???>
wrote:
> >
> >>I was just concerned about password protection. I hope RC4
> >>vulnerability still requires a pretty determined person and that the
> >>tools to break it do not come shrink-wrapped off the shelves.
> >
> >
> > for an extremely short transaction, there's not much text to attack.
>
> I'm not an crypto-expert, but I think the general problem with ESTMP-TLS
> is that some of the text is known.
>
> So one can MAYBE run a known-plaintext attack against the encryption,
> but like I said, I'm not an expert in this field :)
>
> Nico
>

I don't suppose there is any way to ONLY encrypt the AUTH step, and not bother
to encrypt email data? On the theory that the email is probably not going to
be encrypted over at least part of it's journey anyway, since not all servers
support TLS...

Would it be more or less difficult to crack an encrypted username/password
combo if it was the only encrypted part of the session? I am thinking that,
the shorter the encrypted message, the harder it is to crack? Plus, it would
be faster for both client and server, in terms of not having to
encrypt/decrypt the bulk data. I am sure that is a minor piece of the pie,
and the bulk of the exercise is in negotiating the encryption keys. But
still...

OK, let me take this line of thought one step further... Let's say an
authorized user sends a piece of email through your server. He/she
establishes TLS, then authenticates. Everything after STARTTLS is encrypted.
Cool. Now, let's say this mail is destined for a server which does not
support TLS, so Exim dutifully relays the mail in plaintext. Not a problem,
because the username/password are not in the relayed message, right?

But now, let's say some shadowy eavesdropper is lurking about, and manages,
perhaps by counting bytes and/or timing, to associate the original encrypted
session with the outgoing (relayed) plaintext session. Now, the evil bad guy
has both an encrypted and unencrypted copy of the same message. Although not
identical content (only one session has the user/pass, for one thing!), if it
is long enough, I bet it could be cracked, and thus the original user/pass
combo retrieved.

I guess I am suggesting that, cryptographically speaking, it would be better
to encrypt the user/pass separately from the rest of a message (i.e. with
different keys).

Utter paranoia, I am sure. But, I present this for group cogitation.

Jim Roberts
Punster Productions, Inc.