<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 29, 2014 at 9:25 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Oh I see, with serial numbers the server could at a minimum also track<br>
them with a blacklist, which would be smaller than a blacklist of MACs<br>
due to birthday bound (though I'd expect closer to a 2x difference<br>
than 5x). ┬áThat makes sense, seems like a good optimization.</blockquote><div><br></div><div>Yeah I see now you could push the MAC size (L) down quite a bit from normal cryptographic use. You could actually beat the birthday bound since they're all generated at once, you could just throw out any tokens you generate that collide. That would require more work during generation but you could probably get away with 30 bit MACs or so. The adversary would have a 2^-30 chance of forging a MAC, but if that just lets them send one spam mail seems like no big deal.</div>

<div><br>Serial numbers are still more efficient throughout and would still offer nice 10x savings if you need to switch to a bitmap.</div></div><br></div></div>