[jcifs] SMB Signing Sequence Counters

Michael B Allen mba2000 at ioplex.com
Fri Sep 12 13:45:28 EST 2003

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

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).


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.

More information about the jcifs mailing list