network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 5 months |
| seen | Dec 4 '12 at 17:04 | |
| stats | profile views | 0 |
|
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 |
