[jcifs] SMB Signing Sequence Counters

[eglass1 at comcast.net]

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

I *think* so; I'm not sure if there was coverage for that scenario in the tests
I did or not (I know it tested multiple requests in a row, i.e. not just
alternating request-response, but I don't know if it encountered out-of-order
requests).

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

That sounds preferable (assuming it works properly); if you have this coded,
I can test it here.

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

This makes more sense in light of Oleg's comment.  Moving the
clientChallenge is probably fine; just make sure that it is only generated
once.  Previously, I was generating a new clientChallenge for each call to
getLMv2Response, i.e. doing random.nextBytes() every time; while this is more
secure, in that each response has a different client nonce, it was/will prove
unwieldy when the same nonce needs to be used later for i.e. the NTLMv2
response.

Eric