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
