On 12/09/15 11:22, Kurt Roeckx wrote: > On Sat, Sep 12, 2015 at 12:20:52AM +0100, Matt Caswell wrote: >> Dependant on the preceding messages we >> might need to have a CertificateVerify next. So transitions are actually >> "guarded" - there is logic which determines whether a particular event >> is "allowed" in the current scenario or not. > > Does that just not mean you don't have all the states as real > states, but that you're combining 1 state with something like a > variable to determine between other states inside that state?
Yes, that is an excellent point and is indeed correct. I am "cheating" a little by introducing guarded transitions. The implementation of these guards inevitably goes off and inspects state that is held outside of the state machine itself. The kind of state I'm talking about here are things like the current ciphersuite; what extensions have been sent/received; whether the client has sent a Certificate or not; etc. It would of course be entirely possible to build a state machine which did not rely on any of this external state - *all* of the state would be locked into our current position within the state machine. For example, this might mean that you need a different set of states and transitions for handling (say) PSK ciphersuites to the set of states and transitions that you need for other ciphersuites. As you can imagine (and as you pointed out) this could lead to a real explosion in the number of states that you need. There's more to it than just that though. In the state machine as I have designed it the events that trigger transitions are quite simple and the code can be generic for handling them (at least for reading messages): an event is simply the arrival of a message of a particular type. In this new extended state machine that we are imagining where there are many more states, the events are more complicated in order to distinguish between the many more different transitions that we can now make. So for example in my state machine an event might be "a ServerHello message has arrived", whereas in the extended state machine the event might be "a ServerHello with a PSK ciphersuite selected has arrived". This now means our event detection logic is much more complicated - and is state specific. All we have done is moved complexity out of the transition guards and into the state machine structure *and* the event detection code. On balance I think such an approach is not a good trade off. I much prefer the simplicity of a one-to-one correspondence between messages and states. Doing it the other way is much more likely to turn into a code maintenance nightmare IMO. Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
