> Please feel free to review the code once it is finished (it isn't), some already have already provided comments:
This is only useful if you can convince as many people to review your code as have reviewed SSH/TLS. Those protocols both contained bugs which survived dozens of man-years of review. You are not smarter than the entire cryptographic community. Have you read your Ferguson & Schneier (& Kohno)? What's your rekeying time? Do you know what that is and why it matters? Now that I've said that you can look it up and patch one obvious hole, but there will still be a dozen more.
> I think the authors of SPEKE would beg to differ...
WTF, do you not even understand the difference between a crypto primitive and a crypto protocol? SPEKE is a fine primitive (well, there are better ones, but that's actually besides the point). But it doesn't matter if you choose good primitives. If design your own protocol YOU WILL FUCK IT UP AND CHALLENGING PEOPLE TO REVIEW IT WILL NOT SAVE YOU.
Most snake oil vendors honestly believe that their code is great! And advertise them by boasting about using cool primitives (AES! SPEKE! XX-bits! never mind that they're used insecurely!). And then when someone point this out, the snake oil vendor always responds by challenging them to review the code and point out specific problems. Srsly you're exhibiting the classic symptoms. Stop and think about it. Spreading bad crypto is a sin.
> Please do consider the differences between the ssh/tls model and speke
Please read my fucking message. I said you should use TLS-SRP. That has the same model as the protocol you are ineptly trying to design. Yes, it requires you to deal with the gnutls api instead of playing around with fun maths, but on the other hand IT IS DESIGNED AND IMPLEMENTED BY PEOPLE WHO KNOW WHAT THEY ARE DOING AND IT WILL ACTUALLY FUCKING WORK.
(Just one example - SPEKE requires the server store passwords in plain text, which we've had *plenty* of evidence lately is a terrible idea. SRP avoids this problem.)