On 6/17/2013 3:19 PM, Matt Caswell wrote:
On 17 June 2013 14:02, enrico d'urso <e.du...@live.com> wrote:
Hi, thanks for answer.
At the moment in my application I create an random IV and a random KEY.
Client after this creation send them to Server encrpyting all with RSA
public key.
Client decrypt the message with private key, and from this point the
communication will be based
on DES in cbc mode using IV and KEY just created.
in CBC mode the last cipher-text is used to recovery plain text (except for
first time , where IV is used).
Client gets input from stdin , encrypt and send the message to Client.
Since, user input is not always multiple of 8 byte (in size) I need to use
some form of padding, to make this I used Encrypt_final .
After called Encrypt_final you said me that is needed to recall Init
function.
Could I use always the same IV to make this?
Use the old cipher-text is wrong?
Recreate an IV and send it to Server seems result in bad perfomance, no?
I'm repeating the question because I added several details.
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.
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.
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.
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
