Re: Keyed-MD5, ITAR, and HTTP-NG

How are you going to handle mechanism negotiation?

>How are you going to handle mechanism negotiation?

This is a must do item, Simon is haviung to do >lots< of this.

One way of looking at HTTP is as a huge negotiation mechanism. Another way to
look at HTTP is as a large dougnut with sugar frosting, the first is more widely 
accepted.


There has to be more than one crypto mechanism so don't chose. In fact I forgot to 
add our favourite algorithms, such as Skipjack in OFB mode to the list :-)


What DES modes should be bothered with? I always feel that the lumping in of every 
cipher mode under the sun is an irritation. We need a transparent cipher, looking 
very much like a stream cipher (hence the probable reason for Simon hankering after 
RC4). We could use CFB or OFB. 

I don't like OFB myself, it seems to be a bit lame to only XOR a stream of pseudo 
random stuff with the plaintext. CFB also has the stream cipher like property that 
incomplete blocks can be decoded provided that the stride is set right, this means 
that for a 64 bit block cipher one is 8 time slower :-(


Anyone any ideas on the following ?

SEQ
    x = IV
    SEQ
    	c[i] = E(x,K) XOR p[i]
    	x = c[i] 

This is essentially OFB mode but instead of having an XOR with an alledged random 
number generator (which I find disturbing), there is a mix in of the output.

Other mixes to try ?

	x = c[i] XOR E(x,K)

OFB is the following BTW :-

	x = E(x,K)


Note that there may be value in keeping the IV secret in this case. There is probably 
some hack that means that the IV can be finessed but it looks like work.

		Phill

[Short response, because I'm at home. More details tommorow ]

On Tue, 31 Oct 1995 hallam@w3.org wrote:

> 
> >How are you going to handle mechanism negotiation?
> This is a must do item, Simon is haviung to do >lots< of this.

Just to clarify: one of the most important parts of the design is the 
negotation mechanism, so a lot of effort has gone into these mechanisms. 
The aim is to _not_ have to do lots of RTT negotations through the use of 
caching and dynamic profiling. The negotation facilities in HTTP 1.0 are not 
used, not because there isn't a need for them, but because they don't 
offer sufficient power, and are much too inefficient. 

Oh, and when I say dynamic profiling, I'm referring to semi-standard 
profiles that can be obtained over the network, not to OSI style 
dead-trees. Deriving negotiated feature sets from a profile works really 
well for applications like the WEB, as a vast amount of this information 
remains the same for all copies of a particular version of a Browser. For 
example, all copies of hotjava support html 1.0, some netscape 
extensions, and can handle inline gifs, but not inline jpegs; alpha 
hotjava supports the alpha applet API. 

Simon
---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))