Re: [Cfrg] CFRG and thwarting pervasive montoring

[Watson Ladd <[e-mail]>]

On Sun, Dec 29, 2013 at 4:26 PM, Stephen Farrell
<[e-mail]> wrote:
>
>
> On 12/29/2013 09:12 PM, Paul Hoffman wrote:
>> On Dec 29, 2013, at 11:12 AM, Stephen Farrell
>> <[e-mail]> wrote:
>>
>>> . . .
>>
>>> I would love to see ongoing detailed work within CFRG as to how to
>>> counter pervasive monitoring.
>>
>> Wearing your perpass hat, how can CFRG help? I ask this because I
>> have seen little on the perpass mailing list that indicated that an
>> even minor problem has been lack of crypto, or the use of crypto that
>> is thought to be breakable. What type of crypto research or
>> assessment would help perpass?

Sending to perpass to get feedback on this question.

>>
>> Note that deprecating the use of crypto that is widely known to be
>> broken is the purview of IETF WGs, not the CFRG. The relevant WGs
>> (particularly TLS) seem to already be doing that.

I don't agree with this assessment: the BCP Yaron Sheffer wrote on
depreciating RC4 got kicked
to the newly formed UTA WG, which has done nothing with it. The
biggest changes here have
been AGL pushing stuff into Chrome, but he can't do the server side
nearly as easily. It's been
a controversial topic in the TLS WG, even with Marsh Ray and AGL pushing for it.

>
> One question might be whether some modes of operation are
> really inherently more likely to have side-channels in their
> implementation or not and whether the impact of that might
> be practically usable by an attacker.

That assumes crypto is being used, and can hide the relevant information.
DNS is still in cleartext, and even HTTPS reveals what sites you are looking at.
The only fixes are PIR protocols, onion routing, and related tricks. We can also
try to reduce what is revealed: version numbers, configurations, and options can
be quite interesting for targeting, particularly if they are linkable
across sessions.

Side-channels are fixable with good, freely usable implementations: I
don't understand
why we are concerned with bad implementers. (Of course, the standard
needs to allow
a good side channel free implementation.) The lazy would rather copy
than innovate incorrectly.

Anyway, AES-GCM has side channel issues, but with HMAC+Salsa20/Chacha
or Chacha/Poly1305
it is easier to avoid them with as they have efficient circuits which
CPUs can do.

>
> Another might relate to whether things like nonces might
> provide a way for borked implementations to leak key bits
> and if so, whether there are practical ways for susceptible
> protocols to mitigate that, or bits of advice that should
> be included in such protocol specs. (And finding some
> susceptible protocols would be cool too if CFRG folks were
> willing.)

As in leak a key via the bits of an IV? That's not borked but
deliberate. For signing quite a few covert channels are known in
ECDSA. This is rumored to be an issue in the Test Ban Treaty negotiations,
but good luck finding out about that!

The easy countermeasure for some algorithms is to use nonces that are
implicit, incrementing with message number. That way
each peer enforces the algorithm on the other. Robert Ransom deserves
credit for this recognition AFAIK,
but I am sure this has been done before.

>
> I'm sure clever folk can come up with more once they start
> to think about it.
>
> S.
>
>
>>
>> --Paul Hoffman
>>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin