Re: OTP and message integrity.

From: contact (contact_at_eversealsolutions.com)
Date: 06/19/03 

Date: Wed, 18 Jun 2003 22:26:42 -0700

Besides the fact that you're offensive, I'll respond to some of your
questions.

"Mark Wooding" <mdw@nsict.org> wrote in message
news:slrnbf1vhe.18j.mdw@tux.nsict.org...
> 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.

And why would that be? Without the hash, the integrity couldn't be checked
at all.
Without the keys, the message couldn't be decoded.

>
> 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.

Gee thanks. Still, you're offensive. The hash is a standard SHA hash using
160/512 bit primes as per the standard.

> 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

If that were so, then every thing else would sorta be irrelevant. With the
exception of the ability to send a false message. But then the attacker
would also have to have access to the random number files and the code. If
he has that, then it seems he has the person's computer in it's entirity.

> 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.

The hash is of the 3DES encrypted data, just before the OTP step. BTW the
keys are different for each encryption, the random number files for the OTP
step are different for each encryption.

> 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

How would that be possible when a different random number file is used each
time for the OTP step?

> -- 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.
>

Gee thanks again. I doubt I care. I mean after all, this is not 'Virtual
Matrix Encryption' or 'we use a secret encryption system', phrases anyone
can laugh over.
Which brings up a point - what are you doing?

> Oh, my. And now I've read the FAQ list. You hand out the random
> numbers to the users?

The whole point was to provide well formed random number files. Which is
where most OTP schemes fail.

Do you think a PRNG would be better? Trust is a thing that is earned. And
maybe I haven't earned it fully but most all of you are using an OS or
browser that you have no idea what it does. 'Who do you trust?' is an
interesting question on the internet. I'm also working on a system to allow
the user to create his own random numbers using a hardware generator so that
would remove that particular criticism.

>Oh, dear. The Crypto-Gram Doghouse beckons,

Been there, done that. It's a shame that the man feels he has to attack
others to make himself feel good. On the other hand it did drive a lot of
traffic to my site.

> I think...

I'm sure you do. It appears you know a good deal about cryptography, less
about how to work with others. On the other hand, I am in business, so if
you or someone (US residents only please) would like to collaborate on a
product, you know how to reach me. (I'll keep it quiet lest you get
attacked). I'll also consider your more informative points.

>
> -- [mdw]

Relevant Pages

  • Re: OTP and message integrity.
    ... Without the keys, ... You provide some level of integrity, ... The encryption is provided by an OTP. ...
    (sci.crypt)
  • RE: Signing before Encryption and Signing after Encryption
    ... The property that a hash match is supposed to verify (is this ... Signing before Encryption and Signing after Encryption ... Signing with symmetric keys is a lot more ...
    (Security-Basics)
  • Re: Newbie - Is this Reasonable?
    ... because this hash is stored in the database. ... So you use PKCS5v2 to generate a key hash from a salt and the user's passphrase, then store the salt and the hash in a database. ... are even more critical in database applications because the payoff from tampering with selected fields may be much higher, fields tend to be fixed-length so it's easier to tamper with them in a meaningful way, and databases lend themselves to off-line analysis, so the attacker can marshall more resources and take more time to attack your system. ... You're using a stream cipher for encryption. ...
    (sci.crypt)
  • Re: Signing before Encryption and Signing after Encryption
    ... Hash: SHA1 ... Encryption and Signing after Encryption ... are signature schemes that only require symmetric keys. ...
    (Security-Basics)
  • Re: Encrypting incoming messages with GnuPG
    ... Hash: SHA1 ... Trick is to not write to disk prior to encryption. ... the 'nobody' user, and I've setup the GPG keys ...
    (Debian-User)