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
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.
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
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
>
If DES is not strong enough then you can use it to do EDE which is
pretty good.
- Brill
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
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
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:
Some work on this:
http://citeseer.ist.psu.edu/651647.html
http://scholar.google.com/scholar?hl=en&lr=&cites=11438733955405183159
Amir
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:
>
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.
[...]
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:
[...]
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.
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
If a bouncycastle implementation is working out for you on javascript,
I'm completely wrong and speed is no issue whatsoever.
Time will tell.
- Brill Pappin