3
$\begingroup$

Alice and Bob want to communicate using a stream cipher. At the beggining, they create a session key $K_s$ and exchange it via some secure channel (using some asymmetric algorithm). After every message, they want to append a MAC value to verify their identity.

The question is this:

Should I have a direction flag $D_a$ and send

$$ C:=Enc(D_a, M) || MAC_{K_S}$$

or generate a new key $K_a$ for each participant (for a total of 3 keys in my example) and send

$$ C:=Enc(M) || MAC_{K_a}$$

The second scheme looks more solid to me, assuming static direction flags. Intuitively I believe the two schemes are equivalent if the flags change after each message. Is this correct?

Notes:

  • When I say they exchange a key what I mean is they agree on some seed and use it to generate a pseudo-random stream using a PRF. For a long enough seed (32 bytes) and periodic re-seedings, I do not see anything wrong with this but any comments would be appreciated.

  • The encryption method is $C_i:=S_i \oplus M_i$ for some stream $S$.

  • For two participants generating the same stream, one uses every odd $S_i$ and the other every even $S_i$.

Improve this question
$\endgroup$
2
  • $\begingroup$ I think you mean 32 byte seed, but you forgot the nonce in the scheme, which would eliminate the need for direction flags if there is no nonce overlap between parties $\endgroup$
    – Richie Frame
    Sep 8, 2013 at 20:43
  • $\begingroup$ You're right about the seed length, sorry about that. Correcting now. About the nonce, where I present the alternative equivalent if the flags change after each message, that's what I mean so you've partly answered the question. Poor wording on my part. Cheers @RichieFrame $\endgroup$
    – rath
    Sep 8, 2013 at 20:48

1 Answer 1

Reset to default
2
$\begingroup$

Either method is fine. They're both secure. You can use whichever feels more convenient, given your application setting.

Better yet -- don't try to design this kind of thing yourself. Instead, use an existing scheme for providing a secure channel abstraction (e.g., TLS).

Improve this answer
$\endgroup$
1
  • $\begingroup$ Ah, the obligatory "don't roll your own crypto". It's more of an excersise for me to play with mlock() and family but getting familiar with OpenSSL would be a good excersise as well. Cheers $\endgroup$
    – rath
    Sep 9, 2013 at 1:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.