Reputation
26,574
Next tag badge:
419/400 score
79/80 answers
Badges
2 37 112
Newest
 Benefactor
Impact
~410k people reached

10h
awarded  Benefactor
14h
comment Why calculate pi to estimate randomness?
@Paul Uszak: Generating random numbers, and testing them, is fascinating; that's the state of mind at fourmilab's hotbits. Their generator seems to be a high-quality, physically-seeded TRNG, with multiple statistical tests at the lightly-conditioned output, which is fine. However their use of the π-by-Monte-Carlo test is more an extra, simple demo that the thing works, for added confidence that there's no horrible goof, than a test designed for real use in fielded cryptographic devices.
1d
revised Why calculate pi to estimate randomness?
link to FIPS 140-1 and other polish
1d
revised Why calculate pi to estimate randomness?
justify π/4
1d
awarded  Necromancer
2d
revised Why calculate pi to estimate randomness?
More links to jargon
2d
awarded  Revival
2d
revised Why calculate pi to estimate randomness?
Give example of purposely induced defect
2d
revised Why calculate pi to estimate randomness?
Add links to jargon
2d
revised Why calculate pi to estimate randomness?
polish
2d
answered Why calculate pi to estimate randomness?
2d
comment Library to find an addition chain for a large number?
A reference to some of the best solutions known to the problem of addition chains (without subtraction) is Daniel Bernstein's Pippenger's exponentiation algorithm
2d
awarded  Nice Question
2d
comment Permuting Small Sized Set in Practice
In this pseudocode, t = rand(0, i) must generate a random integer uniformly distributed among the i+1 integers in range [0,i] inclusive; otherwise the permutation is distinguishable from random, especially for small sets.
Jul
27
comment Permuting Small Sized Set in Practice
What's wrong with the Fisher–Yates shuffle, which is the archetypal way to randomly make a permutation of a set small enough that we can store the index of each element? Or/and (especially, for wider sets) enciphering the index using one of the many techniques of Format-Preserving Encryption and a fixed key?
Jul
24
comment Collision or second preimage for the ChaCha core?
If we could demonstrate that the ChaCha core is not a bijection (other than for 0 rounds, where that result is trivial), it would be something. I conjecture that's feasible for few rounds (like 2), but becomes infeasible for enough rounds to reach security (like 8 or more). The final addition destroys the argument of bijection, but lack of argument for a proposition does not prove that it does not hold (much less provide a counterexample).
Jul
24
comment Collision or second preimage for the ChaCha core?
Nitpick: the final addition in the core makes it not easily invertible. We know how to make public, easily computable functions over a 512-bit domain that are demonstrably bijective, but quite computationally hard to invert for arbitrary output (admittedly, building such function using only ARX operations requires a lot of these).
Jul
24
comment Collision or second preimage for the ChaCha core?
Summarizing the discussion: the theorem prover proved that 2 rounds of ChaCha can't collide; this is not directly related to the ChaCha core with 2 rounds colliding. $\;$ It did not answer on if the ChaCha core with 10x2 rounds collides. In fact, if an automated tool could prove or disprove that the ChaCha core with only 2 rounds has collisions, that would be even more an achievement than proving that for the Salsa20 core. $\;$ There are strong heuristic arguments that there are collisions for the ChaCha core using enough rounds for security, we just do not know any (for now).
Jul
24
revised Collision or second preimage for the ChaCha core?
Merge the two clarifications
Jul
24
revised Collision or second preimage for the ChaCha core?
clarification added