In some email I received from antirez, sie wrote:
>
> On Thu, Oct 21, 1999 at 08:58:25AM +1000, Darren Reed wrote:
> >
> > I have one problem with this: it requires changes/additions to the original
> > message. This poses some obvious problems when you start adding MAC's of
> > the original message, etc, to what's being sent around.
> >
> > SMTP supports that sort of thing with additional information added in the
> > "Received" lines, but then we all know how secure/reliable SMTP is by
> > itself.
>
> I think that we can insert the hash into the message itself without
> security risks. For example an entry like the following is only more dirty:
> "in.ftpd[9077]: connect from 127.0.0.1 <2290babda371e52eeca2a2065a358783>"
> Collisions can be avoided (in the case the logged line has a <32digits>
> string)
> simply requiring that at least one of this strings matchs the
> HASH(msg+secret).
> Maybe that without changes/addictions to insert the hash in the message
> itself is the only solution, also is backward compatible.
Ah, no.
What I was addressing was the insertion/addition of timestamps into the
message from hops B & C when a message goes through them from A to D.
If A sent the above message, it would include the timestamp at the front,
before the "in.ftpd". That timestamp is part of the data which we want
to `sign', otherwise we have an ftp connect message (which we can prove
is authentic) but we cannot be sure of when it was sent. When you compute
the hash, you must include everything that you need to rely on. This will
include the message itself, of course, and should also include other meta
data such as originating host, time it was generated, facility/level, etc.
Given this, if you want to add timestamps from B & C to the message, you
either remove the MAC that A (and B) put on the message when it gets to
C or both B & C add their own timestamp and MAC on the end of the message,
which covers the rest of the message.
Darren
