You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this is by design then it is a serious vulnerability, because the entropy used compromises a fixed part of the final random pattern. This means that it is reducing the overall "randomness" of the generated keys thereby weakening it.
If the user supplies entropy then 1/3rd of the key is compromised, thus you're losing randomness guarantees by allowing entropy to be supplied there as a sort of seed value which in fact does nothing useful for the user since only a state actor with massive resources could pre-image the rest of the key.
Furthermore it breaks expectations since if I am already supplying entropy then the logical conclusion is that same entropy should yield same account, every time. This is not happening because we concat a randomly generated 32 bytes on 2 separate occasions. That would allow for an additional attack vector since if the random function is overridden by an attacker, for example an XSS, the whole system could be compromised.
It needs to be either one or the other. Either the create with entropy function provides a consistent result without trying to toss in randomly generated values from another source, or it completely disregards the entropy in favor of injecting it's own randomly generated values, in which case one has to ask, "what's the point of this function?"
Thanks!
The text was updated successfully, but these errors were encountered:
It looks like https://github.com/MaiaVictor/eth-lib/blob/master/src/account.js is injecting it's own random values despite supplied entropy.
If this is by design then it is a serious vulnerability, because the entropy used compromises a fixed part of the final random pattern. This means that it is reducing the overall "randomness" of the generated keys thereby weakening it.
If the user supplies entropy then 1/3rd of the key is compromised, thus you're losing randomness guarantees by allowing entropy to be supplied there as a sort of seed value which in fact does nothing useful for the user since only a state actor with massive resources could pre-image the rest of the key.
Furthermore it breaks expectations since if I am already supplying entropy then the logical conclusion is that same entropy should yield same account, every time. This is not happening because we concat a randomly generated 32 bytes on 2 separate occasions. That would allow for an additional attack vector since if the random function is overridden by an attacker, for example an XSS, the whole system could be compromised.
It needs to be either one or the other. Either the create with entropy function provides a consistent result without trying to toss in randomly generated values from another source, or it completely disregards the entropy in favor of injecting it's own randomly generated values, in which case one has to ask, "what's the point of this function?"
Thanks!
The text was updated successfully, but these errors were encountered: