Can you detail how can this support any of the features of a relational database? Filtering rows, joining tables, aggregation, ordering.

To clarify all misconceptions in other posts, having been to a talk of hers a few days ago, here's the encryption types involved:
    * RND (salted symmetric key encryption) - used for columns where no sql manipulation is needed
    * DET (unsalted symmetric key encryption) - used for columns that need to be looked up by equality
    * Partially homomorphic encryption - used for aggregation such as SUM()
    * Order preserving encryption - useful for inequality where clauses, indexes, aggregations such as MIN()
    * Searchable encryption - allows something like ILIKE on text columns

OPE is the most dangerous, but is rarely needed for the most sensitive fields. They've run CryptDB on top of phpBB and
some other thngs with acceptable overhead. Let me know if you have other questions.

Well, other sources do not typically threaten to send you to a special place to burn forever.

The ability to evolve of the ability to evolve may actually evolve.

I wasn't aware TLS-SRP patched browsers exist. In any case, these mechanisms will likely be adopted only if they can be embedded in HTML. Few designers are going to sacrifice their fancy login form for that ugly-ass browser window that asks for credentials. But allowing proper authentication in HTML forms would imply that you get all or nothing. Either all HTML forms that contain an input type="password" must use TLS-SRP for sending the credentials, or this cannot be adopted. Otherwise a MITM would simply alter the form to switch from secure authentication to plaintext authentication.

To the best of my knowledge , HSTS is merely the Strict-Transport-Security response header. The lists are just something
extra. The "not very useful" comes from the fact that you are still unprotected the first time you access the website. If the
attacker is present the first time you visit an website, he can remove that header via MITM. Otherwise you should be fine.

No, I meant what I said. "https.example.com" is an example of a host supporting HTTPS, yet the browser accesses
it by default as "http://https.example.com". You don't seem to have understood what I said at all.

Because of the lack of widely adopted HTTPS, browsers are default-HTTP. So if you type https.example.com in your browser,
it will first try to access it by HTTP. Sure, the host is sometimes nice enough to redirect you immediately to HTTPS. But the
redirection happens over HTTP (because that's how you accessed the website). Therefore, a MITM can easily prevent such a
redirect and keep you in the HTTP land (see sslstrip tool), where attacks are a child's play. So unless your victims are paranoid enough to
check the address bar to make sure "https" appears, or manually write https:/// in front of their links, or use an addon such as "HTTPS Everywhere", then providing HTTPS doesn't matter much.
What addons like HTTPS Everywhere do is they have a huge lists of websites known to support HTTPS, and they force the browser to go default-https instead.

In my opinion, good solutions would include:
a) make HTTPS-everywhere part of the browsers;
b) add some proper authentication and encryption in HTTP2.0 instead of bitching that it's the wrong layer. it's clear no-one is going to adopt HTTPS
        widely anytime soon; most websites require you to login, meaning you can perform encrypted key exchange (EKE) with them, which allows for two-way authentication, plus encryption optionally;
c) widely adoption of something like this: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security - not very useful, but still an improvement

As you said, it is the all-or-nothing that concerns me. I am not claiming that sandboxing
would magically solve all problems and that successful exploits would never be able to do
any harm. But being able to mount an attack such as "someone using MS Office somewhere might use it
to open sensible data, which we can steal" is not the same as mounting an attack like "we can use MS Office
to collect all stored passwords from all browsers and send them to us. And to spawn a keylogger". The MS Office
should have no business accessing the sensible data of other applications or their memory space for that matter.
I don't believe that the fact that Windows allows everything to stick its head where it does not belong is really an unsolvable problem.

Antiviruses are blacklisting, code signing is whitelisting. Both bad solutions in a world
where we have so many apps that keeping track of all of them is very difficult.
Besides, code signing does not solve the problem of too relaxed permissions. In the
situation presented in the article, MS Office is a signed piece of software.

Yes, this is a major issue, but I don't believe it to be one without a solution, should one really bother
to come up with a good implementation.

On a mobile phone, you (as an application) can refuse to run if an user does not grant access to
a resource (such as webcam), because you know for sure that every phone has an webcam.
This blackmailing procedure may not be so successful on a PC, where if the owner refuses to grant
access to his webcam to an app, the OS can make it such that it is impossible for
the app to distinguish between "the PC has no webcam" and "the PC has an webcam but
you do not have access to it". Doing this for most resources should make it a lot more difficult
for apps to trick users into granting more permissions than they need.

I have been saying this for ages. It is embarassing that the concept of "antivirus" still exists.
Its main purpose is to enforce a huge blacklist of .exe files that can harm you. Instead
of keeping track of million of apps that are evil, why not just apply some least privilege
principles and sandboxing already so that we can run an application without granting it
access to all our resources?

It comes as no surprise that everything gets moved to the web nowadays. One can safely
open a website without worrying that all his personal data can be accessed (such as Firefox
stored passwords). On the other hand, opening an application requires complete trust in the author,
which is simply too much to ask most of the time. Look how well "apps" have evolved in mobile
platforms. It is quite natural to prefer apps to websites, because it can be easier to have something run on startup
and be easily accessible whenever you want, as opposed to having to go through a browser. They
generally have less overhead and are more powerful. If Windows had a decent package manager
and proper privilege separation we would probably be living in a different world today.

For anyone who claims stuff like "but Windows has UAC", obligatory xkcd: http://xkcd.com/1200/

Could we take this offline (e.g. IM)? Discussing this way seems highly counterproductive.

> The more important question, however, is why did the alleged "needless use of
> RSA" trigger such a huge red flag for you? What is the reason we should not
> use RSA?

Because public-key cryptography, while being super awesome and very useful in
many situations, is orders of magnitude slower than private-key
cryptography (not only RSA, but everything that needs to deal with
exponentiations and multiplications of 2048bit numbers).
When I hear about hard-disk I/O and synchronization, I think of
encryption that must have almost no speed penalty (see Truecrypt).
Storing data in a way that can be retrieved only by the same person who stored
it is certainly not a good use-case for an asymmetric cryptosystem with huge
overhead. If I have to open 10000 file handles then the overhead of decrypting
10000 filekeys with RSA will not be negligible.

> If two files are identical (or even start off identical), having them
> encrypted to different cypher texts is a nice bonus to have.

Any Mode of operation that is not broken provides this feature, as
the IV is chosen at random. You do not need different keys to provide this
feature (hint: try running "echo -n a|openssl aes-128-cbc -k test -a" multiple
times on a terminal). Moreover, even if you do use different keys for each file,
those keys can still be encrypted with symmetric crypto.
Key-encrypting-key can be achieved with symmetric crypto alone. The use of
public key crypto appears only when those messages need to be authenticated,
signed or when multiple parties are involved somehow. Unless you do more fancy
stuff, such as distributed encrypted file systems or encrypted computation/databases,
data storage alone has little to gain from public key crypto.

As for the backup example, that does not make much sense. Why would a machine
need to look at any of the contents to perform a backup? Encrypted data should
in general be indistinguishable from random data (plausible deniability and
all). To backup encrypted data you simply copy it, there's no need to decrypt
anything. I see no reason why a backup machine should have any additional
insight on my data. And besides, how would that even work?
What would the backup machine be able to do? Decrypt? Encrypt? Encrypting new
files sounds useless for backupping (because you can't read the old ones).
Decrypting on the other hand, if provided to the backups machines, means that
they can read everything.

> And the bottom line is that all of the above just boils down to "industry
> best practices". It is the exact same thing PGP does when encrypting files
> and messages.

Truecrypt only uses AES. PGP uses public-key cryptography because it needs to
sign and authenticate messages (e.g. to prove that an e-mail has the author it
claims it has), which is a totally different usecase than what you have.

Do not get me wrong. This is not personal and I'm not attacking you, so stop
being so defensive. I simply made an initial comment that the devs don't seem
to know what they're doing in regards to crypto, and then you challenged me and
I simply detailed why I made the claim. I appreciate and respect open-source work, but
unless you can back up your design choices with pertinent arguments, try to
swallow criticism more easily. There's a reason why "don't make your own
crypto" is a rule of thumb for programmers. Unless you're working in the
field, let the experts deal with this. Or go study. "I have some crypto
knowledge" is not enough to justify modifying existent mode of operations such
as CBC.

> 3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.

a) You do not want to encrypt all files involved using the same symmetric key.
Care to explain why? There is nothing wrong with using the same key for multiple files.
Anyway, if the main key is leaked then all the keys can be derived, so how is this different than
using a single key? What additional security does this give? Is there a scenario in which a single-key symmetric approach
does not survive an attack but your approach does?

b) With this scheme, you only need to reliably and securely store one key
And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the
set of people capable of doing one direction of the operation differ from the set of people that can do it backwards?
Even if you use different keys for each file, you can still encrypt each of those keys with your master key, which can
still be symmetric.