RE: Nonrepudiation - in some sense

[Weger, B.M.M. de]

Hi all,

  server, and re-encrypting the information. Moreover, it
  maintains the non-repudiation of transactions since the
  encrypted communication is between client and application with
  no proxy acting as middleman.
 
 Firstly, even if you believe that _any_ crypto provides 
 non-repudiation
 (see http://www.apache-ssl.org/tech-legal.pdf for a paper I 
 co-authored
 on this and other stuff - executive summary: I don't believe it), you
 can't maintain the non-repudation of SSL because it doesn't provide
 non-repudation.
 
 Secondly, obviously, you can only decrypt SSL if you have the private
 key, so presumably this is referring only to incoming SSL connections.

Moreover, it seems to me that:
1. it is misleading (at least in general) to state that SSL operates 
   between client and application. SSL operates between client
(browser) 
   and (web) server; in many cases the real application might be on 
   another server, way behind the point where the SSL connection
terminates.
   Are there any SSL-aware applications (i.e. implementing business
logic
   rather than providing communication services) for which this solution
   may be useful?
2. it is misleading to state that SSL secures transactions. SSL
secures
   sessions. The authentication of SSL applies only to the session
handshake,
   not to the exchanged data, in which transaction data might be
present. 
   This is why (as Ben remarks) SSL does not provide non-repudiation.
3. with this solution you need your private key in at least two
different 
   places. This introduces essentially more complicated key management,
   and increases the risk of key compromise.

Grtz,
Benne de Weger

=
Technische Universiteit Eindhoven
Coding  Crypto Groep
Faculteit Wiskunde en Informatica
Den Dolech 2
Postbus 513
5600 MB Eindhoven
kamer:  HG 9.84
tel.:   (040) 247 2704, bgg 5141
e-mail: [EMAIL PROTECTED]
www:http://www.win.tue.nl/~bdeweger
=

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: general defensive crypto coding principles

[Jack Lloyd]

On Fri, Feb 10, 2006 at 07:21:05PM +1300, Peter Gutmann wrote:

 Well, that's the exact problem that I pointed out in my previous message - in
 order to get this right, people have to read the mind of the paper author to
 divine their intent.  Since the consumers of the material in the paper
 generally won't be expert cryptographers (or even inexpert cryptographers,
 they'll be programmers), the result is a disaster waiting to happen.

I would expect that typically implementors would be following a published
standard, which would (well, one would hope) have had expert cryptographers
check it over sometime prior to publication. If your typical application
programmer is just coming up with their own crypto protocol, I personally don't
consider it to be a valid concern because they will with overwhelming odds
completely botch it in any case, and usually in a much less subtle way than
this.

(Actually offhand I can't think of a single non-cryptographer-designed crypto
protocol I've seen that wasn't fundamentally broken, often in a fairly obvious
way. I could believe there have been a few, but the odds seem very much against
it.)

-Jack

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]