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.

I'm writing a client-server encryption scheme for homework, and I've stumbled upon what might be a fatal blow to my current implementation.

When using AES-256-CBC on the two sides, it's important that the client's encrypt context and the server's decrypt context remain in sync. However, my protocol allows for rejection of messages if they fail an HMAC test.

If a message were to fail the HMAC test, then the two contexts fall out of sync because the state of the context was polluted by the garbage ciphertext. All subsequent decrypts will fail. Is there any way to rollback a decryption, i.e. bring it back to the state in which it was before the decrypt happened? Alternatively, is there any way to copy an decrypt context?

The same goes for the client when it receives word of the failure. It's going to want to roll back its encryption.

Should I use something other than CBC mode?

share|improve this question

migrated from stackoverflow.com Feb 12 '12 at 22:25

This question came from our site for professional and enthusiast programmers.

1 Answer 1

You should packetize, or recordize, the messages into discrete units of a size reasonable for your protocol. Each record should be independently encrypted with its own IV. As an example, look at TLS 1.2 record or IPsec ESP packets. If a record is corrupted it can be discarded without impacting other records.

EDIT:

As pointed out by @poncho, TLS incorporates an implicit sequence number in the MAC calculation. Thus this may not be a good example. He also points that DTLS includes an explicit sequence number, and thus may be a better example.

share|improve this answer
    
So essentially switch to counter mode and use the sequence number in the HMAC? –  Alex Feb 12 '12 at 16:27
    
@Alex: No, simply send the initialization vector for each message with the message itself. Of course, this only works if the attacker inserts only whole packets, i.e. for a packet-based protocol. For stream based protocols it is usual to break the connection when a packet comes with wrong MAC. –  Paŭlo Ebermann Feb 12 '12 at 17:30
1  
@GregS: While IPsec ESP is a good example, TLS is not. A corrupted TLS record shuts down the connection; even in TLS 1.1 (where the IV is included in the record), there is an implicit reliance on a sequence number, which must also remain in sync between the sender and the reciever. Perhaps you meant the rather more obscure DTLS (which has the sequence number in the record as well)? –  poncho Feb 12 '12 at 22:42

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.