On 6/17/2013 5:11 PM, Matt Caswell wrote:
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.
No but many of the public about CBC and IV selection it appear to be
falsely extrapolated from limited information and then blindly
regurgitated.
Fundamentally, every CBC block except the first will use what you call a
"predictable" IV, namely the previous ciphertext block. To make any
sense security arguments about this need to be very clear about what is
and is not vulnerable.
Summarily telling anyone using CBC to never chain on from one message to
the next and/or to switch to inherently less secure modes such as CTR
just to avoid an attack that has so many other countermeasures is very
bad advise, especially when done in a public forum, which is why I could
not allow your bad arguments to stand unopposed.
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.
I have not seen any attacks on the "CBC IV problem" that were at all
preventable by integrity checks.
I have seen and used techniques that prevent the issue in a way which
is entangled with integrity checks, but the prevention is not due to
the integrity protection itself.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
