On 17 June 2013 15:17, Jakob Bohm <jb-open...@wisemo.com> wrote: >> >> IV's should always be random - you should not reuse an IV. >> Using the the last block of cipher-text from a previous message as the >> IV gives a predictable IV which is insecure in CBC mode for certain >> classes of attack. > > > You are making the mistake of extrapolating from SSL/TLS specifics here.
Using a predictable IV is not an SSL/TLS specific problem. Your argument, is that there are certain situations where you can chain an IV across messages without it being predictable. I agree (further comment below)... > > The general rule for CBC and chaining the IV across messages is much > simpler and thus easier to avoid than in the specific context of > implementing SSL/TLS: > > 1. Never reuse an IV (it is OK if one random IV is the same as another > by chance, just not by choice). If you use a (chained) IV for > something and need to send it again, make the retransmission unchanged > (otherwise they see two different messages with the same IV). > > 2. IF someone else can (even indirectly) change some of the plaintext passed > to CBC, make sure their last chance to do so occurs before you send the > first byte of the block before the block whose plaintext they > can affect. Accepted. Although I'm not sure that's a "simpler" rule! It is safer in my view in the general case to advise against chaining across messages...doing otherwise is probably best left to expert users (such as yourself :-) ). > > For example, if using DES (8 byte block), if plaintext bytes 19 and 20 > comes from something that others can influence, make sure they cannot > do so after you send byte 8, because bytes 8 to 15 are the IV of bytes > 16 to 23. > > It so happens, that the combination of SSLv3 and HTTP failed that > second rule by default, and various workarounds were added to randomize > the IV of each SSL record, one of those workarounds was to pick and > send a random IV with each record if the TLS version was 1.1 or higher. > > >> If you MUST use CBC then you will need to send an IV every time - and >> yes this could result in bad performance if you are sending a lot of >> these. Hence my recommendation that you consider an alternative mode - >> CTR (or perhaps GCM if you require authenticated encryption). CTR does >> not have a restriction on predictable IVs. >> > > CTR has a different and much more well known problem. CTR essentially > turns DES/AES/etc. into a stream cipher with all the well-known problems > and attacks that apply to those. Nobody bothers to write about that > because they think it is so obvious. Agreed. CTR is a good mode if you use it right and understand its limitations. If you abuse it you are in for a lot of trouble. But then that is probably true of crypto generally. I would also strongly advise that anyone using CTR (or CBC for that matter) properly consider integrity issues. Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
