# Tag Info

## Hot answers tagged random-number-generator

88

The main difficulty with the one-time pad is that it requires pre-arrangement. In order for me to use a one-time pad to communicate with you, we must either have arranged ahead of time for a one-time pad that we will use (which must be as large as our communication will be), or else we must have some secure way of communicating that will allow us to agree on ...

38

For symmetric encryption algorithms, your question is basically "Why do we use AES or DES rather than another function that provides the same properties as AES or DES but forces us to use the second weakest chaining mode and never lets us use the same key twice?" Well, the answer is obvious, we sometimes want strong chaining modes and we often like to use ...

32

There is a theorem in cryptography that states that secure encryption and secure PRNG are equivalent, and in fact you just proved half of it. Given a secure PRNG, you can create a secure encryption algorithm using the method you just provided (using the key as the PRNG-seed). The other half is that given a secure encryption algorithm, you can create a ...

25

I wouldn't try to explain the mathematics of the backdoor. Just explain that the NSA hid a secret backdoor in there. Instead, I would suggest focusing on the history and the context. For instance, you could explain about Crypto.AG, how they spiked their RNG to help the NSA spy on their customers. You could explain how random number generators are a ...

17

Blum-Blum-Shub is a stream cipher: given a short key, it produces an effectively unlimited-length stream of pseudorandom bits. Other well-known examples of stream ciphers include AES-CTR and RC4. Blum-Blum-Shub gets mentioned a lot by non-expert cryptographers. I suspect this is because it comes with a "proof" of security, which sounds like a wonderful ...

16

Here is a list of products and companies who have had their EC DRBG algorithm validated by NIST. http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html The validation lists all modes that have been validated, so you can see which ones have gone to the effort of having their implementation of Dual_EC_DRBG validated. Tim Dierks points out that, for ...

14

Frankly, I'd be surprised if anyone did use it. Even before the potential backdoor was discovered back in 2007, the Dual_EC_DRBG was known to be much slower and slightly more biased than all the other random number generators in NIST SP 800-90. To quote Bruce Schneier: "If this story leaves you confused, join the club. I don't understand why the NSA ...

12

There is a very easy reason why one-time pads are not always used. It requires information sent before the encryption is set up, i.e. both the sender and the recipient need to have access to the pads themselves. That's a big pain, especially if all information was to be sent with one time pads. How would one distribute the pads themselves? There is also a ...

12

Checking statistical randomness is a semi-good test. What I mean by that is that if a given PRNG does not look good statistically, then it is utterly proven to be pure junk. On the other hand, good statistical randomness does not tell you much with regards to cryptographic security. Cryptographic security is about whether the PRNG output could be predicted ...

12

The answer you posted is actually correct (more or less, see below): have each participant commit to their random number $r_i$ by publishing, e.g., $\mathcal{H}(r_i)$ in the first round. And then in the second round, each participant opens the commitment by publishing $r_i$ and everyone checks that it matches the committed value by hashing it. The final ...

12

RSA BSAFE Libraries (Both for Java and C/C++) use it as their default PRNG. Java: http://developer-content.emc.com/docs/rsashare/share_for_java/1.1/dev_guide/group__LEARNJSSE__RANDOM__ALGORITHM.html C/C++: https://community.emc.com/servlet/JiveServlet/previewBody/4950-102-2-17171/Share-C_1.1_rel_notes.pdf This obviously impacts users of the library such ...

11

mpz_nextprime states in the documentation and source (file: mpz/nextprime.c) that it simply finds the next prime larger than the provided input. There are various methods of doing so (depending on how efficient it tries to be), but they should all produce the same answer. Looking at the code, mpz_nextprime first tests a number against a large quantity of ...

11

A simple way to imagine the effect of the hash function is a truncation. A "good" hash function ought to behave like a random oracle. If your source has entropy $s$ bits, then this means that the source somehow assumes $2^s$ possible values. When processed with a random oracle with an $n$-bit output, you force the $2^s$ input values into $2^n$ possible ...

10

If the people who generated the pre-paid card numbers did their job properly, then no, it is not possible to reconstruct these numbers. The simplest pre-paid card number generation system is to use purely random numbers, and store generated numbers in a database. To verify a generated number, simply look it up in the database. The function which can then ...

10

According to the paper On Lempel-Ziv Complexity of Sequences by Doganaksoy and Gologlu, A test based on Lempel-Ziv complexity was used in the NIST test suite, to test the randomness of sequences. However the test had some weaknesses. First of all, the test could only be applied to data of a specified length: $10^6$ bits. Moreover, the test used empirical ...

10

There are three general solutions to the non-duplicate random number problem: If you want a few numbers from a large range then pick one and reject it if it is a duplicate. If the range is large, then this won't cause too many repeated attempts. If you want a lot of numbers from a small range, then set out all the numbers in an array and shuffle the array. ...

10

It is so easy to create cryptographically-strong random numbers in ways that are known to be strong that adding new methods that add new risks is not advisable. However, if you have an existing method that is known to be secure and has the ability to take in additional sources of randomness in way that cannot do harm even if they are known to an attacker, ...

10

Distinguishing attack. How broken is it? It is broken. As fgrieu notes, the high bit is highly biased. In other words, the high bit is fairly predictable. This is enough to distinguish the output of this generator from a truly random bitstream. That means the stream cipher is broken: that's the definition of what it means for a stream cipher to be ...

9

It is possible to design a PRNG upon a hash function, but it requires some care, notably because existing hash functions are not random oracles (being collision-resistant and preimage-resistant is not all that can be dreamed of for a hash function). NIST Special Publication SP 800-90 describes some PRNG designs which are "Approved" (in the bureaucratic ...

9

Since the goal is to generate the salt for PBKDF2, there is no need for an efficient (as in fast) random generator: PBKDF2 is (purposely) compute-intensive. Further, in many uses of PBKDF2 (e.g. storing a password), the salt is generated once, stored, and reused many times, further lowering the concern over efficiency of the salt generation. As the saying ...

9

Well, the chief vulnerability is that if an attacker is given a large enough sample of Mersenne Twister output, he can then predict future (and past) outputs. This is a gross violation of the properties that a cryptographically secure random number generator is supposed to have (where you're supposed to not even be able to tell if the random bit string ...

9

I'm not familiar with the terminology "reduced state", so I can't address that half of the question. However, this particular PRNG makes it easy to reconstruct the internal state; we note that the state function can be rewritten as: x := 2*x + 5 - kx * p y := 3*y + 7 - ky * p for some small integers $k_x$, $k_x$ (in fact, $0 \le k_x \le 2$ and $0 \le k_y ... 9 Would it be useful for companies who need to keep their data safe? No, a one-time-pad is only useful in very rare circumstances. The main issue is key-management. You can only use each pad once, it's as large as the data you want to encrypt, and you need to get it to all parties in a secure way. The direct competition of a one-time-pad is a stream cipher. ... 9 First of all, there is a difference between writing to /dev/random and/or /dev/urandom and increasing the entropy count maintained in the Kernel. This is the reasony why, by default, /dev/random is world-writable - any input will only augment, but never replace the internal state of the RNG; if you write completely predictable data, you're doing no good, ... 9 We currently have no way to prove that a specific PRNG is cryptographically secure. In fact, we currently cannot prove that there exists a cryptographically secure PRNG (!). If you scale back the requirement from "mathematical proof" to "something we generally accept", there's still no way for an automated test to verify that a specific output is ... 8 A stream cipher, RSA, or whatever you designate by the expression "discrete logarithm system", are not "one-way functions". In particular, asymmetric encryption algorithms and digital signature algorithms provide functionality which is not doable (or not with the same usability) with only the "scrambling" techniques of symmetric cryptography. Let's not ... 8 Mersenne Twister (as an example) is a fast random number generator, and has good properties (long period, good distribution) for most applications of random numbers (like statistics, simulations, modelling). For cryptographic applications, we need more: We need a cryptographically secure random number generator. Such a function (implemented by an algorithm) ... 8 The perfect security of OTP hinges on the fact, that keys must be chosen truly at random and uniformly from the domain of all possible keys, i.e. all bitstrings of a certain length. The problem with your approach is that you use a pseudorandom number generator to generate the key. It does not matter how good the generator is, because the entropy that can be ... 8 No, it's not safe to seed a PRNG with the hash of a password, then generate a key from that PRNG. That is especially bad with DSA and shared parameters$(p,q,g)$, and only slightly less unsafe for RSA, or DSA with per-key parameters$(p,q,g)\$. Two essentials things are missing: some slow step, and salt. If the proposed procedure was applied, all there is to ...

8

It looks like there are really two potential problems. From the mailing list all private keys generated on Android phones/tablets are weak and some signatures have been observed to have colliding R values, allowing the private key to be solved and money to be stolen. Recall that with bitcoin Transactions are cryptographically signed records ...

Only top voted, non community-wiki answers of a minimum length are eligible