[Botan-devel] Quick Tutorial Question

Jack Lloyd lloyd at randombit.net
Wed Oct 5 15:01:09 EDT 2005


On Wed, Oct 05, 2005 at 11:26:49AM -0700, Rachel Blackman wrote:

> Lemme try to put this more clearly, actually, since someone on the list 
> might have a brilliant idea on a better way. :)
[...]

Well, in this setup, your only real worry is what a compromised server or
client can do, since if someone can break TLS we have bigger problems. Things
that come to mind include:

 - The server can generate a message and claim it is from another client

 - A client can claim to be another client to the server, and either
     - Start receiving that client's messages, either ignoring them or
        responding to them blindly
     - Start sending messages to someone else claiming to be the wrong client

 - The server can repeat, reorder, modify, or drop messages. Nothing you can do
   about dropping in this case, and using RSA or ElGamal with OAEP, any
   modification should be detected, so those two can be mostly ignored.

 - A client can claim that a message supposedly from it originated elsewhere

So, basically, RSA+OAEP will get you confidentiality and integrity, but it
won't get you non-repudiation or source identification. This may or may not be
an issue depending on your exact environment. You could use signatures, but
that would mean two public key operations per message, which seems a little
pricey. Another way would be to use TLS client authentication, or just a
signature-based challenge/response protocol between the client and server after
the TLS connection is established, so the server can confirm that the client is
who it is 'supposed' to be at the start of things. Then it can annotate each
message that it relays with an identifier of the sending client, and as long as
the receiver trusts the server it can rely on that information.

-Jack



More information about the botan-devel mailing list