<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div><div><br></div><div>Your approach eliminates the need to mask the intro-cert lookup via PIR or dummy traffic.  But it lowers the security of your long-term key from ~128 bits to ~80 bits, and reduces "forward-secrecy of linkages", since compromise of the long-term ECDH key (which you've printed on your business card, so you're not going to rotate it frequently) allows going through published rendezvous messages and linking correspondents for the key's lifetime.</div>

</div></div></div></div></blockquote><div><br></div><div>Something I think was missed when Trevor initially proposed the intro-cert lookup process: we shouldn't assume the only use case is that Alice/Bob meet, and later on there are time-correlated lookups for Alice and Bob's intro-certs. It seems reasonably common that a group of people get together and have a small key-exchange party. I'm assuming nobody wants to support some group exchange protocol and we'd prefer pairwise exchanges, but this means If N people get together, and then they all lookup a very similar set of N-1 intro-certs promptly thereafter, this is going to be hard-to-impossible to mask by timing noise and dummy traffic. I suspect that if unlinkability is a goal then this approach requires PIR.</div>

<div> <br></div></div></div></div>