How effective is open source crypto? (bad form)

[Anne & Lynn Wheeler]

At 09:30 AM 3/16/2003 -0800, Eric Rescorla wrote:

>Correct.
>
>It's considered bad form to design systems which have known replay
>attacks when it's just as easy to design systems which don't.
>If there were some overriding reason why it was impractical
>to mount a defense, then it might be worth living with a replay
>attack. However, since it would have only a very minimal effect
>on offered load to the network and--in most cases--only a marginal
>effect on latency, it's not worth doing.
>
>-Ekr
>
>--
>[Eric Rescorla                                   ekr at rtfm.com]
>                 http://www.rtfm.com/

so, lets look at the alternatives for servers that are worried about server 
replay attacks:

client has public key & crypto-preferred info (dns or cached), generates 
random secret key, encrypts request, encrypts random secret key, single 
transmission

server gets request ... application has opened the connection with or w/o 
server replay attack. if the application, higher level protocol has its own 
repeat checking .... it has opened the connection w/o server replay attack. 
and the server sends the request up the stack to the application. If the 
application has opened the connection with server replay attack, the 
protocol sends back some random data (aka its own secret)... that happens 
to be encrypted with the random key.

The client is expecting either the actual response or the replay attack 
check. If the client gets the actual response, everything is done. If the 
clients gets back the replay attack check .... it combines it with 
something .... and returns to the server.

The difference is basic two packet exchange (within setup/teardown packet 
exchange overhead) plus an additional replay prevention two packet exchange 
(if the higher level protocol doesn't have its own repeat handling 
protocol). The decision as to whether it is two packet exchange or four 
packet exchange is not made by client ... nor the server ... but by the 
server application.

Simple example for e-commerce is sending a P.O. along with payment 
authorization ... the transmitted P.O. form is guaranteed to have a unique 
identifier. The P.O. processing system has logic for handling repeat POs 
... for numerous reasons (not limited to replay attacks).

Single round-trip transaction:

ClientHello/Trans->
                         <- ServerResponse/Finish

Transaction w/replay challenge:

ClientHello/Trans->
                         <-Server replay challenge
ClientResp->
                         <-ServerResponse/Finish


Now, ClientHello/Trans can indicate whether the client is expecting a 
single round-trip or additional data.

Also, the ServerResponse can indicate whether it is a piggy-backed finish 
or not.

So, the vulnerability analysis is what is the object of the replay attack 
and what needs to be protected. I would contend that the object of the 
replay attack isn't directly the protocol, server, or the system .... but 
the specific server application. Problem of course, is that with generic 
webserver (making the connection) there might be a couple levels of 
indirection between the webserver specifying the connection parameters and 
the actual server application (leading to webservers always specifying 
replay challenge option).
--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
   
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com