[jcifs] SMB Signing Sequence Counters

[Michael B Allen]

Eric wrote:
> It also gets strange since multiple threads can be throwing stuff
> at us (that's why I put separate sequence counters for signing and
> verifying; I had a single counter, but it all fell apart under
> multithreading because I would get i.e. 2 consecutive requests and
> lose sequence).

What would the sequence numbers be for the below 3 SMBs? From looking at
your code it looks like it should be something like the following:

send: SMB1 sign 0
send: SMB2 sign 2
send: SMB3 sign 4
recv: SMB3 vrfy 5
recv: SMB1 vrfy 1
recv: SMB2 vrfy 3

Is the verify sequence number of the response always 1 more than the
sequence number used to sign it's request (as shown above)?

If so, would it make more sense to put the verify sequence value in the
ServerMessageBlock class (i.e. keep the state with the object it
represents)?

We don't need the signingLock. If my reasoning is correct we can have one
signSequence counter and set a verifySequence in the response object. Then
we do all signing/verifying from within the snd_buf/rcv_buf locks. We can
initialize things as necessary from within this lock as well. That will
give us the concurrency we need and considering snd_buf and rcv_buf are
static it prevents their contents from changing during signing/verifying
(which I think might be a problem with the current code).

Mike

PS: java.util.Random is much faster. I also moved it to where
clientChallenge was actually required. BTW, I failed to mention yesterday
that there were serveral other threads in the monitor dump that looked
like they were trying to generate some kind of seed value. I also wonder
if Java 1.3 has the JCE providers that Java 1.4 has.

-- 
A program should be written to  model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the  potential for it  to be applied  to tasks that are
conceptually similar and, more  important, to tasks that have not
yet been conceived.