Hi Wei,

I can't resist... Approximately how much of a size savings witll this
be? If the MAC is AES derived (I have not looked at P1363 yet), it
should be on the order of 128/8 or 16 bytes.

Jeff

On 11/10/06, Wei Dai <[EMAIL PROTECTED]> wrote:
When you decrypt an invalid ciphertext with ECIES, the DecodingResult
returned by Decrypt() should have isValidCoding == false. Is this not the
case?

V is a temporary public key created for the message, and is needed to
decrypt. T can be omitted if you do not care about the security properties
that it provides, but to do this you'll need to create a dummy MAC class
with a 0 MAC tag size and use it as the first template parameter to
DL_EncryptionAlgorithm_Xor.

----- Original Message -----
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
To: "Crypto" <[email protected]>
Sent: Saturday, November 11, 2006 2:53 AM
Subject: General Question on ECIES Operations


> Hi All,
>
> When one uses ECIES, an ECIES ciphertext object (V, C, T) is created,
> where:
>
> * V is EC public key
> * C is encrypted message
> * T is authentication tag generated from a message M
>
> If I tamper with the cipher text object (for example, change byte[ 0
> ]), and then decrypt, Crypto++ does not throw and error. I've gone as
> far as changing every third byte.
>
> How does one detect this (I would expect it would be caught during
> decryption using T)? On a side note, is it possible to pull out
> encrypted message C if V and T are not required (to further reduce the
> size of the encryption object)?
>
> Jeff
>




Reply via email to