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
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
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"?
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.
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
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.
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.
Feb
14
comment Why is triple-DES using three different keys vulnerable to a meet-in-the-middle-attack?
@owlstead Thanks for the Link. I would never use 3DES anyway, this was just a question raised and not answered by the Wikipedia article.
Feb
14
comment Why is triple-DES using three different keys vulnerable to a meet-in-the-middle-attack?
Thanks for your answer, but the question I was trying to ask is why Meet in the Middle won't work (or will not make the attack "cheaper") on 2 keys as opposed to three keys. Or is 114 operations a fixed value for meet-in-the-middle? EDIT: Seeing your edit, it now is a bit clearer to me what you mean. Thanks.