NYCPHP Meetup

[Joe Leo]

Thanks to all who have replied and commented to my questions. To Tim and
Dave, thanks for the input - your comments have all helped me to understand
quite a few things about the encryption. I think I've just graduated
encryption 101:) with much more to learn. Again, thanks for everyones
feedback!

Joe


On Sun, Apr 6, 2008 at 9:23 PM, Tim Lieberman <tim_lists at o2group.com> wrote:

> Joe Leo wrote:
>
> > The missing piece of info I guess I did not realize is that if I encrypt
> > some drive or part of it like folders or some system volume that I had to
> > have the decryption keys as part of it. I thought the keys was encrypted as
> > well. And, the only time it could be decrypted is by me.
> > So, If I wanted to modify and update the encrypted data I would then
> > download it back to my machine and decrypt it and make whatever changes and
> > upload it back to the server. While uploading and downloading the data it is
> > already in encrypted form.
> >
> That sounds correct.  In this scenario, you're just using the server as a
> file server.  Since your data are encrypted before leaving your machine, you
> don't need to worry about encrypting it (again) in transit.
>
> >
> > And, my understanding was that new data that is saved/updated by users
> > would be encrypted on the fly. Encrypted data that leaves the server would
> > be decrypted BUT then with SSL only the user would see the requested data.
> > This was my understanding of what tools like TrueCrypt does. So, I think I'm
> > totally missing the point of the product.
> >
> This is where things get tricky.  If your users are submitting data (over
> SSL), and the server is encrypting it for storage, you can use a symmetric
> key pair, with only the encryption key on the server (you keep the
> decryption key secure at your location).
>
> Things break down, however, when you want to give other users access to
> the data.  Now, the server needs to decrypt the data before sending it
> (which involves encrypting it via SSL, but you need unencrypted data to feed
> to the SSL mechanism).  Now, even with symmetric keys, you need both keys on
> the server.  Once you have encrypted data + the decryption key on the
> server, the encryption is meaningless, since if anyone compromises the
> server, they have all the information they need to decrypt the original
> data.
>
> Generally, if you're trying to communicate sensitive information via a web
> based application, you want to look at the following areas:
>   - The host security of the server.  Is the box hardened?  Are you
> running old, vulnerable versions of server software?  Do you have a strong
> password policy, or are you using SSH keys for authentication? Do you trust
> the people who have physical possession of the server?
>   - The security of whatever web-based application is managing the data.
>  If I can break your web-app, then I can steal your data (even if it's
> encrypteded on disk!)
>   - The protocol security of the protocols used to communicate with the
> server.  You should be using SSL (for web) and SSH (for shell access and
> file transfer services) -- otherwise you run the risk of a man-in-the-middle
> stealing your passwords, and subsequently your data.
>
> If those three areas are properly addressed, you should be fine.
> If the data is encrypted on disk, that's fine -- but as soon as one of the
> above three is broken, your on-disk encryption is essentially worthless.
>  Which of course means that before any of those are broken, it's probably
> meaninglessly redundant.
>
> Note, there's a forth concern: The security of the people who are allowed
> access.  Are you sure that user X isn't actually a spy.  This gets into the
> Authorization problem, which is probably going to get handled in your web
> app.  If you can limit people to accessing only the data they need, you
> limit your exposure.  This is a non-trivial problem, but there's a lot of
> good reading you can do about it.
>
>
> -Tim
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20080406/295e83cd/attachment.html>