On Sun, Dec 29, 2013 at 4:26 PM, Stephen Farrell <[email protected]> wrote: > > > On 12/29/2013 09:12 PM, Paul Hoffman wrote: >> On Dec 29, 2013, at 11:12 AM, Stephen Farrell >> <[email protected]> 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 > [email protected] > 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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
