Tag Info

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

I will answer considering Linux OS, as being one of most popular Unix-like OS (between OSes which have urandom). If you need other OS, please, inform me.
Also I will answer using source code of random.c driver from Linux 3.3.3 Kernel, because it is one of best documentation of /dev/random mechanics. And the other is paper: Analysis of the Linux Random Number ...

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 ...

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 ...

You don't want to use something like the Mersenne Twister for gambling. It is not cryptographically secure.
Given a small amount of output, it is relatively straightforward to compute all future outputs. These algorithms are designed for things like Monte-Carlo simulations and things of that ilk.
A better option is to select a 128-bit key at random and ...

Yes, it is unsafe to seed a PRNG with only with the system time. No, that's not all Bouncy Castle's SecureRandom does.
The SecureRandom default constructor calls SetSeed(GetSeed(8)); which calls Master.GenerateSeed(length); which calls SetSeed(DateTime.Now.Ticks); which is misleading because SetSeed only adds seed material to an already existing prng (the ...

Even in context, much of what is written in the blog post makes no sense. E.g., it says:
While it can be argued that the DRNG is in reality just splitting a 128-bit value into two pieces and handing them to you one piece at a time, from a theoretical viewpoint this does not matter. While the original value had 128 bits of entropy, the end result is that ...

Evaluating a TRNG device positively requires knowing its structure, both to evaluate the actual amount of entropy it produces, and the possibility to detect a field failure.
Some devices sold as TRNG are in fact a TRNG subsystem followed by a PRNG, which produces the output of the device. In that case, if the PRNG is any good, the output of the device may ...

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 ...

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 ...

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, ...

No, that would not be a true RNG, because these physics engines would just repeat the exact same calculation and thus repeat the whole sequence of random numbers - like a PRNG. The starting conditions are the seed of this PRNG.
Dice are truly random in the real world. Well, are they? If we ignore quantum effects, we could measure all relevant values of the ...

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 ...

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 ...

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 ...

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 ...

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 ...

"PRNG" means "Pseudorandom Number Generator" which means that a sequence of numbers (bits, bytes...) is produced from an algorithm which looks random, but is in fact deterministic (the sequence is generated from some unknown internal state), hence pseudorandom.
Such pseudorandomness can be cryptographically secure, or not. It is cryptographically secure if ...

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 ...

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. ...

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 ...

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 ...

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 ...

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, ...