Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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$.

share|improve this question
    
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 –  Richie Frame Sep 8 '13 at 20:43
    
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 –  rath Sep 8 '13 at 20:48
add comment

1 Answer

up vote 2 down vote accepted

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).

share|improve this answer
    
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 –  rath Sep 9 '13 at 1:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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