# Tag Info

0

Try the Yarrow suite of Algorithms by Bruce Schneier

1

The most secure CSPRNG would be one which produces a stream indistinguishable from random data without knowledge of the key, and which takes a key large enough that an exhaustive search of the key space is impossible. It turns out that there are many such CSPRNGs, so there's more than one answer: ChaCha and Salsa20 are 256-bit stream ciphers which can ...

9

Some time ago (more than 5 years, I think) in a local forum one guy gave a "cryptographic challenge" to the community. He gave an encrypted string and a small piece of code that produced it. The goal was to find what the encrypted string was. The encryption key was based on System.Random(), which is the spot where it could be attacked. At the time my work ...

45

You asked for the practical impact, so the answer is that for \$120 I could probably have your entire password database done by tomorrow. Here is your program, or something similar to it: using System; using System.Text; using System.Security.Cryptography; class Program { static void Main(string[] args) { byte[] pwd = new byte[128]; ... 7 The practical impact is that if the attacker can determine the time when the password was created, they can feed that time as a seed to System.Random, and will get exactly the same password. System.Random uses a time value with a precision of 1 second. Assuming password creation time is known down to a second (like a user registration date/time from a ... 6 To aid the intuition, please consider my new password generation scheme "seems trustworthy until people inspect details" or "stupid." The way that stupid works is you throw a die and pick a password. If you throw 1, your password is "dhjousacbjlfswsgolFHfhjQPC." If you throw 2 it is "vmcseykogcsKcsNTLhczdg." And so on. Those look like pretty good passwords ... 19 The official documentation for System.Random explicitly says it should not be used for generating passwords. It’s predictable, and seeded only from the system clock. This means System.Random has at most 20 bits of entropy to anyone who has a clock accurate to within a second. Indeed, try creating two new instances in quick succession on different threads; ... 27 From what you have described, it sounds like your system works as follows: Consult the system clock to find a 32-bit seed$s$. Use System.Random to generate a passphrase$p = G(s)$. (Here$G$is shorthand for whatever computation happens inside System.Random.) Hash the passphrase with PBKDF(2?) into output$x = H(p, \sigma)$, where$\sigma$is a salt known ... 3 If someone chooses to run your program with a seed that you can't predict but an adversary can, you won't be able to tell. There is no way around this: nothing about the software can tell you what an adversary does or doesn't know; you can only use cryptography to ensure that if an adversary doesn't know a key and the message, then they can't decrypt the ... 3 How often should I replace the key? The SUPERCOP implementation replaces the 32-byte key every 768 bytes. It's a latency/throughput tradeoff. Generating a longer batch of output raises the maximum latency of any query to the PRNG but also increases the throughput by using proportionally more CPU cycles for generating data and fewer for generating ... 2 I'd guess that you can simply split this into two problems: create 64 - n random bits, call this R shuffle n bits where m bits (at any location) are set to 1, call this P Finally you can simply perform R | P (presuming big endian notation). Shuffling lists of elements is an operation present in almost any language. If there is any inefficiency it would be ... 1 The problem for choosing$k$bits from$64$ultimately comes down to computing a uniformly random integer$r$with$0 \leq r < \frac{64!}{k!(64-k)!}$then decoding it to determine which bits. The$k!$in the denominator is annoying, but we can ignore it, because we can just allow our algorithm to have$k!\$ random numbers that map to the same output (...

Top 50 recent answers are included