Hi All,

A follow up in case others approach this bridge in the future.

Is another possible solution the following:
Derive DL_EncryptionAlgorithm_Xor_NULL
This will apparently Encrypt, but Decryption fails...

Jeff

template <class MAC, bool DHAES_MODE>
class DL_EncryptionAlgorithm_Xor_Null : public
CryptoPP::DL_SymmetricEncryptionAlgorithm
{
public:
   bool ParameterSupported(const char *name) const {return
strcmp(name, CryptoPP::Name::EncodingParameters()) == 0;}
        unsigned int GetSymmetricKeyLength(unsigned int plaintextLength) const
                {return 0;}
        unsigned int GetSymmetricCiphertextLength(unsigned int plaintextLength) 
const
                {return plaintextLength;}
        unsigned int GetMaxSymmetricPlaintextLength(unsigned int
ciphertextLength) const
                {return ciphertextLength;}
                //{return 0;} //Grabbing at straws now...
                //{return CryptoPP::SaturatingSubtract(ciphertextLength, 
(unsigned
int)MAC::DIGESTSIZE);}
   void SymmetricEncrypt(CryptoPP::RandomNumberGenerator &rng, const
byte *key, const byte *plaintext, unsigned int plaintextLength, byte
*ciphertext, const CryptoPP::NameValuePairs &parameters) const
        {

       return;
        }

        CryptoPP::DecodingResult SymmetricDecrypt(const byte *key, const byte
*ciphertext, unsigned int ciphertextLength, byte *plaintext, const
CryptoPP::NameValuePairs &parameters) const
        {
       return true;
        }
};

On 11/11/06, Jeffrey Walton <[EMAIL PROTECTED]> wrote:
Hi Wei,

> first template parameter to
> DL_EncryptionAlgorithm_Xor.

Is another possible solution the following:
Derive DL_EncryptionAlgorithm_Xor_NULL from DL_SymmetricEncryptionAlgorithm?

Is ECIES using 'class MAC' for anything other than T in the (C,V,T) object?

Jeff

template <class MAC, bool DHAES_MODE>
class DL_EncryptionAlgorithm_Xor : public DL_SymmetricEncryptionAlgorithm
...
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