I've always thought that a Java implementation of public key encryption would be useful.
For example, I'd like to be able to put up a page on my web site containing a Java applet with my embedded public key.
That way I could finally remove my grandmother's AOL account from the exception list, the last obstacle standing between me and my "all incoming mail must be either signed by somebody I trust or encrypted with my public key" procmail rule.
Requiring the sender to use their own CPU cycles to encrypt messages is a classic variation on the "micropayments" approach to reducing spam volumes...
I've been poking around trying to generate Web-site passwords by hashing the hostname and a master password, and I've come up with this bookmarklet which takes the first 8 chars of the hex representation of the MD5 hash.
This means you only have to remember one master password, and each site you register for gets its own unique password - instead of using the same throwaway password all over so you've given your whole online identity to each site's admins...
I've been meaning to find a crypto guy to ask if I could just use CRC32 to hash the input string, since MD5 is too much Javascript to bookmark in IE. I know it's not a secure way to checksum a file, but given a CRC32 hash and part of the input, can you recover the other part? Anybody?
Similar techniques are in use already
by
gusnz
·
· Score: 5, Interesting
Have a look at Yahoo Mail's login page (you may have to log out of Yahoo services completely to see it). If you view source on that, you'll see:
/*
* A JavaScript implementation of the RSA Data Security, Inc. MD5 Message
* Digest Algorithm, as defined in RFC 1321.
* Copyright (C) Paul Johnston 1999 - 2000.
* Updated by Greg Holt 2000 - 2001.
* See http://pajhome.org.uk/site/legal.html for details.
*/
They're using a JS implementation of the MD5 algorithm to calculate client-side hashes of user passwords before form submittal.
It's definitely an interesting approach especially of a site that size, when you look at how much server CPU usage a full SSL login connection would take. And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.
Plus, JS is free to implement (unlike a SSL cert) so hopefully if this technique catches on, more mom-n-pop sites will wind up using it instead of a totally unencrypted login connection.
Slashdot Mirror
For example, I'd like to be able to put up a page on my web site containing a Java applet with my embedded public key.
That way I could finally remove my grandmother's AOL account from the exception list, the last obstacle standing between me and my "all incoming mail must be either signed by somebody I trust or encrypted with my public key" procmail rule.
Requiring the sender to use their own CPU cycles to encrypt messages is a classic variation on the "micropayments" approach to reducing spam volumes...
I do not deploy Linux. Ever.
I've been poking around trying to generate Web-site passwords by hashing the hostname and a master password, and I've come up with this bookmarklet which takes the first 8 chars of the hex representation of the MD5 hash.
This means you only have to remember one master password, and each site you register for gets its own unique password - instead of using the same throwaway password all over so you've given your whole online identity to each site's admins...
I've been meaning to find a crypto guy to ask if I could just use CRC32 to hash the input string, since MD5 is too much Javascript to bookmark in IE. I know it's not a secure way to checksum a file, but given a CRC32 hash and part of the input, can you recover the other part? Anybody?
It's definitely an interesting approach especially of a site that size, when you look at how much server CPU usage a full SSL login connection would take. And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.
Plus, JS is free to implement (unlike a SSL cert) so hopefully if this technique catches on, more mom-n-pop sites will wind up using it instead of a totally unencrypted login connection.
<!-- DHTML / JavaScript menu, popup tooltip, Ajax scripts -->