michwill

13 ms·

61.
by michwill 11y ago
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 pycryptodo
62.
by michwill 11y ago
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
63.
by michwill 11y ago
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
64.
by michwill 11y ago
Oh wow, thanks for the links, will need to go through that! We've seen gundb [ http://gun.js.org/ ] keeping data distributed between clients. Also, I'm even thinking if it is possible to run ZeroDB on top of SpiderO
65.
ZeroDB (end-to-end encrypted database) is now open source(github.com)
3 points by michwill 11y ago|0 comments
66.
by michwill 11y ago
In fact, soon we want to switch away from Python pickles (which also could have security problems) into serializing to msgpack. And that makes everything much better in terms of cross-language compatibility. So, things people dreamed about
67.
by michwill 11y ago
Heh, yeah.ZODB seems to be pretty good for the purpose here (it's performance is usually not the bottleneck). But when indexing large texts, it becomes a problem. One way to solve it is instead of using generic serializing for data str
68.
Pinterest rolls out (sub)image search using deep learning this week(technologyreview.com)
3 points by michwill 11y ago|0 comments
69.
by michwill 11y ago
1. Yes, this is a fair problem. Currently common solution is this. You encrypt data with, say, AES, and AES content keys with your public key. Whenever you want to share, you (not cloud) re-encrypt all the content keys for all people you wa
70.
Working with encrypted data without decrypting: CryptDB, ZeroDB and homomorphic(zdnet.com)
43 points by michwill 11y ago|14 comments
71.
by michwill 11y ago
Oh wow. Do you have a github repo?)
72.
by michwill 11y ago
ZeroDB here. We're not homomorphic, and it is possible to make a cloud hosting you're talking about w/o homomorphic encryption. But if you are to perform heavy computing on server side, you have to be homomorphic. Or other am
73.
by michwill 11y ago
Yes, that's currently the plan! More than that: when end-user is SMB but paying customer is a B2B cloud software vendor, needs are often the same as for startups.
74.
by michwill 11y ago
ZeroDB co-founder here. Basically, end-to-end encryption for client (browser, mobile) software vs protecting backend software which uses some flavor of SQL
75.
by michwill 12y ago
I think, your points are largely correct. You indeed need to lock multiple buckets when you commit data which could be slow. My point is that you can tolerate that if your application is something like gmail. Client A has his own tree saved
76.
by michwill 12y ago
> I assume michwill is probably taking notes! Yes, you're correct! ;-) > "one table, one source of truth, period," or "Use for write-seldom; read-often applications only," Right. Another model - "write an
77.
by michwill 12y ago
Thank you for making a very good comment! One thing which we will probably inherit from ZODB is server-side versioning of all objects. E.g. if something gets corrupted, it's easy enough to roll back to a previous version. If the model
78.
by michwill 12y ago
CryptDB doesn't use homomorfic encryption. It is doing sortable deterministic encryption. E.g. after encryption the server can determine whether a > b or a == b. They have a very good understanding of what data does it leak, when ca
79.
by michwill 12y ago
You're right, clients will be responsible for inserting data, re-balancing the tree etc.
80.
by michwill 12y ago
HN doesn't allow to reply too deep in the tree of comments, so I continue here. ZODB on which we base is ACID-complaint, so it cares about simultaneous writes. You either don't use cache, or get invalidation requests if you do (so
81.
by michwill 12y ago
Indexes are created where you told them to. So, if you include an arbitrary field, it's probably not going to be indexed to start with. And yes, query is for indexed fields. I guess, we can have another type of behavior where all new f
82.
by michwill 12y ago
I consider ZODB as more like a framework for quickly building databases. ZODB developers (we've talked to many of them) consider upgrading objects as no-problem (because they have very well understood patterns for that) etc. While that
83.
by michwill 12y ago
Usually it's order of 100-200 KB per query but caching things like the tree root makes this footprint smaller (e.g. second query is always faster than first one). We tested it with pretty ad-hoc parameters (just to check if it's p
84.
by michwill 12y ago
Yes, we think about it. This information is not rock-solid and changes with time as the tree re-balances. But for ultimate security, I think, we need something like a proper Oblivious RAM protocol
85.
by michwill 12y ago
Yes, you are right. The server stores indexes (which are actually trees), but the query logic is on clients.
86.
by michwill 12y ago
For example, full text search over your text queries, or range queries for your numerical data. The idea is that data in databases is organized in B-Trees, so we traverse those from a remote client. It is fast enough because usually only lo
87.
by michwill 12y ago
Good question. We thought about two cases. One is when your are sole owner of the data. The other is when the owner of the data is some group (like JP Chase). In this case we can have server-side quotas for handling cases when one or severa
88.
by michwill 12y ago
With mongodb, you either pass your key along with query or lose your ability to search. In our case, we don't pass the key to the server, yet having the ability to query
89.
by michwill 12y ago
It is scalable enough because you need to download log(index_size) rather than full index. The use case - any private data which you'd like to encrypt on the server while preserving ability to search. Medical records, financial data, e
90.
by michwill 12y ago
You're right, good that someone is familiar with ZODB! We plan to make it a full-scale database. For that, we obviously require to have some convenient query language (similar or even compatible with Mongo's). We've talked to

More ›