Re: crypto db

[andreas]

Hey rick, thanks for the link!
Now actually the previous link works for me too, maybe the server was just down 
because of the glibc issue or so ;-)

Interesting read.
And this is a complete different scenario than cryptodb, as this is about web 
clients, not native clients.

As I wrote in my other post, web client crypto is a problem. They address this 
by verifying the code with another server separate from the web application / 
database server.
If I understand it correctly, with Mylar you have 2 instead of 1 server, and 
only 1 of those 2 servers need to be absolute secure.
Though I'm not sure if this holds true, if an attacker starts to manipulate the 
web application code he might be able to completely replace the original 
application undetected, I think.
Still, I don't see how building a more complex system (more code = more bugs) 
with 2 servers from which 1 has to be properly secured is better then building 
a system with less code with one server and properly secure this one server.

There seems also to be a browser extension to verify the client side code, so 
this is more like having a native client then.
But yeah, user have to install the extension, and if you don't deliver that 
extension physically (CD/stick per postal mail) to them, then an attacker could 
temper with it, so its about securing a server again.

KISS.


- Original Message -
From: Rick Lyman [mailto:lyman.r...@gmail.com]
To: picolisp@software-lab.de
Sent: Thu, 18 Feb 2016 06:20:00 -0500
Subject: Re: crypto db

>This link https://css.csail.mit.edu/mylar/ is not working for me

https://www.google.com/webhp?sourceid=chrome-instant=1=2=UTF-8#q=mylar%20meteor%20pdf

Re: crypto db

[Rick Lyman]

>This link https://css.csail.mit.edu/mylar/ is not working for me

https://www.google.com/webhp?sourceid=chrome-instant=1=2=UTF-8#q=mylar%20meteor%20pdf

Re: crypto db

[andreas]

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 

Re: crypto db

[Alexander Burger]

On Wed, Feb 17, 2016 at 06:42:48PM +0200, Mike Pechkin wrote:
> question: is it hard to implement crypto-like-db with encryption on-the-fly?
> as example for local password manager, right?

I think it can be done easily with remote DB objects

   http://software-lab.de/doc/refR.html#remote/2

Data can be en-/decrypted locally, and stored in encrypted form on the
remote machines.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: crypto db

[Rick Lyman]

or, maybe:

https://css.csail.mit.edu/mylar/

On Wed, Feb 17, 2016 at 3:04 PM, Yiorgos Adamopoulos <
yiorgos.adamopou...@gmail.com> wrote:

> On Wed, Feb 17, 2016 at 6:42 PM, Mike Pechkin 
> wrote:
> > hi,
> >
> > first of all, i don't understand picodb and didn't write a line of code.
> > question: is it hard to implement crypto-like-db with encryption
> on-the-fly?
> > as example for local password manager, right?
> >
>
> Are you describing something like CryptDB?
>
> https://css.csail.mit.edu/cryptdb/
>
>
> --
> "If technology is your thing plan to die reading manuals" --Gene Woolsey
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: crypto db

[Yiorgos Adamopoulos]

On Wed, Feb 17, 2016 at 6:42 PM, Mike Pechkin  wrote:
> hi,
>
> first of all, i don't understand picodb and didn't write a line of code.
> question: is it hard to implement crypto-like-db with encryption on-the-fly?
> as example for local password manager, right?
>

Are you describing something like CryptDB?

https://css.csail.mit.edu/cryptdb/


-- 
"If technology is your thing plan to die reading manuals" --Gene Woolsey
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe