This link https://css.csail.mit.edu/mylar/ is not working for me.
@cryptdb / searchable symmetric encryption:
This is a system where you have a client application (not web browser !) and a
database server.
The point is to encrypt any data already on the client side, also encrypting
queries the server should execute.
This is very complex, can not be done with all kinds of data, and costs a lot
perfomance.
The catch is to be able to build encrypted indexes, so you can do encrypted
queries against the db without having to download the full encrypted db to the
client and decrypt there (no point of having a server then).
Here is a good presentation explaining this:
https://media.ccc.de/v/32c3-7333-the_magic_world_of_searchable_symmetric_encryption
If you got the necessary skills in crypto, math and statistics to build such a
system, then it might be easier to implement with picolisp then with classic
SQL, because you have basically to write your own DBS specific to your data.
And the whole point of this is, not do to encryption/decryption on the same
computer as the DB is, so I would see this is rather not fitting the usual
usage of picolisp DB.
#Edit:
After discussion with Abu a bit in IRC, this could more easily be achieved
indeed with pilDB and block-wise encryption using *Ext mechanism.
You would need to write a custom (commit) function which encodes the blocks
before sending them to the remote server. And using *Ext mechanism with custom
reader which decrypts the blocks.
Different then in cryptdb and similiar systems, you would run queries locally,
but you only fetch the necessary blocks (index and/or database records) from
the remote fully encrypted db.
@web & client crypto:
Don't do client side crypto in web applications. The idea of it is a complete
joke, even as there are libraries and serious projects for it around.
Whenever crypto is done in JS, then the server delivering the JS file has the
complete control over the encrypting code, so you could rather just do it on
the server.
If you don't trust the connection to the server, then you are also unable to
deliver the JS securely. Its a joke.
Could be done with a browser-plugin or native client application, but yeah,
then its not a web application anymore.
Also if you don't go the very complex path of cryptdb/searchable symmetric
encryption, the server must still have control over the crypto to make
meaningful indexes and fulfill the task of a db instead of being a simple file
storage.
@crypto on server:
I see several options:
A) block-wise encryption
pilDB writes data in blocks into the database files. One could encrypt every
block, so one would still have index-ability but the stuff would be only
encrypted on the filesystem.
This would need changes in picolisp source code. Not easy but doable. Edit: Abu
just stated in IRC that this could also be done via the *Ext/Remote mechanism,
no pil source changes necessary then, only custom lisp code
Easier it would be to do disk encryption like LUKS (thats what comes with
standard ubuntu) and place the db then on such a specific encrypted volume,
then the OS is doing the encryption/decryption on writting/reading
automatically.
This I have in use, actually.
B) property-wise encryption
Encrypt data before (put>)ing it into database objects. I think this is what
applies to Abus comment, of course you can do it for remote DBs too.
Catch:
When the encryption happens on the server, you have to trust the server.
Stuff is still unencrypted in RAM. Filesystem/storage encryption protects you
if someone steals your database files. maybe encrypt the files when doing
backups.
But if an attacker has access to the server to steal this files, it is likely
he is also able to change the server program code, to disable the encryption,
though this needs more skill.
@Conclusion:
Full symetric encryption of the db as in cryptdb is very complex, depends on
the specific data you wanna store, and I use pilDB usually locally or for web
applications, both scenarios where it doesn't make sense.
Server crypto can increase the difficulty and efforts needed by an attacker.
Question is, about what kind of adversary are we talking here?
Private hacker who gained access to your server and steals your files? You
fucked up somewhere for real, if that happens, and he could still change your
code on server to get around encryption (needs picolisp knowledge, not very
widespread).
Physical stealing of the hardware? filesystem/disc encryption protects, if the
machine is down when the guy runs with it. Most police squads doing such stuff
have this days methods to keep the machine running while transporting it away.
Your server hoster (or someone hacking him / putting pressure on him): he just
makes an image of your running machine and grabs the necessary keys and stuff
from RAM copy, I would think.
1) if you really want a remote fully-encrypted db, write a cryptodb-like with a
local pil