[messaging] channel-ID vs PAKE secrets

Trevor Perrin trevp at trevp.net
Wed Feb 19 10:43:08 PST 2014

On Tue, Feb 18, 2014 at 5:06 PM, Brian Warner <warner at lothar.com> wrote:
> On 2/18/14 3:30 PM, Trevor Perrin wrote:
>> But for an online rendezvous, the meeting ID (derived from the shared
>> secret) is the weak point:  An attacker can try to guess the shared
>> secret by making a large number of online queries for the meeting ID,
>> and the rendezvous server can try to crack the meeting ID with offline
>> search.
>> You earlier suggested that users could agree on separate meeting IDs
>> and shared secrets.  But I'm not sure that gains anything.  (Ex: if
>> users can agree on 60 shared secret bits, splitting that into a 30-bit
>> meeting ID and 30-bit shared secret weakens resistance against the
>> offline attack to 30 bits).
> Oh, I probably didn't explain myself well: the users must specifically
> agree on two *independent* secrets.
> But if the secrets are properly independent, then an attacker who wins
> the 30-bit online attack against the channel-ID merely earns the right
> to make the one (and only) guess at the 30-bit PAKE secret.

Good point, I agree that having separate secrets makes PAKE meaningful
here, since it's no longer undermined by the Meeting ID.

But the tradeoffs are complicated:

Choosing two 30 bit secrets instead of one 60 bit means:
 (a) Easier for rendezvous server to do offline search and discover
the Meeting ID secret.  If that secret is something like
"AliceAndBob123" which links one or both users then this is a problem.
 (b) Easier for online attacker to search 2^30 Meeting IDs, thus
discovering the Meeting ID secret and disrupting the rendezvous.
 + Instead of revealing the PAKE secret, these just give the attacker
"one shot" at hijacking the connection with 2^-30 probability.

If the total entropy is large enough to resist offline search (eg 80
bits plus key stretching), then splitting it doesn't help and could
make (a) a problem.  If the total entropy is small enough that
splitting it makes (b) easy (eg 30 bits), then that's also probably a
bad idea.

There's probably a sweet spot in-between where separate secrets is a
good idea.  But I'm not sure exactly how big it is, or if we could get
users to reliably hit it.  Hmm.


More information about the Messaging mailing list