[360] in WWW Security List Archive
Re: Experimental implementation of SimpleMD5
daemon@ATHENA.MIT.EDU (Mary Ellen Zurko)
Mon Jan 30 17:36:34 1995
From: zurko@osf.org (Mary Ellen Zurko)
To: www-security@ns2.rutgers.edu
Date: Mon, 30 Jan 95 12:04:01 EST
Cc: zurko@osf.org (Me)
In-Reply-To: <95Jan26.050014gmt+9(?illegal end of message identification?) :00.; from "Phillip M. Hallam-Baker" at Jan 26, 95 4:49 am
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
> On the nonce question :-
> ------------------------
>
> The CERN server is forking. Under the UNIX madness there is no threads
> systems we can expect to work for reference code - extreeme :-(. This
> means that connections *have* to be idempotent. So the use of nonces becomes
> a problem, how do we work out which nonces we have sent out??
Another vector, if you're still considering nonces; if they're not
meant to be confidential (and I couldn't tell if they were meant to be
or not), clients could always use "last nonce + n" for the return
trip, with "n" in the clear. So, if the client increments a little
more than the server, it doesn't matter.
> This being the case I would prefer to dispense with the nonce value idea and
> use a timestamp :-)
So this is a timestamp as a nonce, so that the clock skew between
server and client doesn't matter? Or does the clock skew matter, so
what is it? Glancing back at your on-line proposal, I find only that
the timestamp is not currently checked, not how it will be.
Mez
