[Cryptography] Hiding parties identities

Peter Gutmann pgut001 at cs.auckland.ac.nz
Thu Oct 29 00:25:54 EDT 2015


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.

>This is dutifully flagged in the security considerations, but no mitigation 
>is proposed.

When the opportunity has arisen, I've asked users of PSK whether this is a 
concern to them.  So far none have indicated that it is.  

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.

>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.

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

Peter.


More information about the cryptography mailing list