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...
Javascript insecurity
by
Anonymous Coward
·
· Score: 3, Interesting
Since javascript has to be the second biggest backdoor into your computer since MS Windows, it never ceases to amaze me that people can take this stuff seriously.
I've used javascript cryptography routines before, once in a php project for authentication, used javascript to generate an md5 hash of the password and sent the hash over http.
I considered it a hack, but it's what the client wanted, and who am I, the developer, to question the client's motives? Cheap bastard, didn't want to pay for an SSL cert. Just hope no one passes the hash.;)
I don't see why this is a problem for *hiding passwords*, but the hash can be intercepted and replay attacks can be done. What you should do would be to have the client request a single-use time-limited challenge nonce from the server and hash the password together with it, and compare with the original.
Javascript not just for Clients
by
yomahz
·
· Score: 3, Interesting
There are a number of servers that support server-side javascript. I recently had a project where a remote office needed to communicate with a servlet based webpage using RC4 ecnrypted parameters.
The remote office didn't know much programing so I wrote a RC4 and base64 implementation in Javascript for them to implement server side.
Well, you could just start up a cert org for producing Javascrypted certificates. Being a certification organization is primarily a trust issue. Open up your certification procedures, i.e. do you check an applicant's credit card, do you retain copies of drivers license, etc, or do you only require an email address, etc. Get yourself backed by an org like Truste, who will vouch for your integrity, etc. Then lobby for Microsoft, Netscape, and Mozilla to accept certs issued by you as valid, and you're ready to go. The technical issues behind creating a certificate are easy. If you want to read more into this, I suggest Googling for the Java 2 certification production scheme, etc. You can probably write up a quick scheme to create certs, sign them with your key, etc. After all, what is a cert? It's simply a document saying "Yup, site ______ can be trusted", signed with your private key. Then any MS, Netscape, or Mozilla client can simply validate the certificate using a widely available public key.
I've often wondered a little about the demand for ultra high powerd crypto for e-commerce. It's all good in theory, but when people happily send their credit card number to any random website claiming to seel stuff that does an SSL connection, just what is the point?
I seem to recall a quote about armoured cars being used to deliver a package from someone living under a bridge to someone living in a cardboard box.
And can someone explain to me again why some people still persist with giving their credit card numbers over the phone "because its more secure"?
Until the ideas actually sink in at a deep cultural level, we will continue to have all manner of stupid and contradictory actions from people who don't have the time to understand how all of this works. Hopefully it'll happen soon, right?
Nice approach
by
randall_burns
·
· Score: 3, Interesting
This stuff is nice because Javascript is a very accessible language(i.e. lots of people know it). This is stuff that can be maintained in situations where other approaches aren't really practical.
I'm also glad to see folks doing more with the capabilities within a browser. The folks that are taking this the furthest that I've seen are the folks at Technical Pursuit.
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?
I think that is the entire point. Some businesses only put just enough effort into anything to make sure they won't get sued.
Vendors of e-commerce packages come to mind. Their software makes just enough effort so that if anything goes wrong it's going to happen on the end-systems and is therefore be the fault of operator / client / user.
Plausable deniability, etc.
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.
Re:Similar techniques are in use already
by
BlueFall
·
· Score: 2, Interesting
That's cool to know, but I don't think that this is true:
And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.
If you look at the code on the site, they have a 'challenge' value that is appended to the hash of the password, so to calculate the challenge response you need both the 'challenge value' (a.k.a. a nonce) and your password. The server needs the same thing. I think that this same technique is used in APOP.
The only way that they wouldn't need some shared secret is if you used some sort of asymmetric signing protocol, but then key distribution is a problem...
Why this is useful
by
EmCeeHawking
·
· Score: 3, Interesting
I see a lot of posts here wondcering how this is useful and why not just use PGP.
I can't imagine people really trust PGP anymore. No longer open source, no longer affiliated with Phil Zimmerman... and his statement when he left was scary.
For those who don't know, Phil stated when he left that every PGP product released while he was there contained no hidden back doors. Knowing that companies like PGP were being pressured, it makes me think the creative differences were them wanting to build something in that he thought shouldn't be in.
Re:JavaScript RULEZ!!1!
by
S.Lemmon
·
· Score: 2, Interesting
The main problem is it's *almost* elegant, but not quite 100% there - in actualy use it always seems like you need some ugly half-assed hack to do something that should be simple.
For example, say in a form you want to validate a field as soon as the person enters it (i.e. they type a bad value and it returns focus to the field). Sounds simple right? Just trap the onblur event, test the field, and call focus() if it fails.
Not so... most browsers will ignore focus called from within onblur (because the "blur" happens after the event fires, and you can't stop it). You wind up with the silly, messy hack of setting a timer to call focus() a few milliseconds later. Really, this makes onblur almost useless for the main thing you'd expect to use it for!
It's quirks like this that makes you pull your hair out trying to do anything serious with javascript. I sometimes wonder if those setting the standards have actually ever eaten their own dog food (as the Mozilla folks like to say).
Re:Nope
by
Anonymous Coward
·
· Score: 1, Interesting
Also, key distribution is not a problem with public key systems.
Sure it is. I am your bank. This is your bank's public key. Now encrypt your wire transfer details and deposit some of that sweet green wampum, baby!
It's so much of a problem that Certificate Authorities can exploit their positions to turn doing practically nothing into a goldmine, and even then they screw up sometimes and get social-engineered into issuing key pairs to people who are not the convicted monopolists they claim to be.
Cool, but it needs a net connection
by
CurbyKirby
·
· Score: 2, Interesting
Stealing and modifying some RC4 code, I made a self-contained Javascript/PHP CipherSaber encoder/decoder.
Boring I know, but at least it can create self-decrypting HTML files where the ciphertext and decryption code is all self-contained. With such output, any* JS-enabled browser can decrypt the file without a net connection. Here's a sample (use password "test" and 1 loop). This idea can be modified to fit almost any encryption scheme; RC4 just seemed like a good mix of security and extreme ease of implementation at the time.
* This is almost guaranteed NOT to work on Safari in Mac OSX. It works on recent Firebird builds under Windows XP and RedHat 9 (and probably other things as well).
--
--
"Extra Anus Kills Four-Legged Chick" -- Headline
Useful teaching tool
by
ca1v1n
·
· Score: 4, Interesting
Schneider's javascript Rijndael implementation makes a great teaching tool, because it's so easy to modify it to show intermediate steps. Sure, you can do this in any other language, but it's especially compact in javascript, and anyone who has ever programmed in ANY modern language can read javascript, which cannot be said of plenty of other languages. For my architecture class we had to implement Rijndael with synthesizable modules, and that implementation saved us countless hours, because it was so easy to tweak things in the javascript implementation that we could often save time by deliberately introducing bugs into the reference implementation and seeing if it had familiar effects. Anyone who's ever used FPGA Advantage probably knows how much of a pain in the ass it can be debugging with that alone.
Similar thing for Flash ActionScript
by
dodell
·
· Score: 2, Interesting
I created a similar thing for Flash ActionScript called ActionCrypt; although it's still in progress. You might want to check it out; Javascript and ActionScript are very similar (as they're both based on the same syntax).
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.
Since javascript has to be the second biggest backdoor into your computer since MS Windows, it never ceases to amaze me that people can take this stuff seriously.
I've used javascript cryptography routines before, once in a php project for authentication, used javascript to generate an md5 hash of the password and sent the hash over http.
;)
I considered it a hack, but it's what the client wanted, and who am I, the developer, to question the client's motives? Cheap bastard, didn't want to pay for an SSL cert. Just hope no one passes the hash.
There are a number of servers that support server-side javascript. I recently had a project where a remote office needed to communicate with a servlet based webpage using RC4 ecnrypted parameters.
The remote office didn't know much programing so I wrote a RC4 and base64 implementation in Javascript for them to implement server side.
"A mind is a terrible thing to taste."
Well, you could just start up a cert org for producing Javascrypted certificates. Being a certification organization is primarily a trust issue. Open up your certification procedures, i.e. do you check an applicant's credit card, do you retain copies of drivers license, etc, or do you only require an email address, etc. Get yourself backed by an org like Truste, who will vouch for your integrity, etc. Then lobby for Microsoft, Netscape, and Mozilla to accept certs issued by you as valid, and you're ready to go. The technical issues behind creating a certificate are easy. If you want to read more into this, I suggest Googling for the Java 2 certification production scheme, etc. You can probably write up a quick scheme to create certs, sign them with your key, etc. After all, what is a cert? It's simply a document saying "Yup, site ______ can be trusted", signed with your private key. Then any MS, Netscape, or Mozilla client can simply validate the certificate using a widely available public key.
I've often wondered a little about the demand for ultra high powerd crypto for e-commerce. It's all good in theory, but when people happily send their credit card number to any random website claiming to seel stuff that does an SSL connection, just what is the point?
I seem to recall a quote about armoured cars being used to deliver a package from someone living under a bridge to someone living in a cardboard box.
And can someone explain to me again why some people still persist with giving their credit card numbers over the phone "because its more secure"?
Until the ideas actually sink in at a deep cultural level, we will continue to have all manner of stupid and contradictory actions from people who don't have the time to understand how all of this works. Hopefully it'll happen soon, right?
Jedidiah
Craft Beer Programming T-shirts
I'm also glad to see folks doing more with the capabilities within a browser. The folks that are taking this the furthest that I've seen are the folks at Technical Pursuit.
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 all good in theory
I think that is the entire point. Some businesses only put just enough effort into anything to make sure they won't get sued.
Vendors of e-commerce packages come to mind. Their software makes just enough effort so that if anything goes wrong it's going to happen on the end-systems and is therefore be the fault of operator / client / user.
Plausable deniability, etc.
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 -->
I see a lot of posts here wondcering how this is useful and why not just use PGP.
I can't imagine people really trust PGP anymore. No longer open source, no longer affiliated with Phil Zimmerman... and his statement when he left was scary.
For those who don't know, Phil stated when he left that every PGP product released while he was there contained no hidden back doors. Knowing that companies like PGP were being pressured, it makes me think the creative differences were them wanting to build something in that he thought shouldn't be in.
The main problem is it's *almost* elegant, but not quite 100% there - in actualy use it always seems like you need some ugly half-assed hack to do something that should be simple.
For example, say in a form you want to validate a field as soon as the person enters it (i.e. they type a bad value and it returns focus to the field). Sounds simple right? Just trap the onblur event, test the field, and call focus() if it fails.
Not so... most browsers will ignore focus called from within onblur (because the "blur" happens after the event fires, and you can't stop it). You wind up with the silly, messy hack of setting a timer to call focus() a few milliseconds later. Really, this makes onblur almost useless for the main thing you'd expect to use it for!
It's quirks like this that makes you pull your hair out trying to do anything serious with javascript. I sometimes wonder if those setting the standards have actually ever eaten their own dog food (as the Mozilla folks like to say).
Also, key distribution is not a problem with public key systems.
Sure it is. I am your bank. This is your bank's public key. Now encrypt your wire transfer details and deposit some of that sweet green wampum, baby!
It's so much of a problem that Certificate Authorities can exploit their positions to turn doing practically nothing into a goldmine, and even then they screw up sometimes and get social-engineered into issuing key pairs to people who are not the convicted monopolists they claim to be.
Stealing and modifying some RC4 code, I made a self-contained Javascript/PHP CipherSaber encoder/decoder.
Boring I know, but at least it can create self-decrypting HTML files where the ciphertext and decryption code is all self-contained. With such output, any* JS-enabled browser can decrypt the file without a net connection. Here's a sample (use password "test" and 1 loop). This idea can be modified to fit almost any encryption scheme; RC4 just seemed like a good mix of security and extreme ease of implementation at the time.
* This is almost guaranteed NOT to work on Safari in Mac OSX. It works on recent Firebird builds under Windows XP and RedHat 9 (and probably other things as well).
--
"Extra Anus Kills Four-Legged Chick" -- Headline
Schneider's javascript Rijndael implementation makes a great teaching tool, because it's so easy to modify it to show intermediate steps. Sure, you can do this in any other language, but it's especially compact in javascript, and anyone who has ever programmed in ANY modern language can read javascript, which cannot be said of plenty of other languages. For my architecture class we had to implement Rijndael with synthesizable modules, and that implementation saved us countless hours, because it was so easy to tweak things in the javascript implementation that we could often save time by deliberately introducing bugs into the reference implementation and seeing if it had familiar effects. Anyone who's ever used FPGA Advantage probably knows how much of a pain in the ass it can be debugging with that alone.
WARNING: there is a trojan on your
I created a similar thing for Flash ActionScript called ActionCrypt; although it's still in progress. You might want to check it out; Javascript and ActionScript are very similar (as they're both based on the same syntax).
www.sitetronics.com/wordpress