Hashing algorithm needed

Ben Laurie benl at google.com
Wed Sep 8 16:35:38 EDT 2010


On 8 September 2010 16:45, <flj at 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 majordomo at metzdowd.com



More information about the cryptography mailing list