Return to Answer

For a CSPRNG I would say the fact that it can repeat blocks is a good thing; predicting that a pattern cannot repeat is problematic. The only reason why it is usually acceptable is that the chance of repetition of larger blocks is negligible anyway.

Say that you'd use a CSPRNG to create a set of 128 bit blocks, the block size of AES. A million is about $2^{20}$. you would expect a chance of $1 - (1 - {1 \over 2^{128}})^{1000000} \approx 2^{-108}$ for a the initial block to be repeated, and ${1000000 \over 2^{128}} \approx 2^{-(128 - 20)} = 2^{-108}$ for any collision in the first million blocks to occur. The reason why these values are about the same is that a million is next to nothing for 128 bit values. As you can see, the likelihood of a collision is so low that it can be seen as negligible. This is why a stream cipher such as AES-CTR can be thought of as a CSPRNG itself.

Generally CSPRNG's have a large internal state, which means that it is impossible to know when the PRNG repeats. More importantly, the chance that they hit a cycle is extremely low (if a cycle is hit then the CSPRNG would generate the same - large - pattern in repetition). So because of the unpredictability you can use a CSPRNG as stream cipher. This is true for AES / CTR as well of course, if you look at patterns other than 128 bits at precisely the right location. Obviously a pattern of a single bit will repeat extremely often - it's just that you cannot know which bit value you'll find at a given position. The problem with AES-CTR is that it will hit a cycle precisely after the counter has been depleted.

However, because many CSPRNG implementations have not been designed to generate the same deterministic stream, you should be extremely careful of using one as a stream cipher. For instance, they may reseed, use the given seed as additional entropy, generate different output when methods are called differently or even have the algorithm revised. If you are unlucky you will never be able to regenerate the same key stream and your data would be lost (see e.g. getRawKey() on Android devices).

Of course, AES-CTR will generally be a lot faster than a CSPRNG as well. If you don't like AES or don't have hardware acceleration then a stream cipher such as ChaCha would normally be the way to go. Usually you would use these ciphers in an authenticated mode using GMAC (AES-GCM) or Poly1305.

In cryptographic literature you'll often find that stream ciphers and CSPRNG's are used interchangeably, but beware of the practical differences in the last two sections.

For a CSPRNG I would say the fact that it can repeat blocks is a good thing; predicting that a pattern cannot repeat is problematic. The only reason why it is usually acceptable is that the chance of repetition of larger blocks is negligible anyway.

Say that you'd use a CSPRNG to create a set of 128 bit blocks, the block size of AES. A million is about $2^{20}$. you would expect a chance of $1 - (1 - {1 \over 2^{128}})^{1000000} \approx 2^{-108}$ for a the initial block to be repeated, and ${1000000 \over 2^{128}} \approx 2^{-(128 - 20)} = 2^{-108}$ for any collision in the first million blocks to occur. The reason why these values are about the same is that a million is next to nothing for 128 bit values. As you can see, the likelihood of a collision is so low that it can be seen as negligible. This is why a stream cipher such as AES-CTR can be thought of as a CSPRNG itself.

Generally CSPRNG's have a large internal state, which means that it is impossible to know when the PRNG repeats. More importantly, the chance that they hit a cycle is extremely low (if a cycle is hit then the CSPRNG would generate the same - large - pattern in repetition). So because of the unpredictability you can use a CSPRNG as stream cipher. This is true for AES / CTR as well of course, if you look at patterns other than 128 bits at precisely the right location. Obviously a pattern of a single bit will repeat extremely often - it's just that you cannot know which bit value you'll find at a given position. The problem with AES-CTR is that it will hit a cycle precisely after the counter has been depleted.

However, because many CSPRNG implementations have not been designed to generate the same deterministic stream, you should be extremely careful of using one as a stream cipher. For instance, they may reseed, use the given seed as additional entropy, generate different output when methods are called differently or even have the algorithm revised. If you are unlucky you will never be able to regenerate the same key stream and your data would be lost (see e.g. getRawKey() on Android devices).

Of course, AES-CTR will generally be a lot faster than a CSPRNG as well. If you don't like AES or don't have hardware acceleration then a stream cipher such as ChaCha would normally be the way to go. Usually you would use these ciphers in an authenticated mode using GMAC (AES-GCM) or Poly1305.

In cryptographic literature you'll often find that the terms "stream cipher" and "CSPRNG" are used interchangeably, but beware of the practical differences in the last two sections.

For a CSPRNG I would say the fact that it can repeat blocks is a good thing; predicting that a pattern cannot repeat is problematic. The only reason why it is usually acceptable is that the chance of repetition of larger blocks is negligible anyway.

Say that you'd use a CSPRNG to create a set of 128 bit blocks, the block size of AES. A million is about $2^{20}$. you would expect a chance of approx $1 - (1 - {1 \over 2^{128}})^{20} \approx 2^{-123}$ for a the initial block to be repeated, and approx ${2^{20} \over 2^{128}} = 2^{-(128 - 20)} = 2^{-108}$ for any collision in the first million blocks to occur. As you can see, the likelihood of a collision is so low that it can be seen as negligible. This is why a stream cipher such as AES-CTR can be thought of as a CSPRNG itself.

Generally CSPRNG's have a large internal state, which means that it is impossible to know when the PRNG repeats. More importantly, the chance that they hit a cycle is extremely low (if a cycle is hit then the CSPRNG would generate the same - large - pattern in repetition). So because of the unpredictability you can use a CSPRNG as stream cipher. This is true for AES / CTR as well of course, if you look at patterns other than 128 bits at precisely the right location. Obviously a pattern of a single bit will repeat extremely often - it's just that you cannot know which bit value you'll find at a given position. The problem with AES-CTR is that it will hit a cycle precisely after the counter has been depleted.

However, because many CSPRNG implementations have not been designed to generate the same deterministic stream, you should be extremely careful of using one as a stream cipher. For instance, they may reseed, use the given seed as additional entropy, generate different output when methods are called differently or even have the algorithm revised. If you are unlucky you will never be able to regenerate the same key stream and your data would be lost (see e.g. getRawKey() on Android devices).

Of course, AES-CTR will generally be a lot faster than a CSPRNG as well. If you don't like AES or don't have hardware acceleration then a stream cipher such as ChaCha would normally be the way to go. Usually you would use these ciphers in an authenticated mode using GMAC (AES-GCM) or Poly1305.

In cryptographic literature you'll often find that stream ciphers and CSPRNG's are used interchangeably, but beware of the practical differences in the last two sections.

For a CSPRNG I would say the fact that it can repeat blocks is a good thing; predicting that a pattern cannot repeat is problematic. The only reason why it is usually acceptable is that the chance of repetition of larger blocks is negligible anyway.

Say that you'd use a CSPRNG to create a set of 128 bit blocks, the block size of AES. A million is about $2^{20}$. you would expect a chance of $1 - (1 - {1 \over 2^{128}})^{1000000} \approx 2^{-108}$ for a the initial block to be repeated, and ${1000000 \over 2^{128}} \approx 2^{-(128 - 20)} = 2^{-108}$ for any collision in the first million blocks to occur. The reason why these values are about the same is that a million is next to nothing for 128 bit values. As you can see, the likelihood of a collision is so low that it can be seen as negligible. This is why a stream cipher such as AES-CTR can be thought of as a CSPRNG itself.

Generally CSPRNG's have a large internal state, which means that it is impossible to know when the PRNG repeats. More importantly, the chance that they hit a cycle is extremely low (if a cycle is hit then the CSPRNG would generate the same - large - pattern in repetition). So because of the unpredictability you can use a CSPRNG as stream cipher. This is true for AES / CTR as well of course, if you look at patterns other than 128 bits at precisely the right location. Obviously a pattern of a single bit will repeat extremely often - it's just that you cannot know which bit value you'll find at a given position. The problem with AES-CTR is that it will hit a cycle precisely after the counter has been depleted.

However, because many CSPRNG implementations have not been designed to generate the same deterministic stream, you should be extremely careful of using one as a stream cipher. For instance, they may reseed, use the given seed as additional entropy, generate different output when methods are called differently or even have the algorithm revised. If you are unlucky you will never be able to regenerate the same key stream and your data would be lost (see e.g. getRawKey() on Android devices).

Of course, AES-CTR will generally be a lot faster than a CSPRNG as well. If you don't like AES or don't have hardware acceleration then a stream cipher such as ChaCha would normally be the way to go. Usually you would use these ciphers in an authenticated mode using GMAC (AES-GCM) or Poly1305.

In cryptographic literature you'll often find that stream ciphers and CSPRNG's are used interchangeably, but beware of the practical differences in the last two sections.

For a CSPRNG I would say the fact that it can repeat blocks is a good thing; predicting that a pattern cannot repeat is problematic. The only reason why it is often acceptable is that the chance of repetition of larger blocks is negligible anyway.

Say that you'd use a CSPRNG to create a set of 128 bit blocks, the block size of AES. A million is about $2^{20}$. you would expect a chance of approx $1 - (1 - {1 \over 2^{128}})^{20} \approx 2^{-123}$ for a the initial block to be repeated, and approx ${2^{20} \over 2^{128}} = 2^{-(128 - 20)} = 2^{-108}$ for any collision in the first million blocks to occur. As you can see, the likelihood of a collision is so low that it can be seen as negligible. This is why a stream cipher such as AES-CTR can be thought of as a CSPRNG itself.

Generally CSPRNG's have a large internal state, which means that it is impossible to know when the PRNG repeats. More importantly, the chance that they hit a cycle is extremely low (if a cycle is hit then the CSPRNG would generate the same - large - pattern in repetition). So because of the unpredictability you can use a CSPRNG as stream cipher. This is true for AES / CTR as well of course, if you look at patterns other than 128 bits at precisely the right location. Obviously a pattern of a single bit will repeat extremely often - it's just that you cannot know which bit value you'll find at a given position. The problem with AES-CTR is that it will hit a cycle after the counter has been depleted.

However, because many CSPRNG implementations have not been designed to generate the same deterministic stream, you should be extremely careful of using one as a stream cipher. For instance, they may reseed, use the given seed as additional entropy, generate different output when methods are called differently or even have the algorithm revised. If you are unlucky you will never be able to regenerate the same key stream and your data would be lost (see e.g. getRawKey() on Android devices).

Of course, AES-CTR will generally be a lot faster than a CSPRNG as well. If you don't like AES or don't have hardware acceleration then a stream cipher such as ChaCha would normally be the way to go. Usually you would use these ciphers in an authenticated mode using GMAC (AES-GCM) or Poly1305.

In cryptographic literature you'll often find that stream ciphers and CSPRNG's are used interchangeably, but beware of the practical differences in the last two sections.

For a CSPRNG I would say the fact that it can repeat blocks is a good thing; predicting that a pattern cannot repeat is problematic. The only reason why it is usually acceptable is that the chance of repetition of larger blocks is negligible anyway.

Say that you'd use a CSPRNG to create a set of 128 bit blocks, the block size of AES. A million is about $2^{20}$. you would expect a chance of approx $1 - (1 - {1 \over 2^{128}})^{20} \approx 2^{-123}$ for a the initial block to be repeated, and approx ${2^{20} \over 2^{128}} = 2^{-(128 - 20)} = 2^{-108}$ for any collision in the first million blocks to occur. As you can see, the likelihood of a collision is so low that it can be seen as negligible. This is why a stream cipher such as AES-CTR can be thought of as a CSPRNG itself.

Generally CSPRNG's have a large internal state, which means that it is impossible to know when the PRNG repeats. More importantly, the chance that they hit a cycle is extremely low (if a cycle is hit then the CSPRNG would generate the same - large - pattern in repetition). So because of the unpredictability you can use a CSPRNG as stream cipher. This is true for AES / CTR as well of course, if you look at patterns other than 128 bits at precisely the right location. Obviously a pattern of a single bit will repeat extremely often - it's just that you cannot know which bit value you'll find at a given position. The problem with AES-CTR is that it will hit a cycle precisely after the counter has been depleted.

However, because many CSPRNG implementations have not been designed to generate the same deterministic stream, you should be extremely careful of using one as a stream cipher. For instance, they may reseed, use the given seed as additional entropy, generate different output when methods are called differently or even have the algorithm revised. If you are unlucky you will never be able to regenerate the same key stream and your data would be lost (see e.g. getRawKey() on Android devices).

Of course, AES-CTR will generally be a lot faster than a CSPRNG as well. If you don't like AES or don't have hardware acceleration then a stream cipher such as ChaCha would normally be the way to go. Usually you would use these ciphers in an authenticated mode using GMAC (AES-GCM) or Poly1305.

In cryptographic literature you'll often find that stream ciphers and CSPRNG's are used interchangeably, but beware of the practical differences in the last two sections.