michwill

Since the exploit is known: I wonder, is it possible to hack all these devices and let them DDOS localhost?

This stuff makes economic sense to retrieve at certain costs of space launch. As well as manufacturing some stuff (like optical fibers) in space, producing energy, sending nuclear waste there etc

It means "Clinton"

What do you think about:

* As space access becomes cheaper, which economic opportunities will open, at which price point?

* Mining asteroids and Moon

* Space manufacturing. Any manufacturing more feasible in space than on Earth?

* Space power plants (solar?)

* Beamed propulsion. Lasers or microwaves?

Very good. Basically, triggers similar intense "investor days" after the investor day :-D

I think, you may have the application with a different cloud provider or even in a different geographic location, so that you can keep keys away from the data. In this case you sort of distribute trust.

I wonder if uvloop will work with such pypy. The speed would be awesome!

There are many proprietary methods which are based on deterministic encryption + obfuscating word distribution, that's what most companies do.

We avoid doing that because of questionable security of such method. Also we tend to publish what we do (stay tuned for Hadoop paper :-)

ZeroDB doesn't use deterministic encryption (neither Hadoop product, nor open source database)

We have ideas how to make relational databases secure while running everything server-side, thanks to recent research publications [notably CipherBase from Microsoft Research http://www.cidrdb.org/cidr2013/Papers/CIDR13_Paper33.pdf] and advances in CPU hardware. Early days, but we'll probably test it first in the open source ZeroDB database [https://opensource.zerodb.com] and then apply the same method to existing relational databases.

Malicious server, apart from possibility of removing data, would look pretty unusual for the client (like returning incorrect data etc). So it's a good idea to look for these patterns. An attack would probably look like trying to use the client as an oracle, and that's pretty detectable.

But as MacLane pointed out in another comment this is only the case for the standalone database described in the ArXiv paper. The Hadoop scheme works quite differently

0db - that's I was thinking of. Way to fight 0days

Yeah, I guess a little early to retire MySQL and Oracle :-) Thanks for pointing out, legacy is more about DB2

The last is what's remembered best :-D.

But yeah, good point

Actually, I think it's not too hard to get a python library to iOS/Android (especially Android). But I see your point.

Reference implementation without dependencies would be just a more cross-language rewrite of these dependencies though, so would take quite a while. Good news is that authors of ZODB which we use as a dependency are willing to do that (and already do that) in a more cross-language way.

Huh, interesting comparison. Thanks for pointing that out! We'll read more about Datomic: maybe we can learn something useful from them

Deriving from passphrase is optional. Mainly, for development and testing, and also for users who are ok with passphrases.

Having a passphrase + server-saved salt makes it better than a passphrase with no salt (for brute-force by dictionary).

If you think about it, security of passphrase approach is tested all the time with Bitcoin brain wallets. Over there, private keys are derived using SHA256 (which is fast to compute!) with no salt. It's hard for humans to generate good passphrases, so these wallets do that for them (usually 12 words).

But yeah, in most production usecases it would be some certificate, or KMS

No, we don't use any techniques from CryptDB at all. We thought about doing server-side set intersections using some ideas from CryptDB but we decided to not do that.

In brief, we don't compute on encrypted data, we search for encrypted data using encrypted indexes (which are operated from the client, even though are located remotely).

The thing is that anybody who is able to initiate queries has access to that data. No need to do inference attacks over there :-) So, an adversary cannot query data based on particular distribution b/c it cannot initiate meaningful queries.

If an active server-side adversary can trick the client into doing certain queries is another question though.

Yeah, that is actually deterministic encryption.

Microsoft had a very interesting research paper called CipherBase (we cited it), but I think they didn't end up commercializing that research

Yeah, right. I guess, as long as we don't redirect encrypted content of a database to a sound device, we should be all right :-)

Yeah, actually that is true. Enigma worths mentioning as one of MPC references.

Looks like Enigma would have challenges in many practical environments (mainly because it involves a lot of small interactions between nodes, so should be affected by latency). So, it's more like a way to build "Etherium of private computations".

But, as you pointed out, it can have good clues how to solve the problem of active adversaries!

I don't think it's so much of a size issue. I'd use it for applications where you don't have too many simultaneous users of the same dataset (in future - that constraint would be only about simultaneous writing users).

When users have their own private datasets, that's ok to scale up number of users though.

This limitation comes from a) invalidation requests and b) limited ability to do server-side conflict resolution

In fact, the approach you used for actor (using GWT) is no less applicable to us (using pyjs or rapydscript - see https://medium.com/@ZeroDB_/zerodb-js-zerodb-in-the-browser-...)

Yep, relevant pieces, thanks for bringing this!

Our performance become a little better since then. And also we'll update our fulltext search algorithm using Lucene's practical scoring function: that makes it more scalable and will also help with performance.

As number of clients grows, things actually become better for read queries (as long as we support MVCC). However, multiple writing clients can create congestion if they write data to the same place which can affect the performance indeed.

Also you cannot do queries on the encrypted db without being able to observe the results. E.g. if you are able to initiate a query on a fraction of the data, you already have access to that fraction of the data. And you cannot initiate a meaningful query if you are a server-side observer.

Of course, active adversaries could give wrong results (wrong pieces of the index) back, we didn't quite consider yet which problems that could cause.

You are right about the identifiers. And that is exactly what makes us concerned about access patterns attacks.

They are not as dangerous when queries are rare. But we do explore possibilities to mitigate this attack vector completely using oblivious RAMs which become more and more performance.

You are also right about clients updating the b-trees. Currently we use object-level locks to keep data consistent. We may add storing deltas for buckets to keep them on the server when a conflict appears plus use additively homomorphic encryption for counters (BTree.Length object).

Uhh. I'd think, Crypto.Random is supposed to be secure: """Return the specified number of cryptographically-strong random bytes."""

Pretty sad if it is not the case! Interestingly enough, RNG in pycryptodome which I was using for zerodb is urandom. https://github.com/Legrandin/pycryptodome/blob/master/lib/Cr...

Would be interesting to see similar gotchas about that library (though everybody uses PyCrypto, that makes me feel a little paranoid!)

Ok, actually the situation is following. We have some pilots with banks emerging in London where we need to work closely with them. I actually will go there and my wife will go to the US under visa waiver.

Seems like employment is going to be terminated at December 16, re-entry time - January 3.

Would there be any problems with this?

Hi Peter!

I am a citizen of Australia and I am going to switch on ZeroDB [http://www.zerodb.io/] fulltime pretty much now. For that, I have to leave my employer with whom I have an E3 visa (and I have a wife on E3D). Also I need to travel right after that.

Would there be any problem for us to enter back under Visa Waiver? Should we just fill an ESTA form online and have back out-of-US tickets on hand when we enter back? Any possible caveats here?

Another thing - my employer could technically terminate my employment very close to our date of re-entry (due to some corporate stuff). Would it cause problems in getting ESTA (when you are still technically on E3 visa but in a couple of days you're not)?

Thank you!