Re: CBC questions
From: Anton Stiglic (stiglic_at_cs.mcgill.ca)
Date: 07/30/03
- Next message: Henrick Hellström: "Re: Is there any weakness in adding static/known data (salt) to the password hash"
- Previous message: Nicol So: "Re: Surviving Einstein."
- In reply to: Terry Ritter: "Re: CBC questions"
- Next in thread: John E. Hadstate: "Re: CBC questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 30 Jul 2003 10:26:49 -0400
"Terry Ritter" <ritter@ciphersbyritter.com> wrote in message
news:5c88fd7a.0307292206.6dd49012@posting.google.com...
> 2. Just as in ciphers, I am aware of no *guarantee*
> that any particular MAC actually has the strength we
> generally hope it has. It is certainly inappropriate
> to trust any MAC (or any other cryptographic mechanism)
> absolutely. Accordingly, we cannot simply assume that
> using a MAC will solve all our security problems, because
> someday that assumption may be shown to be wrong.
But we do know OMAC pretty well, there are proofs of security
of OMAC based on the assumption that the underlying block cipher
acts like a good PRF. This is the same assumption needed to prove
that CBC-mode is a good encryption mode (we don't have any better
proofs so far). So as far as we know, both schemes rely on the same
assumption, if one is found to be broken some day, most probably
the other will be as well.
In other words, I'm saying that if you do CBC-Encrypt then OMAC,
and you find that OMAC is broken, most probably CBC-Encrypt will
be broken as well, and you've lost your confidentiality property.
>
> 3. When writing computer code, it is appropriate to
> handle problems at the level at which they occur.
> Software engineering calls that "information hiding,"
> which is used to help manage the massive complexity of
> computing. But complexity is even more of a problem
> for security: one common security maxim is that there
> are *no* secure complex systems. Accordingly, security
> coding should be far *more* interested in hiding
> information between computing levels and *less* eager
> to depend upon a higher level "doing the right thing."
Encrypt then MAC would be done at the same level (I mean
it will probably be done by the same library, and can be done
in one function call, if you don't trust that library all bets are off).
> 5. When the IV is not protected, each bit changed in
> the IV changes a bit in the deciphered plaintext first
> block. When the first block plaintext is known, that
> allows *particular* changes to be made which can
> deliberately change meaning or values in the first block
> while not disturbing the rest of the block or the rest
> of the message. The issue is of increasing import with
> larger blocks since more room is available to insert
> false information.
No problem if you MAC.
> 6. In contrast to the IV, when any *ciphertext* block
> is changed in transit, deciphering produces a random-
> like block which is quite unlikely to deliver any
> intended wrong message. Accordingly, changing the
> ciphertext does *not* support *systematic* changes to
> the first block in the same sense as changing an
> unprotected IV in transit. Whereas changing the IV
> can be an attempt at "deception," changing ciphertext
> is just "damage."
Not always, it depends on what the message is. I can
see some kind of client connecting to a trusted server and
asking for a random seed, which the server would include
in the beginning of the message. Changing the first ciphertext
blocks wouldn't be perceived if you don't have some kind
of authentication mechanism. Tell me, how would you verify
that?
See, this is where I think you are wrong, your idea of protection
is in saying that the message that will be decrypted will become
random-looking, but you provide no formal way to detect this.
How would you even code such a check? Have your program pass
a statistical test to see if what you decrypt is random and not
an english message? Or have the user inspect the decrypted message
himself (that's just not usable)?
It doesn't make sense, that's why they invented MACs, a MAC is a
message authentication code that can be automatically verified by your
software for you. The verifier re-computes the MAC and checks if
it's equal to the MAC it received, simple boolean procedure. No
playing around with "well it looks o.k., or no it looks random so it's
not o.k....". I would dub what you describe as a Fuzzy Message
Integrity Verification scheme.
> 7. The first-block CBC MITM problem is caused at the
> block level by the confidentiality failure of sending
> the IV in the clear. The problem is also easily fixed
> at that level simply by encrypting the IV. And since
> the problem can be completely fixed without any
> authentication at all, it is clear that the origin of
> the problem has nothing to do with authentication.
No, you are doing authentication, but it's fuzzy authentication,
and I don't see it working well for the reasons I described
above.
> 9. Because there is a simple complete fix at very low
> cost (albeit for this one problem only), it may at first
> seem odd that the fix should be opposed so widely and
> vehemently. It may be less odd to consider that some
> experts would seek to discount a deeper understanding,
> if that also would avoid the need to admit (even to
> themselves) that for many years their advice in this
> area has been exactly wrong.
You have no practical way of verifying the authenticity of a message.
You simply say "check if the message is not random looking", that's
not a practical (and not a safe) way of verifying that a message was
not modified in transit. A MAC is a practical and a safe way to
do that.
--Anton
- Next message: Henrick Hellström: "Re: Is there any weakness in adding static/known data (salt) to the password hash"
- Previous message: Nicol So: "Re: Surviving Einstein."
- In reply to: Terry Ritter: "Re: CBC questions"
- Next in thread: John E. Hadstate: "Re: CBC questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
