[ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?)

[Michael Lawley]

Oops, just realised I replied only to David and not to ticker-dev.

Here it is again...

David Arnold wrote:

> -->"Martin" == Wanicki, Martin <Martin.Wanicki at Australia.Boeing.com>writes:

> Martin>In fact I'd prefer that the replacement option to be key
> Martin>based, so that only the bona fide originator of a
> Martin>notification has the right to recall or change the notif.

> i played, once, with using this kind of mechanism.  it's actually not
> dissimilar to the Bell Labs S/Key protocol.

> 1. sender picks the plaintext
> 2. sender picks how many times it want to replace the message
> (** this is the bad bit **)
> 3. sender hashes the plaintext, and then hashes the result, and that
> result, etc, N times (from step 2).
> 4. for the first message, use the final hash and then work
> backwards through previous hashes.

> this works because the hash function is one-way, so having seen a
> message, a receiver cannot derive the hash of its replacement, but
> when it gets the replacement, if its REPLACEMENT field hashes to the
> REPLACEMENT of the previous message, it's legitimate.

> the big limitation is that the sender need to know up front how many
> times you want to do this.

If you separate the REPLACEMENT field as the key for which message to
replace from the REPLACEMENT_HASH field, then you only ever need to do
one-step replacement so N=1 and it's "easy".

So, the process is now, choose a UUID for REPLACEMENT.
Choose a plaintext and hash it, send the hash as REPLACEMENT_HASH.

To replace this message, send a message with REPLACEMENT = UUID
from before, REPLACEMENT_PLAIN = plaintext from before, and 
REPLACEMENT_HASH = a hash(new plaintext)

(Actually, UUID could just be hash(plaintext), but keeping it constant
should make it easier on the ticker client.)

|v|					"analog - the new digital"

--
	Michael Lawley,			http://purl.org/NET/lawley
	Scientician.