Anyone try client-side encryption using gwt?
amic...@gmail.com
I'm thinking of using client-side encryption to give users some
assurance of privacy for their data.
Has anyone tried doing this with gwt?
What are the issues?
Are there any good resources on this topic?
Amir
Reinier Zwitserloot
1. virtually all crypto libraries out there, from hashes
(SHA-1/224/256/512 and the like - this is really all you need for
sharing passwords, you'll need more to encrypt everything) to
symmetric (AES, DES, blowfish, twofish, etcetera) to asymmetric (RSA,
DSA, 'public/private keypairs') rely heavily on register looping; the
idea that the maximum value an integer field will hold + 1 'loops
around' silently to the minimum value.
javascript numbers do not behave that way (they upgrade themselves
silently to doubles) - and GWT's 'ints', for reasons of speed, aren't
objectified stuff that software-matically does integer math, they are
just translated to javascript numbers. Hence this looping never
occurs, and all those libraries get confused, and they don't work.
You're FAR FAR better off finding a proper chunk of code designed for
javascript specifically, and wrapping that using JSNI.
2. There is little point to all this; it is IMPOSSIBLE TO PREVENT man-
in-the-middle attacks unless you have use an SSL (HTTPS) connection
with a valid SSL certificate from one of the root cert servers. The
reason is simple: The encryption libraries are themselves loaded from
your site; if someone has spoofed your site and/or controls some in-
between node of the network connection and uses it to hijack the
connection, it can supply completely different code, e.g. code that
does the same thing except it also form-posts all data, before
encryption/hashing, to your server. whoops.
3. this is a complete showstopper for all forms of asymmetric, and a
moderate showstopper for any data exceeding, say, 50k give or take:
javascript is slooooow and with the need to manually emulate number
overflows by any libraries, it'll be even slower. Encryption takes a
lot of CPU power. You see why this is a problem.
basically, use SSL. As annoying as it is, it's way safer than any
client-side encryption you can build in for these reasons.
Amir Michail
Elaborating on this, the idea is to give users peace of mind with
respect to privacy of their data. In particular, the server would
never see the data in an unencrypted form all.
For example, imagine gmail with this assurance. I think many more
people would use it even with the possibility of a man-in-the-middle
attack such as the one you mention.
Of course, a key problem is how would you implement search in this context?
Amir
Reinier Zwitserloot
with asymmetric public/private key pairs. I haven't tested this
hypothesis, but I posit that decrypting a standard mail by going
through all the hoops that proper encryption of such content would
involve waiting far too long; on the order of 30 seconds or more.
(decrypt hash of message using public key of owner to check it really
came from him, AND decrypting a symmetric key with your private key to
make sure only you can read the message, AND decrypting the message
with said private key, AND hashing message to see if the hash is equal
to the attached encrypted hash to complete confirmation that the
sender is really who you think it is) - that's a lot of calculations
javascript is not good at!
The idea is extremely nifty... but for now I think desktop clients are
the only place where you can pull this off. If you want to give this a
whirl, your first objective is to find a bunch of JS libraries for the
job, you'll need JS implementations of:
a symmetric key cipher algorithm: AES-128, DES-3, Blowfish, or at the
very least TEA-128 (that one is definitely the weakest of them all,
but is faster). No roll-your-own stuff will work because as Bruce
Schneier will tell you, the statistical chance that any non-standard
cipher is actually secure is about equal to the chance that exactly
484,123 thousand dollars will magically appear on your lap, right now.
It just doesn't happen.
an assymmetric key cipher algorithm: RSA-1024 is the only one that
really works here, because DSA is susceptible to timing attacks, and
given that timing is already a problem, introducing random delays just
to get around timing attack issues sounds like a bad idea. RSA-2048 is
a lot safer, but over 2x as slow, and, again, timing issues.
a hasher: SHA-224 is the minimum requirement here; SHA-1 is
effectively broken. Still, for arguments sake, SHA-224 is not that
much slower compared to SHA-1, so if you find a SHA-1, just for
testing speed purposes, you can get away with it.
Then do the following:
take a reading of the current time.
Decrypt a 128-bit random string with a private key of a pair with the
RSA-1024.
Decrypt a 224-bit random string with a public key of a pair with the
RSA-1024.
Hash with SHA-224 any random text of about a page in length.
Encrypt same random text with the TEA-128 or AES-128.
take another reading of the time.
Report the difference between the two time readings. If it's more than
5 seconds you are screwed.
If the libraries don't exist, hoo boy. I remember implementing TEA-128
in a similar scheme on WMLScript (the javascript variant for WAP/WML,
the html-lite version for phone browsers, that never took off). It
wasn't pretty, because it too suffered from non-looping constructs.
You have to basically emulate bit-registers due to the lack of bit
operators in javascript and the lack of auto-looping number types. TEA
is the simplest, by a mile, of the 3 items you need!
On Mar 25, 3:15 pm, "Amir Michail" <amich...@gmail.com> wrote:
> Hi,
>
> Elaborating on this, the idea is to give users peace of mind with
> respect to privacy of their data. In particular, the server would
> never see the data in an unencrypted form all.
>
> For example, imagine gmail with this assurance. I think many more
> people would use it even with the possibility of a man-in-the-middle
> attack such as the one you mention.
>
> Of course, a key problem is how would you implement search in this context?
>
> Amir
>
Brill
primitive... and I bet one of them could be compiled by the GWT
compiler.
I was using a very light impl for a J2ME project a while ago... if I
have time to dig it up I'll see if it'll compile however you can
likely find an implementation some place that you can use, just try
and make sure it uses as little in the way of external packages as
possible... i.e. you won't have access to the javax.crypto packages so
you'll have to re-implement what they use or find one that doesn't use
them.
If DES is not strong enough then you can use it to do EDE which is
pretty good.
- Brill
ishmal
The posts here are for the most part correct that SSL is the best
general-purpose way to encrypt your client-server communications.
Since your GWT client is likely from a webapp, you not only trust the
server because it is serving a site to you, but you also trust it
because it just served you the code that provides the client's side of
an encrypted conversation. So in this case, having faith that the
owners of the server will not be able to see your communications is
false.
However, there are methods of encrypting your data before it is
inserted into the system, and it can be done without breaking XSS
rules, for those cases where (a) you only want another end-user to see
your data, or (b) you only want -yourself- to see your data. In other
words, you -don't- trust the server, no matter what its certificate
says.
For those cases, I suggest you look at encapsulating your data in
secure wrappers:
IMHO, the best is XML encryption:
http://www.w3.org/TR/xmlenc-core/
..which is a nice simple format for protecting data in a wrapper
that can't be touched.
This is analogous to Java's SignedObject:
http://java.sun.com/javase/6/docs/api/java/security/SignedObject.html
An untrusted server owner would be able to perform traffic analysis
on packets like these (message size, frequency, from:, to:, etc),
but the semantics would be sealed.
bob
Amir Michail
>
> Amir,
>
> The posts here are for the most part correct that SSL is the best
> general-purpose way to encrypt your client-server communications.
> Since your GWT client is likely from a webapp, you not only trust the
> server because it is serving a site to you, but you also trust it
> because it just served you the code that provides the client's side of
> an encrypted conversation. So in this case, having faith that the
> owners of the server will not be able to see your communications is
> false.
>
I don't think it's so black and white.
It's possible for people to have more trust in a service that claims
to provide client-side encryption. Moreover, providing readable
javascript could help build that trust as well.
> However, there are methods of encrypting your data before it is
> inserted into the system, and it can be done without breaking XSS
> rules, for those cases where (a) you only want another end-user to see
> your data, or (b) you only want -yourself- to see your data. In other
> words, you -don't- trust the server, no matter what its certificate
> says.
>
> For those cases, I suggest you look at encapsulating your data in
> secure wrappers:
But how would you implement something like search in a gmail-like service?
Amir
Reinier Zwitserloot
must still be done by the server; and are thus impossible. No search.
Firefox's offline storage facilities might help there, but given
javascript's slowness, searching through a gig of mails is gonna be a
tough situation.
Brill: DES is laughably easy to break. It'll take my notebook less
than a day to break a DES key. DES-3 is still rock solid but compared
to e.g. the similarly secure AES-128, it's twice as slow. Given that
in JS land this is already a concern, DES-3 is right out, horribly bad
idea. AES or TEA; they are both fast, but TEA is fastER, while AES is
more battle hardened.
On Mar 25, 8:29 pm, "Amir Michail" <amich...@gmail.com> wrote:
Amir Michail
>
> Amir: If you do encrypt content, subsequent operations on that content
> must still be done by the server; and are thus impossible. No search.
>
Some work on this:
http://citeseer.ist.psu.edu/651647.html
http://scholar.google.com/scholar?hl=en&lr=&cites=11438733955405183159
Amir
Reinier Zwitserloot
analysis on encrypted data. I'm aware that on a technical level there
is some progress, but the humongous undertaking we're talking about
here means that, for this project, the time, relevance, and impact of
GWT is less than 1%. And, regardless, you'll have to run that test to
see how quickly a javascript library can run through the 4 steps
needed to read or write a properly crypted mail message of about a
page long, because my gut instinct still tells me that this entire
discussion is moot.
On Mar 26, 3:39 pm, "Amir Michail" <amich...@gmail.com> wrote:
> On 3/26/07, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>
>
> > Amir: If you do encrypt content, subsequent operations on that content
> > must still be done by the server; and are thus impossible. No search.
>
> Some work on this:
>
Brill
to compile into javascript :)
EDE (DES3) would be fairly simple in that case.
I agree that speed is an issue...the question is not is it fast but is
it fast enough?
I guess the only way to find out if its "fast enough" is to try it.
- Brill Pappin
On Mar 26, 12:34 am, "Reinier Zwitserloot" <reini...@gmail.com> wrote:
[...]
> Brill: DES is laughably easy to break. It'll take my notebook less
> than a day to break a DES key. DES-3 is still rock solid but compared
> to e.g. the similarly secure AES-128, it's twice as slow. Given that
> in JS land this is already a concern, DES-3 is right out, horribly bad
> idea. AES or TEA; they are both fast, but TEA is fastER, while AES is
> more battle hardened.
[...]
Brill
to keep secure on the server side.
there is certainly a lot you may need to do with the data on the
server side (search being only one) but there are also times when you
want to protected some very sensitive data.
I don't think this idea should be dismissed just yet and I think any
solution that used it would be a combined solution where only the most
sensitive data was client-side encrypted -- which also means you can
likely take the speed hit since your applying it to minimal data.
- Brill Pappin
On Mar 26, 10:00 am, "Reinier Zwitserloot" <reini...@gmail.com> wrote:
[...]
Reinier Zwitserloot
find some symmetric encryption, hash, and assymetric javascript
implementations, any serious one will do (as long as it meets minimum
security levels; plain DES is no good, DES-3 is fine), and see how
long it takes to run the gauntlet for a page-sized message. If e.g. a
DES-3 and RSA-1024 powered decrypt results in, say, a 10 second
waiting time, then you have a decent shot at optimizing it, and
switching to faster algos, to get it down to 3 or 4 seconds and call
it moderately possible. If it's 60 seconds or more, no snowballs
chance you'll get it in the range of workability. If it's a second or
less, grand, then this is all very very moot.
There are also alternatives possible (an applet, those are definitely
fast enough, or perhaps actionscript (flash) interprets faster - also
an alternative).
It's an interesting topic but to get it all working together, that's a
massive undertaking. I don't find it -that- interesting, just yet.
First I want to see how long it would take.
Brill
On Mar 27, 12:02 am, "Reinier Zwitserloot" <reini...@gmail.com> wrote:
[...]
> security levels; plain DES is no good, DES-3 is fine), and see how
> long it takes to run the gauntlet for a page-sized message. If e.g. a
> DES-3 and RSA-1024 powered decrypt results in, say, a 10 second
> waiting time, then you have a decent shot at optimizing it, and
[...]
Actually I was thinking that you'd want to encrypt small string values
and not entire pages of data... sensitive personal information like a
credit card number or something.
You encrypt it, and send it to the server for storage.
Anyway, since my last post I've got a TDES (DES-3) implementation
working. I grabbed some code from the GWTx project but most of it is
based on the Bouncycastle crypto API.
I haven't tested it extensively, but it seems to be fast enough to be
usable.
I would love for some other people to check it out and test it
(particularly skeptics... we're talking security here after all).
Since the file area here has been disabled, I started a code project
to host it: http://code.google.com/p/gwt-crypto/
the current spike can be found at: http://gwt-crypto.googlecode.com/files/gwt-tdes-spike-src.zip
if your interested in improving the code by all means send me a quick
not and when I get the project organized I'll keep you in mind.
- Brill Pappin
Reinier Zwitserloot
minutes per page.
If a bouncycastle implementation is working out for you on javascript,
I'm completely wrong and speed is no issue whatsoever.
Brill
it's working.
However similar code ran fairly well on a j2me cell phone which should
be oodles slower then even javascript on a reasonable desktop.
Time will tell.
- Brill Pappin