Reputation
209
Top tag
Next privilege 250 Rep.
View close votes
Badges
2 8
Newest
 Yearling
Impact
~10k people reached

  • 0 posts edited
  • 0 helpful flags
  • 20 votes cast
Jan
3
awarded  Yearling
Nov
15
awarded  Nice Question
Oct
22
accepted Proving the security of a one-way function with partially known input
Oct
15
comment Proving the security of a one-way function with partially known input
The one we are commenting on right now. As far as I know, an OWF needs to have one parameter, and the scheme does not require any parameters (assuming TXT is not passed as a parameter). But I may just be missing something obvious here.
Oct
15
awarded  Commentator
Oct
15
comment Proving the security of a one-way function with partially known input
@RickyDemer Interesting approach, I did not think of that. However, I am not quite sure if it is applicable here, as I am not sure that there is a way to model the scheme as an OWF (the reasons for that are discussed in the question). Did I miss a way to model this, or is there another way around this problem that makes the method applicable?
Oct
15
comment Proving the security of a one-way function with partially known input
@RickyDemer Are you refering to a proof by reduction, or what do you mean by "giving a counterexample"?
Oct
15
asked Proving the security of a one-way function with partially known input
Sep
24
comment Secure and unlinkable identifiers
@poncho The second problem is that it will be a client/server system, with mobile devices being the client, so I'd rather avoid sending large amounts of data and doing a lot of computationally expensive stuff, if at all possible.
Sep
24
comment Secure and unlinkable identifiers
@poncho Thank you for the links. While the second appears to be a somewhat standard "Let's throw more computational power at the problem until it disappears", the first one seems really interesting and promising. I'll read it in detail tomorrow. However, my question still stands, both out of curiosity and because I'd have to implement the cPIR system in two programming languages, which is bound to create a lot of problems, while hash functions are available for pretty much any language these days.
Sep
24
asked Secure and unlinkable identifiers
May
24
accepted Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
May
24
comment Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
So, basically, it really is a case of "someone standardized it like this and they never got around to changing it because of backwards compatibility". Figured as much, but good to have it confirmed. Thanks!
May
24
comment Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
I re-read the question and noticed that this was indeed not very clear. I have updated it to make this more obvious.
May
24
revised Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
Clarifications
May
24
comment Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
I think you misunderstood the question. I was referring to the actual operation of the protocol after the handshake has finished, and the order in which the encrypted content of the connection is encrypted and authenticated. You seem to be talking about the handshake protocol itself.
May
24
awarded  Editor
May
24
revised Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
Consistent use of {Authenticate,MAC}-then-Encrypt
May
24
asked Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?
Dec
10
comment Proving the semantic security of the One Time pad
Okay, so, to sum up your answer: there is no explicit proof for the semantic security, because we have already proven the shannon security, which is a stronger requirement and implies semantic security.