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 client application, binding the remote DB with *Ext mechanism to your 
client, as described above.

2) for local databases or server databases with an (web-) application in front 
of it, use filesystem/disk encryption if it makes sense to you.

3) hash passwords (property-wise encryption). you don't need the passwords in 
clear text. password hashing is done to protect your users from their bad habit 
of password-reusing when you get hacked.

4) the widespread SQL-injections don't apply to picolisp, which is a big 
security feature. database injection is hardly doable with pilDB, unless you 
execute/eval pil code directly submitted by user.

5) for web applications, I think the biggest attack surface is HTML injection. 
Check strings entered by user for injection of html/javascript code if you 
deliver those strings as web content back to users.

-beneroth

Reply via email to