The more I think about it, the more I come to realize that the salt should never leave the server. It adds nothing, and takes away something. It's whole purpose is to make it somewhat harder to perform dictionary attacks against the password database. Transmitting it on the wire is just going to make it that much easier to assault the password file.
> Craig, Let's revisit your function - > > f(password + random garbage + timestamp, Bob's public key) > > Given our definition of nonce and salt what is "random garbage"? Random garbage = a string of random characters. Ideally, this would be cryptographically securely generated random numbers, since the default random number generator blows. > Who generates the "random garbage", The client. > and when? every time they send a password. > > Does the "random garbage" need to be shared, if so, how is > this achieved? Nope. On the server side, you decrypt the password + timestamp + garbage and just throw away the garbage. This assumes either a delimiter or a fixed length of garbage. I suggest you check out [1], which is the RFC for PKCS #1. Not only does it outline a standard way of doing this, but you'll need to use this if you want to decrypt the resulting cyphertext with the .NET Crypto APIs. [1] http://www.ietf.org/rfc/rfc2313.txt NB: It's a terrible idea to implement your own protocols! There is a high liklihood that a real cryptanalyst can come along and blow 20 holes in the ideas we're floating here. Unless you have a PhD in number theory, you're better off just using SSL. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
