Slashdot Mirror
OpenPGP Implemented In JavaScript
angry tapir writes with this excerpt from Tech World: "Researchers from German security firm Recurity Labs have released a JavaScript implementation of the OpenPGP specification that allows users to encrypt and decrypt webmail messages. Called GPG4Browsers, the tool functions as an extension for Google Chrome and now is capable of working with GMail."
A quick gander at the source leaves me with the impression that it should be more or less portable to other browsers. It's also built using a lot of off-the-shelf Javascript libraries. (Who knew Javascript had a bignum library and a number of cipher implementations?)
who knew Javascript had a bignum library and a number of cipher implementations
Those that know JavaScript?
And I don't mean the kids copy/pasting stuff found on the web, but real people working with JavaScript and having knowledge of the language, libraries, etc.
The biggest problem with JavaScript is that the world is plagued with kiddos that think they know JavaScript when all they know is how to search their needs on Google and copy/paste from there.
Write boring code, not shiny code!
I want to know who at Teh Google screwed that one up !!
Some group of bears maybe?
Write boring code, not shiny code!
Could be used for web forums too.
http://michaelsmith.id.au
http://www.matasano.com/articles/javascript-cryptography/
In the last year or so suddenly everyone seems to write everything in javascript whether appropriate or not. So these guys really think the future of development lies in the browser which will what, replace the OS as the top level development platform? Sorry , but thats rubbish. It aint gonna happen. Too many disperate browsers with their own quirks and bugs, poor performance and ultimately limited functionality.
So other than "to see if it can be done" what exactly is the point of these projects? However much webdevs might like it to happen, javascript won't be replacing Java, C++ or C# anytime soon for serious development.
I've been to the hideout. It ain't pretty, let me tell you.
I'm pretty sure it's appropriate to write a browser extension in javascript, given that its the only language Chrome allows.
I encountered what was at least a serious attempt to do exaxtly the same thing in the mid-90s. And I used it, too. Together with a colleague. We both worked in a tiny outfit where the boss was meddling in corruption with local politicians and corporate local heroes. Having such a thing as PGP usable in browsers and email clients truly was PGP to us: pretty good protection ( for the evidence we found against our boss ).
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Email encryption (OpenPGP and SMIME ) is done on the client side. People have to use to email client softwares ( outlook, thunderbird ..etc) to encrypt/sign their messages.
The problem, what if you dont wanna use an email client ?
The solution
1 - Do it manually ( copy, encrypt/sign , past)
OR - Implement it on the "new" client software (ie: the browser )
The reason of javascript is that chrome extensions are written in that language ( and every browser support it ). Maybe other releases will be implemented in other languages that integrate to browsers ( Dart ? )
I think for reasons of trust that if you were to use js PGP that it should be from a browser extension that could be reviewed and be within your control to some extent. Or better yet if the js became a core part of a browser where the code could be implicitly trusted. I'd love to see something like Firefox support go further and use a lib like this so unsigned certs could instead describe a web of trust via PGP and modify the manner in which Firefox presents such certs to a user. CAs are the biggest racket on the web and are IMO the biggest impediment to https being the default protocol for web activity.
No, it isn't. This article implicitly assumes user trusts server with everything or not at all. Not a case with GMail: in most attack models I can perfectly assume Google will deliver me correct Javascript code over SSL, but never trust it with securing my email content. Account hijacks are quite usual and replacing code on GMail servers is completely another thing.
Have been working on something similar very very slowly: a single ASP.Net web page (which could easily be ported to PHP no doubt) that acted as a proxy web browser that encrypted its traffic using a GPG key randomly generated (or provided by the user). It'd be text only ( = no accusations of being used for child pr0n or for teh pirates) but the idea would be that anyone could drop it into their own website without having to configure it and instantly people living under opressive censoring regimes (China,Iran,US,etc.) would be able to open that web page and use it as a web browser to get to news sites and the like.
If you don't risk failure you don't risk success.
http://www.matasano.com/articles/javascript-cryptography/
The above was written by someone without an understanding of public key cryptography. All you need to do is ensure that the crypto JavaScript is delivered through a secure channel. Once you have done that you can publish a public key on an insecure site and allow people to send data to you which cannot be intercepted. You can also let them generate a key pair and send you the public key, after which you can send them a response.
Plagiarist! Almost this exact comment was made 20 years ago:
In the last year or so suddenly everyone seems to write everything in C whether appropriate or not. So these guys really think the future of development lies in the windows interface which will what, replace the command-line as the top level development platform? Sorry , but thats rubbish. It aint gonna happen. Too many disperate GUIs with their own quirks and bugs, poor performance and ultimately limited functionality.
So other than "to see if it can be done" what exactly is the point of these projects? However much appdevs might like it to happen, C won't be replacing assembler, Forth or Fortran anytime soon for serious development.
News flash: turing-complete programming languages can be used to created anything. Why is it news when another random project is done in Javascript?
Pretty good is actually pretty bad.
Did you even read TFS?
Because of the security issues raised by any javascript code:
- transmitted from a potentially rooted server, or
- intercepted by a MITM attack, or
- received by a rooted client
this implementation is not secured as specified in the techworld article
Out of your three objections the second one is the only real concern that does not also apply to SSL. Transmission of the JavaScript does not have to come from the same machine as the one using it. If this catches on I would expect most people would download it from an SSL-secured plugin site. If the client is rooted, then absolutely nothing can protect you, including SSL.
The only real weakness is the man in the middle attack. Unless you can guarantee that the public certificate is from the source you have problems. SSL gets around this with certification authorities. This is not perfect, but generally works.
GPG and PGP generally rely on a web of trust. This can work very well among a small group of people - who al trust eachother only to sign a certificate that they have independently verified. If the group has rules that key signatures have to be verified by a phonecall or snailmail this is probably more secure than SSL. On the other hand if you just download certificates from keyservers without verification it does not give you much protection. I don't believe that the web of trust scales to global networks. You might trust all your friends to verify people, and maybe friends of friends too. You can be pretty sure that your friends will be as careful as you. But extend this to firends of friends of friends out to six degrees of separation and you can be pretty sure that there will be a lot of careless or criminal elements in your web.
Because most of the internet users still use "IE8" or less and therefor see JavaScript as something which sucks, is slow and can't find it's own tail?
Amen. Soon, JS will run the stove in my living room. Version 2.0 will also run my lover, making her sit really elegantly with a book on the couch facing that stove.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Indeed. What we need is a low-level language without garbage collection.
Difficult to program by humans.
Easy to target by a compiler back-end.
Give us that, and open-source will give us all the tools and libraries to bring webdevelopment to the next level.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
I'll entrust my keys to code coming from a remote server that now has the ability to send mails as me with non-repudiation and read anything sent to me in ciphertext.
Huh. You probably shouldn't do that. Maybe consider a solution like the one mentioned in the article instead.
Indeed, it would be way more cool if we would have a compiler back-end that targets javascript.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
News flash: turing-complete programming languages can be used to created anything. Why is it news when another random project is done in Javascript?
Ah, the old Turing-complete chestnut. Just because something is possible, does not mean it is feasible, practical, or easy. It's probably possible to code it in brainfuck, chef, lolcode or a bunch of rocks but no-one in their right mind would want to.
What's really interesting about this is that it now brings PGP to almost device with a browser - that is: those with browsers which have javascript support. This gives us such joys as iPhones with PGP that Apple can't suddenly decide they don't want people to have.
"such-and-such a browser will be sending such-and-such a request to you."
In which case they'll be doing server side development so why exactly would any sane person be using javascript for this? In the "real world" I live in javascript stays in the browser. End of.
You might want to think through your replies before you start typing.
I'm sure cryptologist's agree! What could possibly go wrong?!
How is this different from FireGPG? With the exception that this is still in development versus the stall in FireGPG?
This is something that webmail has need for ages. Encrypted email is relatively easy to implement, and is free, but webmail makes it difficult to do without handing your keys over to a third party (GMail, HotMail, etc). This solves the problem nicely. It would be great to see this, or something similar widely adopted.
Generally speaking, porting cryptographic implementations between systems is not as easy as "do both implementations produce the same output for the many test inputs tried?".
Proper implementations will mitigate against side channel attacks by:
I'm skeptical as to whether a web browser implementation (in JavaScript, not part of the browser itself) can address the issues listed above.
Why would in-mail javascript run at all?
What about them?
Encrypting mails you send via webmail without having copy your keys on the server sounds like reasonable usecase.
It's a "Haute Cuisine" dessert, I think. They sell it at the local boutique over-priced (e.g. organic, etc) food store by me. It doesn't look very appetizing.. do you spit out the wax, or try to eat around it?
Can you be Even More Awesome?!
You can already get encryption of your link between google and yourself - just use https, or imap with ssl. In fact, I'm pretty sure that https is the default for the web viewer now.
The article is talking about something different.
Can you be Even More Awesome?!
Hi dare you call chrome a browser! It's a desktop environment dammit!
A secure out-of-band channel is essential to secure communication.
One channel is never enough.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
I think you mean thirty?
Twenty years ago is so, '90s.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Because you just need the secure channel to exchange the keys, and once that is done you can use any other channel even when the secure channel is not available to you. This is, in fact, the entire point of cryptography. If everyone had access to a known secure channel of infinite bandwidth at all times, then there would be no need for it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
What about them?
It really would be a newsflash if they could be solved in a Turing-complete language.
Unfortunately it won't be until v3 that it can actually get you to realize that the purpose of a lover is something other than to sit elegantly with a book on the couch facing the stove, and even a massively parallel supercomputer will never get you an actual lover, thereby making the code useless.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
You pretty much just chew on it until you've managed to get all the honey out then spit out the blob of wax.
They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance. - Terry Pratchett
I've had it before. I don't know if it's treated somehow, but you can just eat the whole lot. It's quite tasty, primarily because of the honey.
What does that have to do with the fact you can create any program with a Turing-complete programming language?
Pretty good is actually pretty bad.
Good point, although the tonal setting seems to veer somewhat toward the hostile, as in : "You poor nerd / geek / ..., you seem not to be able to get / have / keep hold of a lover". Which is not my case. The post was meant i r o n i c a l l y, for the sake of cryin' out loud ***sigh***
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
If it's using JavaScript, they should call this version OpenPBP.
That tone you are hearing is in your head. Here on Slashdot, nobody can ever have a girlfriend, even if they are married ;-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I don't see why all the fuss is made about JS's capabilities. Coming from a very strong Perl/Unix background I see the appealing side of scripting. But if I take into account business programming, JS makes me shiver to the spine.
I grew up being generally interested in CS and specifically in programming. Most programmers I meet hardly ever cease to amaze me at the nonchalance which they adopt when writing code. You (dis-) qualify yourself with me as soon as the argument of "well it works" pops up. Programming the business logic is the easy part. Handling all possible exceptions whilst maintaining integrity is the hard part. Not reaching a conclusion too soon is also "up there."
Most programmers I meet can't be arsed to take exceptions and integrity too seriously. Or to continue pondering over a problem. The natural curiosity of finding out stuff and improving oneself every single day is hardly ever there.
I have adopted the liking of Java for complex solutions. You can only screw up so much in it. And you can program almost anything with it. I like mediocre programmers to write their stuff in Java.
Anything needing complex, low level system interaction I'd program in Perl. I also appreciate other similar languages that do the same. I prefer mediocre programmers around me not to touch Perl.
For setting up running environments for programs to run and to program very simple applications, I advocate Bourne Shell (not bash.) One good thing about Bourne/Unix is that mediocre programmers steer clear from AWK.
Stating that I'm "Not a complete fan of JS" is perhaps an understatement. I find the typing revolting. The means to overload methods. The slightly different method of handling strings compared to Java.
I have had the misfortune of having to know a product using JS and an open runtime implementation. Knowing what other people did is tedious at best and debugging JS there is pure hell. I pity the folks I left behind.
So, from a business point of view I loathe JS. And from a hobby point of view I can't be bothered. Why use a scripting language to program complex software when other better maintainable technologies are around? "Because you frigging can!" is the only answer I can think of.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Except a buggy browser needs to store your private key. That doesn't sound so reasonable to me.
Ah. My user id is pretty low (though not as low as yours); still, I was never informed of that rule. Although, wait. Hm. You can not prove that tone I am hearing is in my head. Neither can I prove that it is not. Oh Bishop Berkeley, where art thou ?
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Yes, that also raises the question why you read/answer encryption worthy emails via webmail but I would argue it is still an improvement that your key does not need to leave your machine.
What does that have to do with the fact you can create any program with a Turing-complete programming language?
Nothing, but was responding to GGP post saying that they could do anything.
Lets play the fill in the blank game!
COBOL compiles to _________.
FORTRAN compiles to _________.
C compiles to ___________.
Javascript compiles to ___________.
There really isn't a good way to compile to Javascript because of the amount the backend work that is needed for it to run (garbage collection anyone). They could try to do what "Go" does and include the garbage collection functionality in the system libraries or in the executable.
Also, no sane OS dev would ever use Javascript for their language of choice. Javascript is a really badly designed language. Unless they take an axe and start removing a lot of the "cruft", it will be shunned by a lot of people still.
Its not what it is, its something else.
So these guys really think the future of development lies in the browser which will what, replace the OS as the top level development platform? Sorry , but thats rubbish. It aint gonna happen.
Altogether replace? For everyone? Maybe not.
But while I use MS Office for my job, *all* my personal word-processing and spreadsheeting is done in Google Docs, and *all* my personal email has been in GMail ever since I got my beta invite -- and I'm not alone. There are flaws in these applications, but they're all outweighed by the ease of moving between computers, and sharing documents with other people.
You don't have to kill your competition in order to be worth doing.
It's more portable than anything else, and it's capable of more than popups. I can only see this trend utilizing processing power better than the (now fading) model of "do it all on the server". How many more people will use PGP if it's built into their webmail client? They won't need to install anything, configure anything - just use.
There are a number of things I'd like to push to the browser. With accompanying server fallbacks, browser processing could greatly reduce my server load which would increase the number of users I could serve.
Try not to think of it in terms of "if it can be done", think of it more in the terms of "can I distribute the tasks".
"Lame" - Galaxar
Two things: hushmail.com does this. And second, it doesn't really work. If you don't trust your provider (or your connection to the provider) then how do you know your javascript encryption library doesn't have a back door?
Your user id isn't what I call low at all.
Sigh
Kids
I just posted the link Amazon search returned (without even being logged in there) so I have no idea what it's referring to, but glad you're happy....
Nothing is forcing anyone to use the "cruft" though.. there are corner cases in every language that can be considered *very* bad form.
Michael J. Ryan - tracker1.info
But you do not need a secure channel to exchange the keys if you use asymmetric encryption mechanisms like RSA or ElGamal. You need trust/authentication to know that the public key is legit.
Having a secure channel as a prerequisite is disingenious. If you presume to already have a secure channel available, then why not just swap symmetric keys over that. Of just send the message there, if it has a lot of bandwidth.
This is what Matasano page is arguing. You need a secure transport layer to transport the Javascript and all the content. But, if you have a secure transport layer with that much bandwidth available, you have no need for Javascript encryption.
Javascript is the only language actually delivering on the promise of "write-once-run-anywhere." Well, "anywhere" that has a web browser, which is just about any device that does human interaction these days. All the other languages you mentioned have numerous environmental dependencies (separately installed run-times, OS specific conditionals, browser plug-ins, compiler specifics, etc.). Javascript sucks in many ways, but it sucks less than the alternatives for building an application quickly that can work just about anywhere.
That is, if you trust SSL and the certificate things, and trust that DigiNotar event can't happen, that there's no evil government running their own root CA, etc. To me, that's a big IF !
The traditional operating system controls access to hardware, virtual memory, provides an API and schedules processes. Something will still have to do that so the "traditional" OS isn't going anywhere. It'll probably just be less obvious.
However much webdevs might like it to happen, javascript won't be replacing Java, C++ or C# anytime soon for serious development.
As someone who has developed Java professionally for a while, I can say that having to pepper 100s of interfaces in the code just to do a closure then write a bunch of cruft to use it is kind of annoying. Not to mention Java the most verbose language gave birth to a bastard child for configuration: XML. I prefer to build cool stuff, not write a bunch of needless code. If JavaScript replaces Java it will be because the JavaScript shops developed better software, faster while the Java shops where writing XML. I have been doing 90% JavaScript the past year or two, solely because of the faster dev times and it's a better language than Java.
...import his private and public keys into the local database...
That's what they want you to think....
Hushmail lost a lot of credibility a few years ago when it turned out that its most commonly-used encryption method that ran server-side was delivered in a modified state at the request of government agencies. Yes, there are issues with trusting anything server-side, but its promises started sounding hollow when the CTO openly admitted it.
If you built your own applet from the public source code, the interception was not an issue, but if you used the easier mechanism hosted by Hushmail, you were at risk of your mail being decrypted and turned over.
http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/
You can never go home again... but I guess you can shop there.
"ease of moving between computers,"
Who moves between computers to do documentation? I mean really, is your company so skint it can't afford laptops and you have to work in netcafes?
This will make basic encrypted messaging tough to block by oppressive regimes like Iran and China. This is good for basic personal freedom.
A secure channel: like a for example a browser extension loaded from your local HDD/SDD ? Which this is.
New things are always on the horizon
Don't forget XSS attacks. XHTML can help here by its strict error handing, and I have suggested logging XML errors to a server before.
No it wasn't, the author of that article specifically takes on the idea of the crypto being delivered through a secure channel, having two basic objections: 1) If you have a secure channel already, then you don't need JavaScript encryption; and 2) JavaScript is completely malleable at runtime, and so you can't guarantee that running code, or the functions/libraries/objects on which it depends (down to the very basic JavaScript objects), will remain unmodified and trustworthy.
The first issue applies to a little different problem than the one being solved here. While the author was considering client-server communications, what we're dealing with here is a different use: end-to-end email encryption. That is, the browser-GMail encryption of the user session and all its contents is already taken care of by HTTPS, but GMail still knows what your email contains. This is, as I understand it, an attempt to encrypt/decrypt the text of the email on the client, such that GMail would only see the ciphertext and never receive the cleartext at all.
Fine in theory, but the second issue would seem to me to still apply. I haven't looked at their source, so maybe they've found a way to avoid this, but if any code from a server can interact with the code from this plugin, then it isn't obvious how the code remains trustworthy, no matter how secure the original channel was through which it was loaded.
Link-level, yes. However, what if google's certificate got hacked? With your emails signed and encrypted (especially on the client side) it would add en extra layer of security.
I honestly believe being another DigiNotar event victim is a few orders of magnitude less likely then having some script kiddie hack my account.
Ach, mein Gott. A granddad of computing deigns to pay me a visit !! :-))
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
You are being extremely naive. There was about 3 registrar issues last summer, and it's a well known FACT that governments (at least China and USA) are playing with certs (there was some real life cases reported, it's not just wild guesses here...). So if a government wants to get your key, it'd be really easy for them to replace the HTTPS hosted javascript. Do not forget too that there's the patriot act, and that you may very well be considered as a terrorist (everybody is, these days).
I said it was for personal stuff. I can get at my Google Docs on my laptop, on my home desktop, on my partner's PC, on my parents' PC... anywhere.
That said, if I ran my own company, I'd use Google Docs too.
Are you the only one who realizes that "Honeycomb" refers to the cereal product? Really?
Stephen D. Williams
:-)