Re: [tor-dev] Even more notes on relay-crypto constructions

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Thu, Oct 18, 2012 at 6:10 PM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
 [...]
>> There are modes that are supposed to prevent this, and applying them
>> to a decent wide-block cipher might solve the issue. IGE is one of
>> them [IGE], but it turns out to be broken by an attacker who knows
>> some plaintext.  The Accumulated Block Chaining [ABC] construction is
>> supposed to fix that; I'm not too sure whether it's correct or
>> efficient.
>
> Am I crazy to think we might try to stop the bleeding of tagging attacks
> by figuring out a way to use ABC or IGE mode as a stopgap until people
> can code and evaluate new constructions for performance and timing
> side-channels? ABC/IGE would "only" involve a mode change, rather than
> an entire relay protocol upgrade and new cipher coding..

ABC or IGE wouldn't help us much on their own without a wide-block
cipher, and IGE is just plain broken. (See explanation below.)

Remember, in the document I originally sent, I was talking about using
ABC or some other corruption-propagation mode at a block level.  That
requires a wide-block cipher, though.  And it turns out we can do
better if the corruption-propagation is part of the wide-block idea.

We'd also burn our performance on platforms without AES acceleration, I think.

> IGE might also actually exist in OpenSSL:
> http://www.links.org/?p=137
>
> It also sounds like IGE is only broken if we try to use it for
> authentication.. We don't really need that property, do we? What we
> really want is the plaintext corruption property at the middle node upon
> ciphertext modification..

That _is_ a kind of authentication, or an analogue to it.  And the
point is that an adversary can repair a hole in the stream, and *stop*
the plaintext corruption.  So IGE does not deliver the property we
would want for it, even if we could use it.

Check out this thread, and the stuff it references:
   http://www.mail-archive.com/cryptography@xxxxxxxxxxxx/msg06599.html

> We could also remove a lot of known plaintext by replacing zero-fill
> with random fill in RELAY_RESOLVE, RELAY_BEGIN, and other short relay
> cells. That should only be expensive at the client...

So long as there is a block's worth of known or guessed plaintext, IGE
fails to ensure that changes propagate forward.  Like, 16 bytes worth
of guessable HTTP in a payload (if you're thinking about this in a
non-wide-block scenario).

Two general process thoughts:

* I may be saying this from an overabundance of caution, but: I don't
think we should use cryptographic primitives and constructions with
known flaws, even if we can't see a way for them to hurt us right now,
and even if we can come up with a solid-seeming argument for how those
flaws can't hurt us..  That's how we got into our AES-CTR mess in the
first place.

* I know everybody wants our crypto problems to get solved, but it's
critical to get this stuff right.  I think that the way to do right by
our users is by taking the time we will need to design the right thing
properly, rather than jumping into something halfcocked.  We all
acknowledge that it's easy for people and organizations to screw this
stuff up: so let's take our time and actually come up with something
solid.  Against the current pain and badness of our current system, we
must weigh the potential harm of jumping precipitously into something
that turns out to be broken because we didn't think about it hard
enough.

And a more general observation:

* I think the only thing we could get designed & analyzed enough to
include in Tor 0.2.4 would be hmac-and-pad, which nobody actually
likes much.  I think that by the time we get anything good here well
designed and discussed enough to reach a sensible consensus about it,
it will be 2013, and time to start adding features to 0.2.5 (at the
earliest).


So here's to getting it right!


yrs,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev