-
Notifications
You must be signed in to change notification settings - Fork 0
Security analysis #145
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
Security analysis #145
Conversation
I remove @dbosk's arguments against @sbuc's statements about receipt freeness and verifiability. I also slightly adapts them: - Footnote on desirable, stating it's probably impossible without violating verifiability. - Still don't make clear which verifiability: @dbosk argues eligibility, @sbuc individual verifiability.
|
I have not yet updated the security analysis itself to these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's run with this. I think we can remove (comment) the adversary model in Section II. I'll do that when I'm editing. Please push to submittable. One small question: is there a reason the adversaries are modeled in the numbered definition format? It would seem more readable to me if they were named A1 etc., same as the properties.
|
The reason I named V1, V2, V3, P1, P2, P3 was that I deemed them not formal enough for a definition, but the adversary was supposed to be a formalization of those properties, hence it got the definition environment. In the current state though, it's probably better to go for A1, A2, A3. I'll fix that. |
I've updated the definitions according to our discussions. Please have a look, PDF attached.