S/KEY OTP

You are to implement the S/KEY one-time password technique. You need not be compatible with the real S/KEY product, but if you want to, you are free to do so. Thus you may use whatever approach to the crypto you want. Keep in mind that you will need three primary components. The first component is the one that is used to generate the one-time password list, the second to select a password to send, and the third to receive a submitted password and either accept or reject it. You may also choose the usage model you want. One approach is to treat the password list as contained in a device the user carries. When they want to log it, they ask the device for a new password that it prints out. The user then types that password into the authentication side. If a textual interface isn't terribly interesting to you, you are free to implement the pair communicating over other modes such as named pipes or network channels.You design decisions should be documented in a design document. 

These will include such things as: what crypto technique you chose and

why, what communication model you chose and why, how do you handle what

happens if the authentication side reboots, how many passwords are

stored on the generator device, etc.  Similarly, you don't know if your

code is correct until you test it.  Write up your test plan and report.

What to turn in: the source code for all parts of your S/KEY system, and the documentation in an open format.