But you've spent an awful lot of time since trying to convince anyone who will listen that it isn't a security issue,
Hm. Seems to me you've expended a lot of time attacking my opinion.
All I've done is spend a little downtime politely and respectfully responded to your inflammatory comments.
you've been shown repeatedly that the assumptions you based this conclusion on were erroneous
No. Far from it. You've described a toy process that can brute force a conclusion when fed with a relatively large number of unrealistically short keys.
What you patently failed to demonstrate is how that knowledge can be used to do anything bad.
Yes, you can use knowledge of the seed to construct a set of keys that could induce pathological behaviour if used to construct a hash, but you simply omitted to address the problem of how are you going to persuade the server to construct a hash from the set keys you've generated.
As I said, a purely theoretical problem that has never and will never be demonstrated in the wild; addressed in a clumsy and over-engineered fashion.
But that just my opinion; it won't change a thing and seems hardly worthy of you're esteemed time to argue with; but here we are 11 levels deep.
In reply to Re^11: Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why?
by BrowserUk
in thread Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |