On 8 September 2010 16:45, <f...@mail.dnttm.ro> wrote:
> Hi.
> Just subscribed to this list for posting a specific question. I hope the 
> question I'll ask is in place here.
> We do a web app with an Ajax-based client. Anybody can download the client 
> and open the app, only, the first thing the app does is ask for login.
> The login doesn't happen using form submission, nor does it happen via a 
> known, standard http mechanism.
> What we do is ask the user for some login information, build a hash out of 
> it, then send it to the server and have it verified. If it checks out, a 
> session ID is generated and returned to the client. Afterwards, only requests 
> accompanied by this session ID are answered by the server.
> Right now, the hash sent by the browser to the server is actually not a hash, 
> but the unhashed login info. This has to be changed, of course.
> What we need is a hashing algorithm that:
> - should not generate the same hash every time - i.e. should includen 
> something random elements
> - should require little code to generate
> - should allow verification of whether two hashes stem from the same login 
> data, without having access to the actual login data
> We need to implement the hashing algorithm in Javascript and the verification 
> algorithm in Java, and it needs to execute reasonably fast, that's why it has 
> to require little code. None of us is really into cryptography, so the best 
> thing we could think of was asking for advice from people who grok the domain.

Well, you can't always get what you want.

What I do in Nigori for this is use DSA. Your private key, x, is the
hash of the login info. The server has g^x, from which it cannot
recover x, and the client does DSA using x.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to