Skip to content

Unnecessary ruling out of zero in (CS)PRNG #107

@scrovy

Description

@scrovy

Thanks for your implementation. Since this is audited, I'm using it as a basis for a (simplified) Python implementation of my own. Nevertheless I don't understand one thing: why do you restrict the cryptographically secure pseudo-random number generator to spit out non-zero coefficients for the polynomials? This reduces the search space slightly by 1/2^bits for each coefficient (for large bits this is not an issue but it is for small bits (for bits=1 the algorithm would break down completely since the coefficients would always be equal to 1, but fortunately you only allow bits>=3)).

secrets.js/secrets.js

Lines 228 to 231 in 14a4b68

// return null so this result can be re-processed if the result is all 0's.
if ((str.match(/0/g) || []).length === str.length) {
return null
}

Here, the construct function returns null on all-zeros (i.e., the zero vector)

secrets.js/secrets.js

Lines 252 to 255 in 14a4b68

while (str === null) {
buf = crypto.randomBytes(bytes)
str = construct(bits, buf.toString("hex"), radix, size)
}

secrets.js/secrets.js

Lines 273 to 280 in 14a4b68

while (str === null) {
str = construct(
bits,
crypto.getRandomValues(new Uint32Array(elems)),
radix,
size
)
}

In these two, you keep generating new PRNG numbers until they are not the zero vector. For bits=3 this means that the only coefficients allowed are $1, 2, 3, \ldots, 7 \in GF(8)$, but not 0.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions