-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Role of EK_A (Is it really needed) #2
Comments
Hello @oblazy. We are happy to see you recognize improvements compared to ROBERT. Great. 1- Small comment regarding the (supposedly) "very strong assumption"this measure (EK_A encryption) is meant to protect against external attackers who may succeed to connect to the server, not against the authority, so this latter has no reason not to erase EK_A. And if we assume a collusion, then the adversary model is even stronger than our honest but curious one. 2- About the fact the server cannot derive any social graph:I really don’t know why you mention « the social graph »? In fact:
We really took great care in « preventing by design » any graph inference, not just by assuming the server is honest but curious. That’s a great improvement of DESIRE. Do you agree or is there anything I’ve missed? It does not answer your question but this is essential since you suggest the opposite. 3- About a DOS if the attacker targets random ID_A with erroneous EK_AIndeed, it could be an issue, which is why « we recommend the use of an authenticated encryption scheme. » Thank you for your valuable feedback. Cheers. |
Hey,
Thanks for this version, there are many things that seem interesting improvements compared to Robert :)
There is something I don't really understand: What is the point of EK_A?
As I understand, you use it to encrypt (and authenticate ideally (footnote 12)) the data in IDTable_A .
In Exposure Status Request
The server decrypts using EK_A, and continues.
At this step, an "implicit" authentication might be interesting, so i think your footnote 12 is important.
(I'd have a comment, iAssuming the server deletes EK_A if he is nothing but 100% trustworthy (not even HBC) is very strong... but oddly i think it's not necessarily useful)
Section 3 Risk Analysis
You say that encryption is here in case of data breach.
From my understanding, there are 4 things in IDTable_A: The "connections", SRE_A, and UN_A (and LPEM_A).
SRE_A, is the last epoch someone sent a Status Request, hard to find a use if it's anonymous
UN_A is a bit saying whether the user had an alert. While sensitive, ID_A is supposed to be an anonymous of A.
The rest are data that concerns the social graph, but here whatever attacks appear in case of data breach, also exists in case of malicious server, and as this data (mostly) only concerns the social graph (DH + ROM clearly hides the rest), either the server can do it, either he cannot...
There is also LPEM but it is never updated (the exposure time is sent by the sick users for example)
So it seems really strange to have an encryption, with facultative authentication.
If I am an adversary interested in the social graph, my attacks are (at best) the same as the server
If I want to deanonymize data, same.
However, i might be interested in causing a mess. So i send request for random ID_A, Q=EK'_A
If ID_A exist, the server will "decrypt" the data, and without authentication will then rencrypt it and cause a mess:
Authentication seems really important, to avoid DOS against someone, and (oddly) encryption is probably superfluous if you consider the social graph to be protected against malicious server.
(Authentication could be as trivial as the server checking that the decryption has indeed x leading zeros)
Did I miss something?
Of course, the space in which ID lives could be huge, making a collision highly unlikely. In this case neither auth or enc would even be required, and it would reduce the server load (which with millions of daily users would likely be happy to avoid several enc/dec for each for them) :)
The text was updated successfully, but these errors were encountered: