Hi, I will consider the fact to use an other mode of encryption.
It seems best solution in my case.
Thanks for support.
Best regards

Enrico

Inviato da Samsung Mobile

Matt Caswell <[email protected]> ha scritto:

>On 17 June 2013 14:02, enrico d'urso <[email protected]> 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.
>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.
>
>Matt
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>User Support Mailing List                    [email protected]
>Automated List Manager                           [email protected]
>

Reply via email to