Timeline for Appropriate AES key length for short term protection
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 5, 2013 at 14:15 | comment | added | pauluss86 | I hate to pollute the comment section.. Would the combination AES with a Rabin Signature Scheme be a proper solution in my scenario? Both would persist for the whole session. Each message would be encrypted (AES) and the resulting ciphertext (ct) signed using RSS (s). A peer would send {ct, s} to all other peers. | |
| Nov 5, 2013 at 12:49 | vote | accept | pauluss86 | ||
| Nov 5, 2013 at 12:49 | comment | added | pauluss86 | To broaden it a bit further: the intention of encrypting the message itself is purely to protect against outsiders. The case where peer A might intercept communication between B and C should not be a problem, because the protocol dictates that A should receive that same message anyway. So, a simplification of the problem becomes: what's a proper way to achieve message authentication and encryption here, without bloating the messages or requiring extreme computational effort? | |
| Nov 5, 2013 at 12:40 | comment | added | pauluss86 | I don't have enough rep to either chat or upvote your answer unfortunately. In reply to your chat message: my understanding was that DH would not be necessary in my scenario because RSA handles the AES key 'exchange'. After considering your comments I'm dropping the per-message key req.; it's indeed redundant because each peer is assumed to have all necessary public keys anyway. I'm reading up on your HMAC suggestion, which appears promising at first glance. One potential issue might be that there must be a secret key for each 'peer-pair', which complicates proxy-ing messages. | |
| Nov 5, 2013 at 6:11 | comment | added | John Deters | let us continue this discussion in chat | |
| Nov 4, 2013 at 23:55 | comment | added | pauluss86 | I've (hopefully) clarified my question a bit. Currently I'm in the process of researching your suggestions. Note that I'm a newbie regarding security, which may very well be the source of our misunderstanding here :-) | |
| Nov 4, 2013 at 21:43 | comment | added | pauluss86 | To add: the AES is for protecting communication in transit, but does not help with preventing MITM attacks. I could do it with RSA alone, but this would be slower (as you stated) than using AES for the message itself and only encrypting the AES key using RSA; which doubles as a digital signature. I'll update the scenario with some more detail. In any case, thank you for your time and thoughts! | |
| Nov 4, 2013 at 21:38 | comment | added | pauluss86 | But does this protect against the following (same sequence of events as example scenario but with tampering): (1) A encrypts: u=AES(x, AB), v=AES(x, AC); (2) A sends u to B, v to C; (3) v is lost in transit; (4) B sends ACK(x) to A and C; (5) C receives ACK(x), notices x hasn't arrived and requests x from B; (6) B changes x: y=tamper(x); (7) B encrypts: w=AES(y, BC) and sends it to C; (8) C sends ACK(y) to A and B. Question: who tampered with the packet? B can blame A or C; C doesn't know: either A or B; A doesn't know either: B or C tampered with the packet. | |
| Nov 4, 2013 at 20:32 | comment | added | John Deters | Here, try thinking of it this way: separate the key exchange from message encryption. If A and B need to talk, they exchange a temporary AES session key called AB, and persist it. When they have a second message, they reuse AB. Similarly, B and C exchange a key called BC, and A and C create AC. If A, B, & C all need to talk, they all exchange an AES key called ABC. Now, when future messages in your voting protocol happen, you only trot out AB, BC, AC, or ABC as needed. When the session is done, you delete AB, BC, AC, and ABC. Reuse keys in session, regenerate them for the next session. | |
| Nov 4, 2013 at 20:23 | comment | added | John Deters | I'm afraid I don't understand the problem with AES being symmetric as you've already stated a willingness to use it. Unfortunately the scenario sheds no light on the discussion. It might help to wrap it in notation indicating messages, encryptions, and keys. | |
| Nov 4, 2013 at 17:41 | comment | added | pauluss86 | I've added an example scenario. My issue is that AES is symmetric. My idea for the AES\RSA combo was due to performance differences and message size being variable. | |
| Nov 4, 2013 at 17:33 | comment | added | John Deters | That RSA encryption is very large in comparison to AES - on the order of thousands to millions of times less efficient. By comparison, it's extremely slow and expensive. (If you're going that route, why not forgo AES entirely and encrypt your messages directly with RSA?) With respect to your second comment, any peer can simply use the AES key exchanged at the start of a session to decrypt the message - no extra RSA required. | |
| Nov 4, 2013 at 17:08 | comment | added | pauluss86 | Regarding the key exchange. My idea was to use RSA to encrypt a per-message random symmetric key. Any peer can then use the public key received when the session started to decrypt the AES key and use that to decrypt the message. If the latter fails, the message was tampered with. Or at least, that's the idea. | |
| Nov 4, 2013 at 16:58 | comment | added | pauluss86 | Thank you for your comment. The message size depends on 'commands issued' and protocol overhead; given size\frequency is during '100% activity'. It should therefore be interpreted as an (estimated) upper bound. Due to the distributed voting scheme, each peer has to notify every other peer whether they agree with some proposed event. Therefore, one peer should not be able to send a different proposal to different peers. In this case, other peers might agree on some proposal, not knowing that they're in fact agreeing to different proposals. I'll update the question to better reflect this. | |
| Nov 4, 2013 at 16:44 | history | answered | John Deters | CC BY-SA 3.0 |