[cap-talk] solve CSRF by making references unforgeable, not unshareable
Sam Mason
sam at samason.me.uk
Thu Apr 2 11:02:02 EDT 2009
On Wed, Apr 01, 2009 at 04:08:09PM -0700, Bill Frantz wrote:
> sam at samason.me.uk (Sam Mason) on Wednesday, April 1, 2009 wrote:
> >Yes, but surely that's why it's the "asymptotic complexity" and not
> >worst case analysis.
>
> All of the hash tables I have used have been designed to have more than one
> entry/chain head. These tables are designed to incur an O(n) cost. Is there
> an example of a real-world O(1) hash table? It would have to have a
> guarantee that no chain was more than one element long. (And with that
> guarantee, the link field in the elements could be eliminated.)
Garg; not sure what I was thinking. As David said I should have said
"average case" and not "asymptotic" complexity. I have a feeling I've
always had the two being synonymous, not sure where I've picked that up
from!
> >how do you decide a new object's index? It sounds as though
> >you've just traded an O(1) insert, lookup and delete algorithm (the hash
> >table) for one with O(1) lookup (and maybe delete) and worse performance
> >for insert (and probably delete). Also I can't see how you'd stop your
> >array from growing indefinitely.
>
> The entries for deleted entries are linked together into a free list. When
> I need a new entry, I check the free list. If there is an entry on the free
> list, I remove if from the free list and reuse it, incrementing the
> allocation count. If there is no entry on the free list, I grow the array.
Yes, some sort of linked list is very obvious. I think my head was
broken last night.
> My array is only as large as the maximum number of remotely accessible
> objects that have ever existed. Keeping the array from growing indefinitely
> is why the allocation count is included in the design.
Wouldn't it be as large as the highest currently allocated client's
index, or is my head still broken?
> If the free list is kept LIFO, adding and removing entries is O(1). LIFO is
> also good for cache performance, including CPU caches, dynamic paging, and
> disk block caching.
Yes, all nice as well.
--
Sam http://samason.me.uk/
More information about the cap-talk
mailing list