Javascrypt

NTK's weekly list of useful stuff includes a pointer to Javascrypt, a Javascript-based encryption utility. Handy.

Comments

The "security blanket" factor

[__aavhli5779]

I had this idea myself, and abandoned it because I realized just how much of a sense of security people get from having that little "lock" in the corner*. Though there are plenty of advantages to a strictly client-side security model, I still wonder how the unwashed ignorati surfing ecommerce sites who have had "MAKE SURE YOU HAVE ENTERED AN ENCRYPTED PAGE" drilled into them will take to this sort of idea.

Then again, if some sort of certification authority could be set up for Javascrypt-ed pages where the user was somehow assured that their data was equally protected as would be over https, then things would be more preferable. However, the byzantine red-tape behind getting a cert is possibly one of the things this technology would do away with best, and it would be a pity to remove such an obvious advantage.

In any case, it's promising, and I hope it is successful.

___________________
*also I am a poor coder

Re:The "security blanket" factor

[herrvinny]

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.

Re:The "security blanket" factor

[Coryoth]

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

Re:The "security blanket" factor

[Anonymous Coward]

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.

Re:The "security blanket" factor

[Jerf]

The algorithm Javascrypt implements is absolutely useless for what you're talking about. AES is a symmetric encryption algorithm, which means that if you're going to send the data to some server using Javascrypt, at some point you need to communicate the key. If you send the key with the data (not to mention the .js for decryption), you've just royally wasted your time. This could only be useful if you agree to a key in advance using some non-internet connection method, in which case you're not going to go with a "cheap ass" encyption technique like this.

(I do not mean to disparage the Javascrypt work, it's good stuff. But it's more useful to introduce people to encryption then for any practical use.)

The genius of asymmetric encryption is that you can negotiate a secure connection without compromising it; it is not immediately obvious this should be possible and I consider it one of the larger mathematical results of the previous century. Extensions of that work have resulted in the ability to "sign" the keys during exchange. None of this applies to symmetric encryption because you have to agree on a key directly with the sender. (You could in theory still provide a third-party affirmation of the validity of a given key with symmetric encryption but not without giving the third party the key, which is undesirable. With asymmetric encryption the third party can sign a public key without knowing the private key that generated it, so even though Verisign signs your key it does not mean that Verisign can read through the resulting encrypted connection.)

A lot of people seem to be laboring under this misconception. Javascrypt is a neat toy and a valuable educational tool. It is not and can not replace SSL or the SSL layer of the browser. If someone wants to implement a version of SSL it may be sort of possible, but since you don't get raw socket support it's going to be a non-compatible kludge, barring some extremely clever and probably not at all cross-platform hack.

Re:The "security blanket" factor

[mosha]

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?

The point is that if you connect with SSL - then the website is not "random". I.e. you can verify that whoever pretends to be amazon.com - is really amazon.com. So you know who you are dealing with - you are not giving your credit card to somebody just pretending to be amazon.com.

Also you made sure that nobody could sniff the credit card number while it was traveling from you to amazon.com.

Re:The "security blanket" factor

[swillden]

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?

What's the point? It is useful to encrypt the data in transit, even if you don't know who it's going to -- then at least there's only one party who can steal your card number, instead of a dozen. Beyond that, if you connect via SSL, and your browser doesn't complain about an invalid certificate, you know a couple of things:

1. The site has a certificate from a "trusted" certificate authority. While the level of verification that these CA's do isn't all that high, and they're not necessarily people you would trust a huge amount, you probably can trust that they've done some basic checking up on the site. The main thing is that they know who the legal entity is who paid for the certificate, which means that in the case of fraud, you have a better chance of being able to track the site owner down.
2. The web site your browser thinks its connected to is the same one listed in the certificate. This means that if you think you're connected to a site you consider trustworthy (for whatever reason), chances are very high that you actually are connected to that site and are not being spoofed by someone who's hijacked your connection.

So, there *is* value in that little lock on your browser window, even if the security isn't iron-clad. Note that the recent spate of Paypal hoax sites that ask for CC# and PIN do NOT use SSL. Why not? Because it's too hard, and too risky, for them to try to obtain a valid cert.

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"?;

Because it is! Under most circumstances anyway. Assuming you called them, and you looked up their phone number in some trustworthy place (like the phone book), then the odds that you're giving your credit card number to someone else are pretty small. Basically, the only way your number could be stolen would be if someone were tapping your line*. Not that wiretaps are all that tough to implement, but they're not that common, either, and more importantly they're not very easy to automate.

Compare that to sending your CC# to a web site. How could that be hijacked? Well, to start with, your machine could be trojaned (worms can quicky infect millions of machines), so the simple act of typing your number in compromises it. Next, assuming no SSL, the data will go in the clear over better than a dozen network hops, more often two dozen, before arriving at the destination. The number can be copied anywhere en-route. Thanks to DNS spoofing, router hacks, compromised proxies, etc., that destination may not even be where you think it is.

And computer-based CC# theft is eminently automatable. Packet sniffers can collect and report anything that appears to look like a number. Trojans can quietly search your whole machine looking for numbers. Faked sites can be set up to collect bunches of numbers.

The fact that computer-based CC# theft can be automated means that the rewards are higher, i.e. it's worth the effort. It's also less risky: the scanning tools can send the data to electronic dead drops on hacked machines so that with a little care the attacker is almost completely untraceable (until he tries to *use* the numbers, but that's a separate issue). Contrast that with the effort and risk involved in tapping telephones.

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.

But don't denigrate useful security measures just because *you* don't understand how they work!

* Note that there is another obvious attack against phone-based CC# delivery: call re-routing. Someone with the ability to re-program the exchanges could get your call sent elsewhere. Again, though, this is labor-intensive and risky, and it requires a high level of access into telco systems, which is not easy to obtain (unlike 20 years ago).

Re:The "security blanket" factor

[damiam]

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"?

Mostly because they're clueless. However, an unencrypted HTTP connection is probably less secure than a phone conversation, because it's much easier to sniff.

Re:The "security blanket" factor

[Anonymous Coward]

The point is that if you connect with SSL - then the website is not "random". I.e. you can verify that whoever pretends to be amazon.com - is really amazon.com.

Sure. But I've never seen anybody click on the lock icon to check the certificate...

Re:The "security blanket" factor

[robolemon]

Or you could tell your poker buddies the key in person and then send the stuff to them once you get home and have complete security with your friends, even if you know that they would never understand "real" encryption.

That gives you security real cheap. I know something like GPG is free and assymetrical and all that, but it's not necessarily cheap in that you have to set it up at every point and educate all the users. This scheme doesn't even make you send an encrypted key to the person beforehand, which eliminates an extra step that Joe and Bob might not care about while they swap stories about cheating on their wives.

No highly secretive government assassin and spy program (or the equivalent) would use something like this for sure, but they're not the audience. This is more of a toy than anything, useful for personal stuff instead of sensitive stuff.

Re:The "security blanket" factor

[RzUpAnmsCwrds]

"Because it is! Under most circumstances anyway. Assuming you called them, and you looked up their phone number in some trustworthy place (like the phone book), then the odds that you're giving your credit card number to someone else are pretty small. Basically, the only way your number could be stolen would be if someone were tapping your line*. Not that wiretaps are all that tough to implement, but they're not that common, either, and more importantly they're not very easy to automate."

You missed a very important point.
When you called that person on the phone, you gave your credit card number to *a person* - someone who could write it down on a sheet of paper without anyone else in the office noticing.

With any good online retailer (e.g. Newegg), the card is billed and the information deleted almost instantly. Yes, the admin could install a program that records credit card numbers, but it would likely be noticed eventually.

"so the simple act of typing your number in compromises it."

Or your house could be bugged with a $5 walkie talkie, so the simple act of saying your number compromises it.

"And computer-based CC# theft is eminently automatable."

And phone based theft requires nothing but an angry employee with some paper, a tape recorder, or any other number of devices.

"the scanning tools can send the data to electronic dead drops on hacked machines so that with a little care the attacker is almost completely untraceable"

And if our employee isn't stupid enough to actually enter your transaction in the computer, they are completely untracable.

There are risks both ways. Neither method is particularly secure. Handing your credit card to that waitor isn't very secure either - but we do it all the time. What amazes me is the number of people who order things using their credit card *in public*. People just blurt it out.

The grandparent was right. Most people do far riskier things with their credit cards than online shopping. Perhaps ordering over the phone is less risky. But shopping online is far safer than handing your card to someone you don't even know - at the food store, the gas station, or wherever. How do you know that that cardreader they are swiping it trough is the real one. How do you know that they aren't committing it to memory. How do you know that the person behind the desk at the airport isn't really typing your cardnumber into notepad. Shopping online pales compared to these risks.

Re:The "security blanket" factor

[Anonymous Coward]

Because it is! Under most circumstances anyway.

I guess you forgot about the human factor. ie. The ease of which it is for the person you talk to to write down your CC details and use for themselves. With online transactions it's (usually) automated, and thus no chance of this happening. Heck, with most bureau services the vendor usually doesn't even get the choice of looking at CC numbers.

Re:The "security blanket" factor

[swillden]

Most theft of CC numbers from on-line stores is done by hacking the database where they're stored. Some on-line retailers delete this information, most keep it around as a "convenience" for the customer, some just keep it around for no good reason.

This means that the employee compromise opportunity is even greater with on-line retailers because it lasts longer.

Actually, though, from a cardholder's point of view, all of this is irrelevant. At least in the US, law limits cardholder liability to $50, and in practice the credit card business is so competitive that it's rare that card issuers will make the customer pay even that. They don't want to risk pissing customers off.

Re:The "security blanket" factor

[Anonymous Coward]

Well, there's one good thing about giving your credit card number out over the phone: you can be sure that there's a reasonably reputable-sounding person at the other end of the line, and that it's not just a front for, I don't know, the Russian mafia or something. Of course, you still have that risk, but if they're able to accept orders from a large number of consumers with people who speak English reasonably well, it's probably all good. Also, the laws for wire fraud are more developed than the ones for fraud over the Internet, and it's easier to track back a phone number than an Internet address.

Re:The "security blanket" factor

[Anonymous Coward]

Actually, you're wrong. You don't need to use a non-Internet based method to exchange keys (how do you think SSL works, hrm?). AES can, and often is, used as the (relatively fast) symmetric cipher in encrypted communications using SSL. Only key exchange needs to be done asymmetrically. This doesn't preclude the use of symmetric ciphers once the key exchange has taken place.

Re:The "security blanket" factor

[Jerf]

No highly secretive government assassin and spy program (or the equivalent) would use something like this for sure, but they're not the audience.

Actually they can, and have; if you've got good physical security it's more secure then key exchange protocols (one more step that can't be broken), and it's not as inconvenient as one-time-pads, which as Schneier points out, is generally useless as it requires a secure sending of enough bits to send the entire message; why not send the message that way in the first place? (The answer, of course, is you may want to send a message later, but that's a relatively rare case; it happens but it's definately an edge case and means that "one-time pad" is not the be-all, end-all of encryption despite being the strongest of the "provably secure" algorithms.)

This argument is what I obliquely referenced in my original post; if you've got a secure mechanism for key exchange, 99 out of 100 times you can just use that to pass your messages instead, so why bother with this encryption?

Re:The "security blanket" factor

[42forty-two42]

The algorithm Javascrypt implements is absolutely useless for what you're talking about. AES is a symmetric encryption algorithm, which means that if you're going to send the data to some server using Javascrypt, at some point you need to communicate the key. If you send the key with the data (not to mention the .js for decryption), you've just royally wasted your time. This could only be useful if you agree to a key in advance using some non-internet connection method, in which case you're not going to go with a "cheap ass" encyption technique like this.

Ever hear of Diffie-Hellman? Sure, there's a risk of a man-in-the-middle attack, but it's better than nothing, and will protect against passive sniffing attacks.

neat piece of work

[Anonymous Coward]

this means that i can encrypt my webmail and the recepient can view it tooo gr8!

Re:Nice, but dangerous.

[tomstdenis]

This is totally stupid. First off the js runs *locally*. The real risk is making sure the js you download is legit.

There is no risk of data going outwards though unless the js has been modified.

Re:Nice, but dangerous.

[TheSpoom]

Uh, it's Javascript. The entire point is that processing is done client-side. No information is submitted to the site. There's no HTTPS or SSL because nothing is transmitted.

Hmmm

[clifgriffin]

For some reason I thought that if you had a good reason to encrypt your content, you'd be using a secure medium in the first place. :)

I don't call a website with no security measures with a neat JavaScript thang "security".

Have a good day,
Clif

Re:Hmmm

[__aavhli5779]

The encryption is suitably strong.

The problem is knowing when you're dealing with legitimate Javascrypt encryption, and when it may be some malicious code instead (see my post above regarding certification).

Also there's still no way of ensuring that your data, once received on the server-side, will be used properly. That will, as always, come down to an issue of trust between you and the vendor.

Re:Hmmm

[clifgriffin]

Good point. I think we are both thinking on the same frequency thangy.

How is my original post offtopic though, people of the slashdot?

I said it's neat, but I don't see a large market for it, and that its implementation seems to have security problems itself.

People these days.

Clif

No GPG?

[Nonesuch]

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...

Re:No GPG?

[radish]

There are more than a few out there already (not surprisingly!):

RSA Crypto-J

BouncyCastle

Cryptix

Flexiprovider

There's a bunch more too - just google for them.

Some of these are free, some are Free and some are neither. Personally, I've written banking software using the RSA libs (I tried to get use BouncyCastle but management didn't like the name!).

Re:No GPG?

[Anonymous Coward]

Hushmail uses a Java applet to encrypt mail - maybe you could get your grandmother to use that. There are other Java crypto implementations, such as Cryptix. Packaging one as an applet shouldn't be too hard.

Re:No GPG?

[Anonymous Coward]

I tried to get use BouncyCastle but management didn't like the name!

Don't act so surprised. BouncyCastle is a childish name because perception matters.

How would a manager look when telling his other suit friends that he just rolled out BouncyCastle instead of RSA? RSA sounds like a boring, professional acronym, while BouncyCastle sounds like fischerprice.

Re:No GPG?

[LadyLucky]

Personally, I've written banking software using the RSA libs (I tried to get use BouncyCastle but management didn't like the name!).

We use bouncy castle. We just didn't tell the management. Really easy. :-). Works pretty well, too.

Re:No GPG?

[Anonymous Coward]

Don't act so surprised. BouncyCastle is a childish name because perception matters.

Right, just think of what's happened with "stoned beaver."

Re:No GPG?

[mcrbids]

Requiring the sender to use their own CPU cycles to encrypt messages is a classic variation on the "micropayments" approach to reducing spam volumes...

Which all sounds quite nice until you realize that it's a price that drops by 50% every 18 months or so. If everybody on the face of the earth started doing the same thing tomorrow, it'd take at most a few months before the spammers got the presses warmed back up.

Sorry, but we aren't going to DDOS the spammers. We need a system for holding them accountable.

Re:No GPG?

[Black Acid]

Requiring the sender to use their own CPU cycles to encrypt messages is a classic variation on the "micropayments" approach to reducing spam volumes...

Which all sounds quite nice until you realize that it's a price that drops by 50% every 18 months or so.

I can't be bothered to look up the source, but I read somewhere that someone is working on a memory-bound solution, rather than CPU-bound. Since memory access speeds do not accelerate at the same rate as processor clock speeds, this should work better as users upgrade their systems.

Re:No GPG?

[alan_dershowitz]

every 18 months, create a newer longer key, and sign it with your old one.

Just an idea. I agree with your post.

Re:No GPG?

[Anonymous Coward]

Errrr. The Post is about Crypto implemented in JavaSCRIPT not Java.

Re:No GPG?

[yourmom16]

a better part is that they can't just use dictionary based attacks on a domain, to contact those who use this technique they must find the public key.

Javascript insecurity

[Anonymous Coward]

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.

Re:Javascript insecurity

[Phroggy]

Are you talking about JavaScript itself, or a particular implementation of it?

Re:Javascript insecurity

[frozenray]

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.

In an effort to win the browser wars by adding functionality, Microsoft dug their own security grave by adding a File System Object to their scripting engines - without it, many browser-based exploits won't work.

Goes to show that your bad design decisions will always catch up with you and that adding security as an afterthought never works.

Re:Javascript insecurity

[Anonymous Coward]

Javascript itself. The entire architecture needs to be scrapped. The only hope for it is by redesigning it from scratch.

Re:Javascript insecurity

[Anonymous Coward]

Now that's just funny. I'd love to hear the reasoning behind that uneducated assumption.

Re:Javascript insecurity

[Anonymous Coward]

I find your comment uneducated. I have yet to meet one single defender of javascript who really has enough security understanding to really understand the issues.

I know many who believe javascript is quite secure. They usually crawl away when confronted with the reality.

Take a quick trip over to securityfocus.com and do a simple search for javascript. That will give you a starting place to begin understanding the issues.

Clearly one of us is uneducated here. So kindly explain why, in light of js's past history, and the recent exploits, why you think it is indeed secure?

This should be vastly amusing.

Re:Javascript insecurity

[ProfKyne]

You mean the implementation, not the language.

Re:Javascript insecurity

[Anonymous Coward]

I suppose that's just like saying the only thing wrong with communism is the implementation, not the philosophy.

useful

[TedCheshireAcad]

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. ;)

Re:useful

[Red Pointy Tail]

Yahoo mail uses cheap bastard technology then :)

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.

Re:useful

[Anonymous Coward]

It's worse than a hack. It accomplishes nothing.

People use encryption when sending passwords, so others can't intercept the passwords and use them. Now you're sending hashes over the network. Others can just intercept the hashes and use them. The attackers won't know what the original passwords were, but what do they care? They can still log in to those accounts.

Re:useful

[TedCheshireAcad]

Yeah, I explained to the client the concept of "passing the hash" and if someone was sniffing the network traffic that a hashed password wouldn't matter and blah blah blah.

I remember his words were "well, it's secure enough for our purposes". So rather than argue, I simply went ahead and wrote it. C'est la vie.

Re:useful

[OsCarJ]

While I agree with you that it's not the best security in the world it's not completely useless to send the password hash over the network.

In the overall scheme of things, the risk of someone intercepting traffic is minimal compared to the risk of someone grabbing the entire password database. The real point of using the password hash is to keep the cleartext password out of a database.

Let's face it. It's a lot less time consuming to just grab an entire database than it is to intercept all the traffic (even if it is automated) until you get the passwords you want.

Re:useful

[F452]

Who says you have to pay for an SSL cert? Can't you just generate your own with OpenSSL (or whatever it's called)?

Re:useful

[Anonymous Coward]

That may be true, but the way I understand this solution, if you grab the password database you don't even have to brute force the hashs of the passwords, you just send the hashes to server and BAM, you're in.

So lame. But what do I know, the importance of the data could have been worth less than the SSL cert.

Re:useful

[netsharc]

Doesn't Yahoo! do that, they issue a particular key (as a hidden html form element) that gets hashed with the password, I imagine they store this key in the session variables in the server.

Ah, I remember the fun trying to use tcl to create a program that can download and convert emails from the Yahoo web mailbox, the project is still in my ever-full "Pending" list, unfortunately.

Re:useful

[Anonymous Coward]

Doesn't Yahoo! do that...

Yes, that's what the parent meant about Yahoo using cheap bastard technology, because the original poster called MD5 password verification that.

Re:useful

[Basje]

To prevent this:

take a hash of the password (Ph1) as the passtoken.

now, on the client, hash the password -> Ph1
do Md5sum(Ph1 XOR SessionID) and send this. Compare on server, where you have the same two pieces of information. Now a replay attack wont work as often (only with the right session id, which is a very slim chance.

The MD5 in the last step is not a hash of a hash, which would yield no improvement. By introducing the SessionID you introduce new info. With the hash, you distribute this info evenly, making reversing it very hard.

Of course, it is a hack, but not everybody can use https, for practical or political reasons. No need to use plaintexts passwords in any case.

Re:useful

[Xrikcus]

Of course, but then there's no verification for the client that you are who you say you are.

Re:useful

[Sexy Bern]

http://fetchyahoo.sourceforge.net/
http://yahoopops.sourceforge.net/

Re:useful

[F452]

But it sounds like the original poster was using some kind of scheme that wasn't universal anyway (not that I understood exactly what he was doing). If you're going to be setting up some other system manually, and it's a smaller scale operation (perhaps for B2B use), you could compare thumbprints on the SSL certs to make sure people are on the up and up. (Whereas comparing thumbrints wouldn't be very practical for Amazon.com.)

My Foil Hat

[dolo666]

That's why I said to grab it and use it on your own computer at home. Download it all to a directory or something.

Considering that I wear a foil hat, so don't be mad, ok? I still think it's not a good idea. I just don't trust Javascript.

At first glance, it looks dangerous. However, after considering what you've said, it appears that it all does run offline locally. The form doesn't clickthrough to his server. It has an onclick value that triggers the javascript. Cool.

I would still prefer to encrypt everything using PHP & MySQL. It's faster, and not so limited as web forms.

Re:My Foil Hat

[dolo666]

Think AC. Think. When do you call encryption in a website? Transactions. Passwords use hashing, not enc... so just financial stuff, really. I guess some places encrpyt user data, but I'd just as soon as obfuscate it with base64 and some slipping.

Not really needed if you're over SSL & HTTPS, just if you want to keep ISP eyes away from your stuff. A discussion site doesn't really need to worry about that.

so like:
$this = md5($pass);
mailpass($pass);
userpass($this); // stuffs password in db

Then when the user signs in:
if($dbpass != md5(getpass($post_pass))) die('wrong pass dude');

Not likely to even notice that one.

Javascript not just for Clients

[yomahz]

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.

Re:Javascript not just for Clients

[Anonymous Coward]

There are a number of servers that support server-side javascript

fucking >:^B *DUH* just figured that out did you?

...so I wrote a RC4 and base64 implementation in Javascript...

...and please don't claim the work of others as your own.

fucking freshman MIS majors shouldn't speak until you have at least 10 years real world experience. do something valuable with your ability to lie, like get your MBA and become a car salesman or something...

Nice approach

[randall_burns]

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.

Re:Nice approach

[Anonymous Coward]

Folks, those folks are doing interesting folksy stuff for us folks.

Password generation Javascript bookmarklet

[nicwolff]

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?

Re:Password generation Javascript bookmarklet

[cryptor3]

I've taken a look at your site, and I see a couple of possible problems with your scheme.

First off, the master password thing makes me nervous. If your master password is compromised, then all your previous passwords are compromised. I think that there are ways to mitigate this risk, by using salts. I'm not sure about this, but it's my gut feel.

Second, to your question. You probably do not want to use CRC32 to hash the input. When you take MD5(masterpw + siteurl) = sitepw, you're relying on the fact that if someone gets your sitepw, they still won't be able to recover the masterpw even if they know the url.

It's a little late, and despite my nick, I'm a bit rusty on the mathematical details at the moment. My inclination is that CRC32 isn't a good idea for absolute security. Reply if you want to chat about this off-thread, and I'll get in touch.

Re:Password generation Javascript bookmarklet

[Anonymous Coward]

Actually, I think this is a great idea!

Like the man says: it's great for throw-away accounts. Of course you still use real passwords for real things.

But if the choice is:
A. Same password for all accounts (I'm also guilty of that I must shamefully admit) or
B. Generated unique password albeit not 100% crackproof

Then B still is a hell of a lot better.

Also: nothing stops you from using different master passwords for different kind of sites, to reduce the potential damage.

And the fact that it's in an bookmarklet makes it ideal because plugins and seperate tools have the disadvantage that you don't have them around when you're on some other computer.

The only obvious problem is when the domain name of a site changes...

I'm gonna look into this one a little further.

Re:Password generation Javascript bookmarklet

[nicwolff]

I agree about the master password being a point of vulnerability if it gets key-captured, or shoulder-surfed, and salts wouldn't help any in that case, but this isn't meant for your most vital passwords to servers or bank accounts, it's meant for all those damned e-commerce and community site registrations for which you end up making up and forgetting crap passwords or using the same one repeatedly...

shortest comment for shortest story

[SuperBanana]

...ever(?)

Re:shortest comment for shortest story

[Anonymous Coward]

No

Oh god no...

[eurleif]

A few years ago Me: I know Java! Silly person: Cool, you can make applets! A few less years ago Me: I know Java! Silly person: Cool, you can do DHTML! Now Me: I know Java! Silly person: So you can do encryption!

Re:Oh god no...

[Anonymous Coward]

You, silly person, what more is there to say?

Re:Oh god no...

[Anonymous Coward]

Well smack the silly person in the face with the hardest fucking punch you can muster for assuming that Java and Javascript are the same.

Then punch yourself in the balls for posting about Java in a Javascript thread.

Look who wrote it...

[Guido del Confuso]

This program was written by John Walker! They were right when they said only terrorists need encryption!

Am I the only one...

[eviltypeguy]

Am I the only one that read the headline as:

"Java's Crypt"

Java dead already? Odd...

I thought, geez the Slashdot Trolls really *have* taken over...

Re:Am I the only one...

[Anonymous Coward]

Yes.

Not new...

[evilviper]

For quite a good long time now (in computer terms that is) Yahoo has been doing this same thing. If you log-in without entering SSL mode, you need to have javascript enabled in your browser so that the script can MD5-encrypt your password.

Despite the whole client-side-encryption advantage, I dislike how much easier it would be to perform a man-in-the-middle, or a number of other exploits. I will admit, however, that I am quite concerned with the prospect of honeypot SSL sites, designed to steal info, but I think the former is more likely. So, for now, I am sticking with SSL. Maybe in conjunction with SSL, this would make an ideal solution. Of course, SSH would be even better...

Re:Not new...

[Proteus]

Maybe in conjunction with SSL, this would make an ideal solution. Of course, SSH would be even better...

Um, SSH uses SSL. How is it, then, better than SSL?

Re:Not new...

[Anonymous Coward]

Um, SSH uses SSL. How is it, then, better than SSL?

ssh does not use ssl, (thought it can to verify host keys, this is rarely done) openssh does use openssl, which is usefull for many things non ssl. it might just be the portable (non openbsd) version.

Re:Not new...

[evilviper]

Um, SSH uses SSL. How is it, then, better than SSL?

OpenSSH uses SSL, yes, but only for it's ciphers really. SSH does MUCH MUCH more than SSL does.

Re:Not new...

[Anonymous Coward]

Parent post is right, this has been done before. I wrote a little twofish encryption/decryption utility in javascript a few years ago:

http://russ.hn.org/twofish/twofish.html

As others have pointed out, symmetric encryption in javascript isn't a generally useful thing. But it is good for some special cases, for example creating a password protected page without server side scripting.

Oblig: Java != JavaScript

[radish]

I'm already seeing people mix the two up in this thread, let's set this down straight:

JavaScript/ECMAScript: Untyped yucky scripting language developed by Netscape (IIRC) and built into browsers so you can have image rollovers.

-- has nothing whatsoever to do with --

Java: OO, multi-threaded, multi-platform language used occasionally on websites as applets, but much more frequently on the back end for app servers and the like.

This has been a public information posting.

Re:Oblig: Java != JavaScript

[Anonymous Coward]

You may use it more frequently on your back end, but I wouldn't put that bloated VM close to mine. Reminds me of Lawrence from "Office Space". Peter wasn't going to jail, he was going to use Java. "Watch out for your corn-hole, buddy".

Re:Oblig: Java != JavaScript

[Webmonger]

It's true that JavaScript and Java have little in common. The name was a marketing ploy. (It was originally called LiveScript.) But JavaScript does have types-- in fact, it's an oo language.

It's just weakly typed.

Re:Oblig: Java != JavaScript

[Anonymous Coward]

But JavaScript does have types...

Oh, I agree heartily. Here are some common types of JavaScript I've run across on the Web:

• Annoying
• Pointless
• Buggy

Yeah, not what you meant, but you get my drift...

Re:Nice, but dangerous.

[evilviper]

in this guy's site, because he can read it, and because it's not over a HTTPS or SSL connection, so can anyone else.

NO! The data never leaves your browser. Therefore, nobody on the net can see it under any circumstances. Also, unless there is a trojan piece of javascript code that submits it to his site (a potential problem with a program in any languge) he can't possibly see it either.

MOD PARENT DOWN. STUPIDLY IGNORANT

[Anonymous Coward]

Javascript is client-side, not server-side.

The page just presents you with the forms and scripts and your browser does all the processing.

This isn't secure

[ArkanWindsong]

The problem with hashing a password with js and then just sending the hash is that the hash effectively becomes the password. i.e. all someone needs to do is eavesdrop your http session and record the hash value. The attacker can then send that same hashed value to the server and login as you.

The server must hash the password itself or it isn't secure. Or the hash value must be protected as much as the password.

Re:This isn't secure

[Anonymous Coward]

You're describing a replay attack. Think about SSH. You log in to your box with the same password every time. What's to stop your ISP from saving a transcript of the transmission between you and your server, and later replaying the entire script with the server again, redoing all the commands you had typed in that eavesdropped session?

The common way to get around this is for the server to generate a random salt value, and require the user to mix the salt in with their password before hashing to generate a unique hash with each session. So, you connect to your server today, and the server sends you the salt "12345". This salt is XORed with your password, then hashed, then the hash is sent to the server. You connect to your server tomorrow, and the server sends you the salt "67890". This salt is XORed with your password, the result is hashed, it's totally different from yesterday's. As long as the server forces you to use the salt it gave you (it doesn't allow you to specify any salt you want, but instead remembers what salt it assigned you between page requests), and the server always gives our unique salts, you can mitigate most of the threat of a replay attack.

I noticed this is how some mail servers are allowing users to fetch mail over a cleartext channel without sending their passwords in cleartext. It was quite unfortunate to discover that this technique had made its way into POP3, because I was packet sniffing for passwords.

Cheers.

Re:This isn't secure

[Anonymous Coward]

Challenge response fixes this. Each page served to the client contains a random nonce, the user supplied password is hashed with the nonce and the hash sent to the server. No replay or MITM attacks. Of course, a smart MITM would just not hash the password on the client side, or hash it reversibly.

Re:This isn't secure

[Anonymous Coward]

It could be the MD5(MD5(password) + something that changes, like a session ID).

Re:This isn't secure

[HeghmoH]

You're correct that hashing the password isn't secure. (Although it is more secure than sending the password directly, because then it doesn't potentially compromise all those other accounts where you use the same password.) However, it's easy to fix this vulnerability. The server sends the client a random value which must be hashed along with the password, and the server compares by hashing that same random value and the client's password. This is impossible to spoof, and sniffing the connection in either direction doesn't give you the password or anything else of use.

What, No RSA/ElGamal? :-)

[Anonymous Coward]

Kudos to the authors, but really, this is nothing new.
Symmetric encryption in java script has been around for a long time. What the world needs(tm) is a good implementation of RSA/ElGamal asym crypto in javascript that doesn't make your computer seem like it took a hit of dank before running through primality tests and arbitrary size integer mods and pows.
Because of the nature of that problem, I don't forsee this really coming to fruition, so if you need asym, you'll be resigned to client side Java or native client implemenations.

LazyWeb MacroMedia Wish:
Another way to obtain pervasive crypto is to encourage MacroMedia to put BigInteger in their Flash faculties :)

Similar techniques are in use already

[gusnz]

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

[BlueFall]

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...

Re:Similar techniques are in use already

[Anonymous Coward]

And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.

but the way you've described it doesn't mention a challenge, the password gets hashed and that submited hash is the same everytime, so there is no increase in security, because an attacker doesn't need your password, she can use the hash of your password she sniffed every time.

I hope you're wrong.

Re:Similar techniques are in use already

[Anonymous Coward]

var hash2 = MD5(form.passwd.value) + challenge;

There is a challenge :)

Re:Similar techniques are in use already

[gusnz]

...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 suppose it depends on how the backend works. I imagine Yahoo for instance have a heckload of servers; perhaps if they have dedicated authentication servers that do all the hashing and authentication, a compromised web server still wouldn't allow password retrieval if it was just a pass-through of the hash.

I know what you mean though, the password must be stored on a server somewhere in plaintext for MD5 authentication to work. Still, it's better than nothing.

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...

Yeah, that'd rock. I wonder if anyone's working on a JS implementation of Diffie-Hellman encryption... coupled with the XML2HTTP libraries available in IE5+ and Mozilla for data transfer (or a hidden Java applet/IFRAME), you could have some seriously interesting applications using that in lieu of (or in addition to) full SSL. Diffie-Hellman is an asymmetric cipher that can auto-generate keys without a pre-existing shared secret (if my vague recall of crypto theory is working, any crypto mavens out there feel free to post corrections :) so it should be quite applicable to server-client work over an untrusted network.

Re:Similar techniques are in use already

[An Anonymous Hero]

* Copyright (C) Paul Johnston 1999 - 2000.

Incidentally, this one is pretty widespread (!), available from here. Walker uses another one by Henri Torgemane (no home page that I could find).

Re:Similar techniques are in use already

[metalpet]

Yeah, home pages are good. Someday I'll write one.

In the meanwhile, my original page has been mirrored at this page by a kind soul.

The pajhome source code is arguably prettier than mine, and should almost always be used, rather than mine.
To my defense, mine was developed and works under netscape 2.0, which probably makes it the first md5 implementation in javascript ever.
I have a nagging feeling pajhome's version requires at least NS3/IE3, although I haven't checked that.

At the time, after I benchmarked it and realized how slow it was to run at the time, I had serious second-thoughts about its usefulness (the 7 hashes test on the page above would take 10 to 15 seconds to run on some very reasonable desktop hardware.)
Things have gotten better, both on the CPU and the javascript speed front, and it does make a lot of sense now to use it for password submissions if you don't want to take the extra cost of SSL.

wrong

[Anonymous Coward]

A self-signed SSL certificate is free.

Why this is useful

[EmCeeHawking]

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.

JavaScript RULEZ!!1!

[Vagary]

It's not yucky! JavaScript is one of the most elegant of scripting languages. You have features like higher-order functions (well kinda), basic OO, and built-in regular expressions. C-like syntax with simplicitly totally unlike Python and Perl. And talk about platform independence! If JavaScript had just a few more libraries I think I'd advocate it as a great beginner language...

Re:JavaScript RULEZ!!1!

[S.Lemmon]

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:JavaScript RULEZ!!1!

[oGMo]

JavaScript is pretty elegant... if you want a more "full-fledged" language that has similar elegance, even more simplicity/grace, and more libraries, try ruby. Don't let a few surface features or initial impressions fool you into thinking it's anything like Perl (or Python). It would probably make a good beginner language; it certainly makes a great "advanced" language. ;-)

Re:JavaScript RULEZ!!1!

[Anonymous Coward]

Your problem is with the browser DOM, not the Javascript language.

Re:JavaScript RULEZ!!1!

[S.Lemmon]

Well, unless your talking sever-side javascript they go hand-in-hand. One's pretty much useless without the other. It's no coincidence they were developed together. It's like saying a hammer with a bad handle isn't a bad hammer.

Re:JavaScript RULEZ!!1!

[liquidsin]

That's a flaw in the browser's implementation of javascript, not javascript itself. Or so it would seem to me at this hour...

Re:JavaScript RULEZ!!1!

[S.Lemmon]

I'd say so too except it seems to be the behavior the current standards dictate. It's odd, but the old Netscape 4.x, for example, didn't have this problem.

I don't know if the standards body may have been influenced to use IE's behavior or something like that, but it definitely seems like usability wasn't the deciding factor.

Re:JavaScript RULEZ!!1!

[Anonymous Coward]

> Well, unless your talking sever-side javascript

Yes, server-side javascript is more popular that you might think. Also, Javascript is a generalized system scripting language on Windows.

You could in theory do browser scripting with other langauges (MS supports VBScript and Perl), and you would run into the same problems.

Please !

[Aliencow]

Make more websites rely on javascript ! I just love client-side code ! It's so great, I bet you could "javascrypt" blink tags so that proxies used to block crap wouldn't see it. Muahaha.

Re:Please !

[BlacKat]

Well, for those without Javascript capabilities you could transfer data in plaintext.

I can see using this to encode passwords or the like, that way if the browser does not support encrypted form data you could do it yourself.

Then you can tell people that if the enable JavaScript on your domain they'll have enhanced security. ;)

Re:Nice, but dangerous.

[S.Lemmon]

Therefore, nobody on the net can see it under any circumstances.

Well, as mentioned on the site, that's not necessarily 100% guaranteed. You could, for example, have another page open running an active-x plug in able to sniff the content of the local page. In fact, it might not even take that much since cross site security problems have been frequent among browser bugs.

Joke?

[RoC MasterMind]

Is this a joke? What kind of slashdot post is this?

Slightly OT, but for hiding mailto links

[WoTG]

I've recently discovered (or maybe I saw it on another /. article...) this nifty javascript "mailto" encoder. It creates drop in javascript that obliviates the need to put email addresses in cleartext on a public webpage. The JS created mailto links work just like they should. Yes, spam bots could learn to read javascript, but, they won't for a while...

Re:Slightly OT, but for hiding mailto links

[Anonymous Coward]

Just put a PNG of the email address on your public webpage. Spam bots cannot read PNGs.

Re:Slightly OT, but for hiding mailto links

[WoTG]

Neither can the blind read PNG's.

Re:Slightly OT, but for hiding mailto links

[NickFitz]

So put the email address in the alt attribute. Oh, hang on...

PS

[Anonymous Coward]

A note to John Walker. John, if you're reading this, thanks for The Hacker's Diet. It was my companion while I dieted a while back, and I lost 65 lbs.

I've always admired your works. Happy hacking.

I have no sensitive information to encrypt.

[Anonymous Coward]

I am nothing.

ECMAScript runs on the localhost

[autopr0n]

If you want to, you should be able to download the page, disconnect from the internet, and still encrypt/decrypt data.

In other words, you don't really understand what's going on. Although it would be a good idea to to check the page source to make sure that it dosn't upload your data...

shouldn't this be called ECMASCrypt?

[autopr0n]

I mean really, people are confused enough about the difference between Java and Javascript (which basically have nothing to do with each other other then some brain-dead attempt at synergistic marketing. JS was originally going to be called Livescript)

Re:shouldn't this be called ECMASCrypt?

[SvendTofte]

ECMAScript is just the core. It does not define the various clientside elements that this program takes advantagde of, such as using mouse input, to generate something random. Describing it as ECMAScript would be wrong. Describing it as JavaScript or JScript would, OTOH be correct.

Re:Nice, but dangerous.

[dolo666]

Yeah there are some things that are best to be on the safe side with. Chances are, if you are going to encrypt something, you'll want to be sure it's foolproof. I'm sure that some exploits will come up with this method in the next month or so. That active-x idea is one for sure, and another is to mock up another site *like* this and just change the sourcecode to steal the data.

Maybe *THIS* site is safe, for now, but how long before others do up a joke site that uses the js here but pumps your data to a backend db for kicks?

Uh

[autopr0n]

I don't think the point of this is to replace SSL or password hashing. Think AC. Think. When do you call encryption in a website? Transactions.

Actually, I call it "Encryption in a Website". What do "transactions" have to do with it? You're obviously not talking about Database Transactions, or the general meaning of the word.

Implement RSA in java

[autopr0n]

import java.io.*;
import java.util.*;
import java.security.*;
import java.security.interfaces.*;
import java.security.spec.*;
import javax.crypto.*;
import javax.crypto.interfaces.*;
import javax.crypto.spec.*;
import java.math.*;

....

public static byte[] encrypt(byte[] enKey, byte[] data) throws Exception{

//make sure our int is unsigned;
//this means -45 --> 45 or whatever, as opposed
// to not being digital signed with a public key crypto system :)
byte unsigned_data[] = new byte[data.length+1];
unsigned_data[0] = 0x7f;
for(int i = 0; i < data.length; i++){
unsigned_data[i+1] = data[i];
}

KeyFactory kf = KeyFactory.getInstance("RSA");
RSAPublicKey k = (RSAPublicKey)kf.generatePublic(new X509EncodedKeySpec(enKey));
BigInteger T = new BigInteger(unsigned_data);
return T.modPow(k.getPublicExponent(), k.getModulus()).toByteArray();
}

//your welcome

Re:Implement RSA in java

[Anonymous Coward]

//your welcome

What about "my" welcome? If you leave my welcome alone, I'll leave your welcome alone.

use a salt

[autopr0n]

Rather then passing hash(password) send in hash(salt + password), where hash is a random string sent by the server. The server then compares the sent value to it's own hash of salt + password. If you don't want to deal with sessions, you could simply change the salt every hour or 5 minutes or whatever.

You could also do hash(salt + hash(password)), that way you don't need to keep the password in the DB.

Re:use a salt

[The Creator]

You could also do hash(salt + hash(password)), that way you don't need to keep the password in the DB.

Yes, but then the attacker too doesn't need password, only hash(password).

Who the hell keeps moderating this shit up?

[Anonymous Coward]

It is WRONG!

Javascript runs LOCALLY not on the server, you retards.

God, Moderators need an IQ test before being allowed to moderate.

Nope

[autopr0n]

They could compare hash(challenge + hash(password)). I.e. they have you append a challenge value to the hash of the password, and then do the same on their end with stored-hash-of-password rather then hash(password)

Also, key distribution is not a problem with public key systems.

Re:Nope

[Anonymous Coward]

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.

Re:Nice, but dangerous.

[nyseal]

In my experience, JS is very invasive. I stay away from it at all cost. Even on the client side, do you truly believe nothing is ultimately transmitted? I'm not trying to be a troll but...oh whatever....

Umm, this guy is dumb...and I quote from article.

[Anonymous Coward]

"The sole reason for encryption is to protect privacy."

Uhh yeah, ok, try again.

RE: PGP

[Chris Tucker]

"When I find myself in times of trouble, PKZ, he comes to me.
Speaking words of wisdom, "PGP, PGP."

If you're so afraid that the post PKZ NAI PGP is tainted, don't use it.

PGP 6 and PGP 5 seem to run just fine on my PowerMac 5500/225 under OS 8.6.

I'm currently using PGP 7 Pro.

If I'm not mistaken, PKZ is now at PGP, Inc and seems happy enough with their implimentation of PGP.

Illegal To Distribute From U.S.

[Anonymous Coward]

Isn't it a violation of U.S. export regulations to allow anyone to download code that can do strong symmetric encryption from your home page?

Sure, this guy's home page isn't in the U.S., but it looks to me like if some U.S. teenager thought this was cool and wanted to put it on their own homepage for any old ter'rist to download, they'd be screaming in agony while John Ashcroft applied 120 volts to their nutsack in a Guantonamo Bay chain link box in no time. I've got a lot of nifty free encryption that I've wanted to give away for a long time, but I don't think I can, can I?

Re:Illegal To Distribute From U.S.

[Anonymous Coward]

Isn't it a violation of U.S. export regulations to allow anyone to download code that can do strong symmetric encryption from your home page?

Thought that law was revoked, since it couldn't be enforced. The usual way around it was something like "we have freedom of speech/press, so we just publish algorithms in books, the export of which cannot be controlled". Of course, considering how "the right of the people to keep and bear arms [which...] shall not be infringed" has been infringed, one wonders how long until books are under export control laws, too. We already live in 1984, if you ask me.

Re:Illegal To Distribute From U.S.

[Anonymous Coward]

Import GOST from Soviet Russia.

It's gratissssss !!!!

It's not a violation of U.S. export regulation because GOST is not exported from U.S.

The DES: Data Encryption Standard is Data Encode Suck-able

Thanks Russian Men by the GOST!

open4free

wrong (reading)

[Anonymous Coward]

setting up lots of SSL connections per second is expensive (in CPU time).

CRC32

[Black Acid]

given a CRC32 hash and part of the input, can you recover the other part?

Maybe, you may find this tutorial useful: CRC and how to Reverse it.

Re:CRC32

[cryptor3]

mmm... Fravia. Good stuff.

y^x(mod p)

[loknor]

*snip*
which means that if you're going to send the data to some server using Javascrypt, at some point you need to communicate the key.
*/snip*

diffie hellman? i think you will need to exchange a key at some point even with ssl. you still have the problem with a man in the middle attack. but if you control both ends and are just trying to stop people from listening in you don't need a cert. or a third party. Just a thought. :)

Re:y^x(mod p)

[Anonymous Coward]

You obvsiously have no fucking idea what you are talking about.... :)

Re:y^x(mod p)

[ariels]

Diffie-Hellman is indeed an algorithm for producing a shared secret without authentication. And indeed, anything without authentication is exposed to a man-in-the-middle attack. That's why SSL doesn't use Diffie-Hellman for authentication, only for (help with) producing a shared secret key.

In SSL, the client verifies the site by means of a certificate that the site provides; this cert has nothing to do with Diffie-Hellman. The site could use SSL to verify the client identity, but this option isn't used when selling stuff to the general public, as the site has no identity it would wish to bind to the client. (Well, a client cert binding the client to a credit card might be considered useful, but until the CC companies mandate it -- and they won't -- the shopping site has no need to check it.)

Having a cert protects you from man-in-the-middle.

The problems with authentication are due to problems on the client side with binding the site's cert to the site's identity. The typical client (a web browser) does the only things it can: It verifies that it trusts the signatory on the cert (so it trusts that the information about the site's identity, as presented on the cert, is correct), and that the cert belongs to the URL displaying the page. Then it leaves it to the user to decide whether to trust the site. Of course, many sites use some third party to handle payments, leaving the poor user the question of whether to trust buystuff.com when buying from ariels.com. And some sites manage to use a cert from the wrong domain, so the browser pops up a warning. And, of course, it's not at all clear to the user how to validate the identity from a cert.

But SSL, as used on shopping sites, does give protection from a man-in-the-middle.

Re:y^x(mod p)

[Anonymous Coward]

Blah blah blah...

A man in the middle attack would be possible in the same way it is for ssh: having a host pretend to be the server, and then relaying client requests to the real server.

Verification of certificates sensibly can avoid this though

Cool, but it needs a net connection

[CurbyKirby]

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).

Encryption, only for protecting privacy?

[imaginaryNumber]

'The sole reason for encryption is to protect privacy.'

Statements like this from developers of a 'high-security data encryption solution' make me worried.

And assertions that transparency will make software secure always presume that someone with the 'required expertise to pass judgment' will actually do so.

I thought MD5 was cracked?

Re:Encryption, only for protecting privacy?

[Anonymous Coward]

I thought MD5 was cracked?

MD2 and MD4 were cracked. This has raised some concerns about MD5, but AFAIK nobody has found any serious flaws in it yet.

Re:Encryption, only for protecting privacy?

[devnullify]

Any (traditional) encryption is brute-forceable, it just takes an exorbitant amount of cpu time to do so. IIRC, the RC5-64 challenge by RSA (a single ciphered message to decode) took something like 5 years to decode, using distributed.net's distributed computer, with 10's of thousands of nodes.

It's reasonably safe today, but it *is* decodable if you have the time (probably decades at minimum without a supercomputer at your disposal).

Re:Encryption, only for protecting privacy?

[Anonymous Coward]

5 years later ...

MD5 was cracked ...

To erase the 1'000'000'000'000'000 MD5's fingerprints in the world.
To generate the 1'000'000'000'000'000 MD6's fingerprints in the world.

open4free

Re:Encryption, only for protecting privacy?

[imaginaryNumber]

I'm confused by your reply. I think you're referring to my comment about MD5 being cracked. My comment was caused by my cumulative skepticism about javascrypt, and their choice of MD5 for hashing.

MD5 was effectively broken in 1995 by Hans Dobbertin. Several cryptographers whom I respect claim that MD5's weaknesses are significant enough that people should not use it --- for digital signatures. I don't know enough to say that the crack makes MD5 good for nothing --- not even general hashes.

I looked at the RC5-64 challenge, and it didn't seem to focus on MD5. So, I'm not sure where you were going with that.

Re:Encryption, only for protecting privacy?

[imaginaryNumber]

In 1995, Hans Dobbertin published an attack that effectively broke MD5. The partial attack shed light on MD5 weaknesses, causing some to suggest to not use it. Especially since alternatives (e.g. SHA1) exist.

Quality of AES

[digitaltraveller]

More excellent work from John Walker. As usual stupidity abounds on Slashdot with most of the criticism way off the mark. "This is useless because he didn't customize it to my every need". Whatever.

A useful fact the detractors haven't mentioned is that in light of the recent 'academic break' paper published by Courtois and Pierpzyk, AES and several other ciphers should be no longer considered suitable for those with a high level of paranoia.

Re:Bugs Bunny in drag

[Anonymous Coward]

Of course not! What you described sounds perfectly normal to me. Not that there's anything wrong about being gay...

Useful teaching tool

[ca1v1n]

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.

Excellent!

[heironymouscoward]

This is a wonderful resource, thanks for the link.

[OT] Re:Slightly OT, but for hiding mailto

[Anonymous Coward]

Sorry for carrying on being off-topic, but:

Yes, spam bots could learn to read javascript, but, they won't for a while...

FEH!

How long until they can get at those addresses? What then? And what of those of us who disable Javascript?

I refuse to munge my email address. I receive spam, and I forward it to the postmaster at the originating site. Spam houses get firewalled out of port 23/53/80 and reported to their uplink. I damned well will not give in to spam lameness.

Simple script security

[sdsykes]

This is a similar javascript utility aimed at encrypting your entire web page. It is used for putting secure content on an open access web server. You can only view the content if you happen to know the key. It's very cool, and has been around for a long time. Secure, small and fast.

Wow...

[Anonymous Coward]

Shortest post, ever

CRC32 is not suitable, try MD4 instead

[cerberusti]

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 would depend upon how much of the file you have compared to how much of it you need, at a minimum, it would narrow the possiblilities of what the original contained by quite a bit. The bigger concern is that CRC32 is reversible, meaning that adding the URL before you hash it would be useless for security, as it can be reversed into a CRC of just the master password. At this point, you could calculate what any of the passwords you are using are by simply running a CRC32 on the URL of the site and starting with the CRC of just the master password (it would also provide useful information to crack the master password, although this would not be necessary, as the data it protected would be exposed anyway.) In short, you still need to use a cryptographic hash .

If MD5 is too much for the browser, you may want to look into MD4. MD4 requires quite a bit less processing power to compute than MD5, and can be coded in much less space. MD5 is a safer method of hashing, however either should be suitable for what you are doing. The important thing is that the hash not be reversible.

Re:Petition to remove Michael

[Anonymous Coward]

I

Join the Jihad!!

Similar thing for Flash ActionScript

[dodell]

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).

John Walker?

[JohnnyCannuk]

Uhmm, perhaps I'm paronoid, but shouldn't you think twice about getting security advice from John Walker? ;)

Seriously, good stuff. Perhaps somebody will come up with an open, secure way like this to replace that behemoth Entrust TruePass (which only runs in browsers that are 3 or 4 releases behind in their Java support - MS JVM but no Java Plugin!).

Ahhh the sweet smell of failure due to fear ....

[Grizzlysmit]

I had this idea myself, and abandoned it because I realized just how much of a sense of security people get from having that little "lock" in the corner*. Though there are plenty of advantages to a strictly client-side security model, I still wonder how the unwashed ignorati surfing ecommerce sites who have had "MAKE SURE YOU HAVE ENTERED AN ENCRYPTED PAGE" drilled into them will take to this sort of idea.

*also I am a poor coder

There's just nothing like it, I just love that you work out ahead of time why it is bound to fail, due to factors which you have know way of knowing are true, but you fear and paranoia say might be, so you quit before you start, thereby insuring failure.

Mate your not just a poor coder your, a gutless coder and a piss poor thinker. Mate I suffer from Major depression and anxiety Disorder, what some Americans call double depression, and I wouldn't let that piss poor set of excuses stop me doing anything. Mate your seriously in need of some basic guts, (I'm not meaning this as a troll, but really, if we all thought like that nothing would ever get done, as for how good a coder you are: team up with someone who is a good coder, especially if (s)he, is great a implimenting but needs a mate thats good has good idea's)

not handy..

[Suppafly]

I'd find it hard to think of anything that was javascript based as being handy. Javascript has caused way more problems than it has solved.

I work for a company that uses javascript to do a few things for their web based apps, and it doesn't even work correctly for the few things it needs to do between browser revisions. Supporting the customers often involves having them upgrade or downgrade their browsers.

DOM != JavaScript

[Vagary]

That's like saying Java and SWING go hand-in-hand. Oh wait, or do I meant Java and AWT? Or SWT? (See my point? Just because your ECMAscript interpreter only has one GUI library doesn't say jack about mine.)

Re:DOM != JavaScript

[S.Lemmon]

Unfortunately you're not saying jack about anything.

ECMAscript and DOM are both *standards* and are intended to work together. Any personal perversion of those standards might be more useable in some local app, but is essentially useless on the web at large.

Unless you're actually foolish enough to still be confusing Java with Javascript (which I'll give you enough credit to assume you're not), DOM is what you have to work with in a standards compliant browser (if such a beast really exists - but that's another issue).

Beginners Need Good Syntax

[Vagary]

I think a beginner language should have C-like syntax (I realise Ruby's is vaguely C-like, but not enough in my opinion) if you expect your beginners to eventually be programming in the real world (full of C, Java, Perl, and PHP). (If the syntax isn't important, then why not just start them on Scheme! :)

One of the nice things about JavaScript is that every computer already has an interpreter. (Although not all have a debugger. :( Also, Ruby doesn't have a large enough user base to have ubiquitous documentation. (I haven't checked, but I doubt you can get a Ruby book at any neighbourhood bookstore.)

Re:Use salt?

[Anonymous Coward]

If the server uses sessions, then for each session it can send the client a random salt, and the client sends hash of the salt plus the password. Then intercepting the hash is useless because it will never be the same for a new session.

Anti-PGP FUD

[Nonesuch]

EmCeeHawking writes:

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.

PGP is not "open source", but like Solaris, source code is published, anybody can download full source at no charge.

Phil Zimmermann is on the "Technical Advisory Board", along with Bruce Scheier and others.

What statement are you referring to?

• Phil Zimmerman Profiled
• Philip Zimmermann's personal response to the ADK bug,
• 2003 Defcon interview
• Phil Zimmermann & Associates LLC

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.

Interesting claim. Care to document it?

It seems to me that if Zimmermann felt that way, he wouldn't be on the PGP.Com technical board, and he wouldn't be reselling their products on his web site.

To quote Phil Zimmermann, "There is no backdoor in PGP. Get a life."

A satisfied PGP customer.

Yes, well

[autopr0n]

Then do hash(salt1 + hash(salt2 + password)) if you really want to.

Re:Yes, well

[cfallin]

Then you would need the plaintext password in the database, because salt2 isn't constant.

Fundamentally, the exchanged data is hash(salt + [something]). Both the client and server need to know [something] in order to compute the hash, and an attacker, knowing [something], can construct the data that is sent - so you must ensure that the database on the server isn't compromised.

etc

[Anonymous Coward]

That's a lot of et cetra's. I'm a fan of words like that, and so forth. I mean, being able to imply that you are referring to a whole class of unspecified things and so on, ad naseum, is amazing. But isn't it interesting that nearly half of the ways we can do this are directly taken from other languages, and everything like that? There's lots of ways to say it, these and the rest. As long as you both shall live, Amen.

pointer?

[tkittel]

> ...includes a pointer to Javascrypt, a
> Javascript-based encryption utility.

hey! Pointers and java is a no-no :-)

Load bookmarklet source externally

[Anonymous Coward]

For longer bookmarklets, you can load them from external sources.