Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
> these threats are orthogonal to Teaclave's design goals yes, I realize this now, and thanks for your suggestion :) -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#issuecomment-1837730938 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
Closed #721 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#event-11133282452 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
I wonder _why_ Teaclave needs to support such attacks because it seems to me that these threats are orthogonal to Teaclave's design goals. The attacks themselves, essentially, fall into the category of side-channel and statistical inferences that can be found in the DB research area. -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#issuecomment-1837540316 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
One condition is that attacker cannot select plaintext from table， but can select result of some operations like SUM, AVG etc. For protection someone‘s data, DB will filter result after SQL to avoid data source only one row. Attacker may not know any data in DB, but can use == to guess existed id and use SUM(n) and SUM(n-1) to compute target data. -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#issuecomment-1778900615 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
Since you can `SELECT` the table, why not use `SELECT money FROM table WHERE id=1` to get the money of user 1 directly? -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#issuecomment-1778861764 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
A simple case is: SELECT SUM(money) FROM table; SELECT SUM(money) FROM table WHERE id<>1; than I can compute the money of user 1 -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#issuecomment-1778388638 You are receiving this because you are subscribed to this thread. Message ID:
Re: [apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
The short answer is no but it could be implemented. I would answer the question more accurately and in detail if you could give more description about the motivation and threat model. It seems not necessary to resist the attack. -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721#issuecomment-1776736407 You are receiving this because you are subscribed to this thread. Message ID:
[apache/incubator-teaclave] Can Teaclave resist Multi-query Attack? (Issue #721)
Hi! I am interested in the way to resist Multi-query Attack. The multi-query attack method includes two attack ways: (1) One way to obtain the other party’s information is to tamper with the input content for each query, while keeping the query itself unchanged. For example, the attacker can obtain all the information of the other party’s join key through multiple join queries and tampering with the content of his join key each time. (2) Another way is to infer the other party’s private data by rewriting the query each time and comparing the results of multiple queries. For example, the attacker can use the where condition to limit the input of the aggregation function. The first time the query obtains the aggregation result of N pieces of data, the second time by changing the where condition, the aggregation result of N-1 pieces of data can be obtained, and then the attacker can obtain the original information of 1 piece of data by comparing results. Cam Teaclave help user resist this attack automatically? Thanks! -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave/issues/721 You are receiving this because you are subscribed to this thread. Message ID:
