57 reputation
3
bio website
location
age
visits member for 1 year, 10 months
seen Dec 4 '12 at 17:04

Dec
2
awarded  Commentator
Dec
2
comment SSL Key Exchange
Well but key agreement isn't secure without additional measurements as well if the data can be manipulated? At least that's how I understand it. I also don't know of any method that can provide authenticity without a write-secure-channel existing at some point before the key agreement. That's why I excluded that possibility. Is there such a method? I'd love to hear about it.
Dec
2
comment SSL Key Exchange
Clear description: Client sends public key to server. Server generates random symmetric key (+IV), encrypts it with the clients public key and sends it to the client. The following communication is encrypted with the symmetric key. (Assuming the messages can be read by a third party, but not manipulated.) -- The forward secrecy argument convinced me. Didn't think of that, thanks. :)
Dec
2
comment SSL Key Exchange
So the method would be secure (assuming no one can manipulate the connection), but you would prefer a key agreement instead of a key transport protocol. May I ask why? It just seems like more work to me. Which properties does key agreement have that make it preferable?
Dec
2
comment SSL Key Exchange
The client usually doesn't have a public key? Why not? Is it that hard to generate one?
Dec
2
accepted SSL Key Exchange
Dec
2
comment SSL Key Exchange
Okay, good point. So when the client generates the session key, one could easily repeat the exact same conversation later. One doesn't know what effects that will have, but they're potentially not desired. But when the server generates the session key - shouldn't that be fine? Is there some technical reason why the server doesn't just generate the full session key and sends it to the client?
Dec
2
asked SSL Key Exchange
Dec
1
accepted Stopping timing attacks on AES: Why is it important to prevent the OS from interrupting the AES computation?
Nov
30
awarded  Scholar
Nov
30
accepted AES timing attacks
Nov
30
asked Stopping timing attacks on AES: Why is it important to prevent the OS from interrupting the AES computation?
Nov
30
comment AES timing attacks
I'll wait until tomorrow and if nobody answered the question by then, I'll accept your answer and ask on stackoverflow. I don't see any use in posting it here again, considering the still very low amount of questions on this site, I doubt anyone could've possibly missed it. :)
Nov
30
comment AES timing attacks
Thanks for the answer. You kind of didn't address my second question though. :) And I have a follow-up question that came up in the comments: Does a timing attack make any sense at all when the plain text isn't known? I can't imagine how this scenario could possibly leak information, but maybe I overlook something.
Nov
29
comment AES timing attacks
@owlstead But how? If you don't know what actually takes longer to encrypt, how are you going to deduce anything from that?
Nov
29
comment AES timing attacks
@owlstead Not affecting performance to much was the idea behind this. Yes, the answer from the server comes later, but after all the CPU can do something else while waiting. (Handling another client.) -- Well that was my question. As I understand it, there would be no point in measuring any timings, if you don't know what data gets encrypted? What knowledge could you possibly gain?
Nov
29
comment AES timing attacks
@owlstead Please note that I didn't wrote "wait a constant time" but "wait to a constant time", meaning that network messages are only send on e.g. 10ms "ticks". -- For a timing attack the plain text must be known? An encrypted chat for example shouldn't even be affected?
Nov
29
awarded  Student
Nov
29
asked AES timing attacks