[Cryptography] Hiding parties identities

Christian Huitema huitema at huitema.net
Fri Oct 30 00:13:34 EDT 2015


On Wednesday, October 28, 2015 9:26 PM, Peter Gutmann wrote:
> Christian Huitema <huitema at huitema.net> writes:
> 
> >I am looking at the “Pre-shared key” specs in RFC 4279, and in particular
> >at the privacy issues inherent with pre-shared key. According to 4279, the
> >client sends to the server a “key identity” so the server understands which
> >shared key to use in the exchange. The problem of course is that by doing
> >so the client reveals its own identity in a clear text message.
> 
> It doesn't really reveal its identity (well, not unless it wants to), just
> some unique value identifying an account, like a 128-bit string.  So the
> most an observer could do is determine that the same entity as before
> connected, which could well be possible by other means like host system or
> traffic fingerprinting.

If the key is unique to the user, then the 128-bit string is a unique identifier. Given enough observed traffic, unique identifiers will be tied to the user's identity. For example, if the identifier is observed on traffic originating from the user's home, it can be tied to the user. If the same identifier is later observed from a Wi-Fi hot-spot, the user will be identified. Then, all traffic originating from that IP address at the hot spot can be tied to the user.

> ...
> Another consideration is that since browser vendors have so far resolutely
> refused to support TLS-PSK (because it's not certificates, so you can't
> have it), I'm not sure how many people it would actually affect.

PSK seems to be the authentication method of choice for Internet of Things. Also, it is one of the plausible options for Post-Quantum.

> >Do you know a better way?
> 
> It depends on what level of protection you want.  If it's not a concern
> (see above), then you're done.  If it's straight masking of the identity
> then using a 128-bit (or whatever) string is fine.  If you also need
> protection from an attacker being able to tell that whatever connected last
> week is the same thing that's connecting this week then that's a harder
> problem, but then again you're going to need to apply countermeasures up
> and
> down the stack to deal with fingerprinting issues.

Yes of course. There are many leaks, and we need to plug them all.

> So the question really is: What's your threat model?

RFC 7624 is a good start for that.

-- Christian Huitema





More information about the cryptography mailing list