Hi Marc,
Are Gambit's hash tables protected against double hash attacks?
E.g. by calculating a random number that's used as hash seed making it impossible for an attacker to produce key hash collissions, https://en.wikipedia.org/wiki/SipHash .
Adam
Afficher les réponses par date
No they are not. Doing this would make executions non-deterministic.
Marc
On Aug 8, 2018, at 4:13 AM, Adam adam.mlmb@gmail.com wrote:
Hi Marc,
Are Gambit's hash tables protected against double hash attacks?
E.g. by calculating a random number that's used as hash seed making it impossible for an attacker to produce key hash collissions, https://en.wikipedia.org/wiki/SipHash .
Adam
|table-ref| (hashtable access) speed being non-deterministic would be all fine as the average access speed should remain constant.
To preserve the possibility of fully deterministic behavior, maybe double hash attack protection by random seeding could be... on by default but can be disabled via a key argument, or, off by default and can be enabled via a key argument, something like this?
Adam
2018-08-08 12:49 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
No they are not. Doing this would make executions non-deterministic.
Marc
On Aug 8, 2018, at 4:13 AM, Adam adam.mlmb@gmail.com wrote:
Hi Marc,
Are Gambit's hash tables protected against double hash attacks?
E.g. by calculating a random number that's used as hash seed making it
impossible for an attacker to produce key hash collissions, https://en.wikipedia.org/wiki/SipHash .
Adam
Add a feature request issue for this. Non-determinism is bad for debugging. And I view “production runs” as debugging because when something goes wrong in production once in a blue moon you need to debug that particular run.
Marc
On Aug 8, 2018, at 8:00 AM, Adam adam.mlmb@gmail.com wrote:
|table-ref| (hashtable access) speed being non-deterministic would be all fine as the average access speed should remain constant.
To preserve the possibility of fully deterministic behavior, maybe double hash attack protection by random seeding could be... on by default but can be disabled via a key argument, or, off by default and can be enabled via a key argument, something like this?
Adam
2018-08-08 12:49 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca: No they are not. Doing this would make executions non-deterministic.
Marc
On Aug 8, 2018, at 4:13 AM, Adam adam.mlmb@gmail.com wrote:
Hi Marc,
Are Gambit's hash tables protected against double hash attacks?
E.g. by calculating a random number that's used as hash seed making it impossible for an attacker to produce key hash collissions, https://en.wikipedia.org/wiki/SipHash .
Adam
On Wed, Aug 8, 2018 at 2:33 AM Marc Feeley feeley@iro.umontreal.ca wrote:
Add a feature request issue for this. Non-determinism is bad for debugging. And I view “production runs” as debugging because when something goes wrong in production once in a blue moon you need to debug that particular run.
If Gambit were to salt its hashes, the salt(s) and/or the random seed used to compute the salt(s) ought to be setable by users early enough (if needs be on the command-line).
Adam: can the salt be per-table (or per-type) or does it have to be global? Can you do it in user-space?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Why is there only one Monopolies Commission? — Lord Sutch
2018-08-10 6:57 GMT+08:00 Faré fahree@gmail.com:
On Wed, Aug 8, 2018 at 2:33 AM Marc Feeley feeley@iro.umontreal.ca wrote:
Add a feature request issue for this. Non-determinism is bad for
debugging. And I view “production runs” as debugging because when something goes wrong in production once in a blue moon you need to debug that particular run.
If Gambit were to salt its hashes, the salt(s) and/or the random seed used to compute the salt(s) ought to be setable by users early enough (if needs be on the command-line).
Adam: can the salt be per-table (or per-type) or does it have to be global? Can you do it in user-space?
As I understand it, the salt can be both per table and global. There is no reason that the user would not be allowed to specify the salt per table. If random u8vector may not be super fast, then maybe just copy the default per-table salt from a global variable that's generated once at startup.
Having salt randomization on by default would follow a "secure by default" reasoning - someone could use a hashtable in an exploitable place, and not be aware of the DDOS implications hashtables can have.
Of course as a user you can add hash salting on top of Gambit's hashtables yourself, by cons:ing on a random constant to all your table keys, or by implementing your own hashing function and telling Gambit to use it.
(Some more thoughts,
I see the point about determinism of software execution, however isn't the only effect of the randomization that table operations will have slightly different execution times which mean nondeterminism, aren't there some other common sources of nondeterminism around such as variance in OS thread execution speed or IO speed, that could complicate debugging already and even more than hashtable behavior -
Anyhow an optional salt works too. Hashtable DDOS security is really not a normally notable threat, it just occurred to me to bring it up for completeness, that was all. Yep should add a feature request.)
-
Adam -
Faré -
Marc Feeley