Re: OTP and message integrity.

From: Mark Wooding (mdw_at_nsict.org)
Date: 06/19/03 

Date: 19 Jun 2003 00:05:03 GMT

contact <contact@eversealsolutions.com> wrote:

> It appears you didn't read it all. The keys are OTP encrypted as well.

I read it all. I noticed that. It's just that appending the key and
hash to the message was where the hare-brained schemes took over from
the sensible crypto.

The objective seems to be to come up with some integrity check on the
message. This is at least a point most snake-oil purveyors miss, so you
deserve some quantum of kudos for that. The page doesn't make clear
exactly what the hash is of, which is something of a shame.

If the hash is of the plaintext, and the IV used for CBC mode encryption
is present (as is usually the case) then the scheme is insecure: an
adversary who knows the plaintext can modify the first block by toggling
bits of the IV through the OTP and compensate by XORing in the
difference between the old and new hashes; the scheme therefore falls to
a chosen ciphertext attack.

Again, if the hash is of the plaintext, DES's complementation property
provides an avenue for attack. If you include the IV explicitly, then
complementing the key (either just the last one, or all of them -- your
choice), the IV and the CBC ciphertext (all of which can be done through
the OTP XOR) gives another ciphertext which corresponds to the same
plaintext, meeting the formal requirements for a chosen ciphertext
attack. Alternatively, we can complement the first block instead of the
IV, and compensate the hash (though this requires known plaintext).

You can also modify the message using the DES complementation property.
By complementing the first plaintext block, the ciphertext and the key,
and patching up the hash, you end up with a valid message again. This
is a surprise for a scheme purporting to offer integrity.

I can't see any more attacks offhand, though this looks brittle to me.
Hashing the ciphertext may well be more secure. XORing the hash with
the OTP makes it look a little like an XOR-universal-hash-based MAC, and
the remaining difference -- the ability for the adversary to know the
XOR difference between the hashes of two messages -- looks like it's
been removed by the CBC encryption. But I'm still not certain about
that.

If the scheme is secure, it's secure by luck rather than judgement. A
proper scheme would use a Carter-Wegman MAC, neatly avoiding any
necessity to rely on unproven assumptions such as the security of 3DES
or SHA1. I stand by my description of EverSeal as snake-oil.

Oh, my. And now I've read the FAQ list. You hand out the random
numbers to the users? Oh, dear. The Crypto-Gram Doghouse beckons, I
think...

-- [mdw]

Relevant Pages

  • Vigenere++ Proposal of a (new?) cipher
    ... additional ciphertext shuffling phase. ... which is a fast hash function with a low collision rate and the Mersenne ... plaintext, "C" to indicate the i-th letter of the ciphertext and ... For each character of index "i" of the plaintext: ...
    (sci.crypt)
  • Re: Combined Signature and Encryption Schemes.
    ... A block cipher on the Plaintext, this gives me the CipherText ... A Mac on the Ciphertext ... digitally signing the MAC value would remove the need for a hash pass ...
    (sci.crypt)
  • Re: Baraks definition of obfuscation useful ?
    ... ciphertext to be decrypted is given as a challenge to the attacker. ... the plaintext if and only if the plaintext begins with "allowed". ... to win than the standard IND-CCA2 game, hence if the public key scheme ... is already secure, Adv_Awill be zero. ...
    (sci.crypt)
  • Re: Collision resistant encryption scheme
    ... scheme that is resistant to such collisions. ... sufficient conditions that can guarantee that such plaintext does not ... attack, because the pair {plaintext, ciphertext} must uniquely identify the ... differential leverage. ...
    (sci.crypt)
  • newbie: please help...just your opinion
    ... // Init hash ... //PASS2: Shuffle ciphertext ... pseudo random generator seeds does not reveal the plaintext, ...
    (sci.crypt)