Hot answers tagged stream-cipher
35
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 ...
30
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 password as the PRNG-seed). The other half is that given a secure encryption algorithm, you can create a ...
19
It's important to make the distinction between ciphers which use XOR
internally as a component operation (which is nearly all of them),
and 'ciphers' which just XOR the plaintext with a secret. If the key
is the same length as the plaintext, then it's a one time pad, so in
some sense, yes, with "sufficient randomness" you can safely encrypt with XOR.
The ...
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 ...
9
If the key used to XOR your plaintext is any shorter than your plaintext, then the repeats will give it away. If the key is truely random, and never reused, it is effectively a one-time-pad.
The historical name for XOR encryption is Vernam cipher.
is there something inherently wrong with XOR based ciphers
The amount of effort you need to put into ...
9
This approach, at a high level, is actually fairly common; many stream ciphers operate on this very principle. For instance, Salsa20 uses what is effectively a hash function (a PRF) to convert a secret input (that includes a counter) into the keystream which is XORed with the plaintext. However, this kind of function can be much faster than a secure ...
8
On software platforms, bytewise adding will not be faster than bitwise XORing. It may be a bit slower, though, also this will be negligible with regards to the process which generated the stream (and, for that matter, will probably also be negligible with regards to the memory bandwidth).
On hardware platforms (FPGA, dedicated ASIC), addition is slower than ...
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 ...
7
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 ...
7
With the corrected system (which actually uses the key), I see these weaknesses:
If the attacker can guess some plaintext_n, he can derive pad_n from ciphertext_n and from this all the following pad_i - which means that he can read the rest of the message.
The ciphertext starts with a H(plaintext), which means that an attacker which can guess the plaintext ...
7
I think you are referring to Colin Percival's Everything you need to know about Cryptography, in one hour in which he observes:
An asymmetric authentication scheme is considered to be
broken if an attacker with access to the verification key can
generate any valid ciphertext, even if he can convince you to
sign arbitrary other plaintexts.
This is ...
6
A reason to use CBC (or CFB) over CTR and OFB could be that they are a bit more misuse-resistant: If you use CBC with a repeated initialization vector, a (read-only) attacker only can get the fact that the plaintexts are equal up to some block, and not much more (and from the first different block the rest is different). With CTR and OFB, a repeated ...
6
Summary. This scheme is insecure. It can be cryptanalyzed using standard methods from the cryptanalytic literature. It also has poor performance.
Your algorithm. To summarize your scheme, in your algorithm a one-bit message $m \in GF(2)$ is encrypted by picking a random quadratic polynomial $p(x_1,\dots,x_{128})$ in $GF(2)[x_1,\dots,x_{128}]$, setting $c ...
5
There is no universally accepted definition of the expression "stream cipher"; but the one I most often encounter is the following: a stream cipher is a symmetric encryption algorithm which accepts as inputs arbitrary sequences of bits (or bytes) such that:
the length of the output is equal to the length of the input (no padding);
for any $n$ (possibly any ...
5
There is a theoretical construct described here (published in FSE 2007), assuming that the stream cipher is "seekable" (it suffices that the stream cipher can be initialized with a key and an IV, so that you can have many streams for a given key; the stream ciphers described in the eSTREAM Project accept an IV, but RC4 does not). The construction is ...
5
OFB and (to a lesser degree) CFB are malleable: an adversary knowing a selected portion of the plaintext and able to change the ciphertext can trivially change the alleged plaintext to something chosen, e.g. "no!" to "yes". CBC has a (small) degree of resistance to that.
OFB does not allow decryption of an isolated segment of ciphertext. CBC (and CFB) do.
...
5
Actually, it's option 1: the attacker won't be able to compute anything, as long as a secure cipher is used.
The reason for this is that one of the requirements of a security cipher is resistance to known plaintext; that is, a message encrypted by the cipher with a key is secure even if the attacker can get the text of another message (and corresponding ...
5
A PRG and a hash function are both PRFs, but they have different security considerations. (At least, historically they do. Moving forward some of them may be more closely aligned.) Due to this, building a hash from an existing PRG designed under older security constraints probably isn't a good idea for the intuitive construction of using the plaintext as the ...
5
If the keystream $p$ is as long as the plaintext $x$ (and is not reused), then $y_n := x_n \oplus p_n$ is a one-time pad, which is theoretically unbreakable, and thus needs no further strengthening.
On the other hand, if $p$ is shorter than $x$, then what you have is basically equivalent to a Vigenère cipher, which is known to be quite weak. Thus, any ...
5
As Thomas notes, most stream ciphers cannot be parallelized (in the sense that generating a single keystream would be significantly faster with multiple processors than with one) or randomly accessed (in the sense that the mimimum time needed to compute the $k$-th bit of the keystream would be sub-linear in $k$).
Examples of stream ciphers that cannot be ...
5
As D.W. notes, the distinction made between "bit-based" and "word-based" stream ciphers in the source you cite is irrelevant to the end-user. For both kinds of stream ciphers (as well as for block ciphers in streaming modes like CTR or OFB), the manner in which the keystream is combined with the plaintext is always the same: bitwise XOR, which operates at ...
5
As fgrieu points out, the number of states reached is at most $2^\ell-1$ and that is achieved only if the feedback polynomial is a primitive polynomial (and the initial state is not all
zero). If the feedback polynomial is irreducible but not primitive, then with
nonzero initial loading, the LFSR state will cycle through $N$ states, where $N$ is a
divisor ...
5
As pointed in the question, a conservative API to authenticated encryption should only ever release authenticated plaintext on the deciphering side. Anything else is too open to attacks (padding, timing, denial of service, unamit).
In a streaming API, this forces aggregation of data into blocks, each authenticated. The simplest method is fixed size ...
5
The problem with this approach is that it literally gains you nothing. In order to choose a random subsequence of a needed length from $\pi$, you need to generate a cryptographically random number of at least the same length of the desired key to use as the offset. But then you may as well just use that number as your secret key.
Other than that, yes, it's ...
5
Firstly, I presume this is not something you are going to use for protecting data in any kind of real life scenario, but are only asking out of curiosity.
Secondly, just to get the terminology straight and avoid confusion, what gives an OTP cryptographic scheme information theoretic security is that it meets both of the following two criteria:
The key ...
4
You can use any invertible operation to apply the key stream to the plaintext for encryption (and use the inverse to apply the key stream to the ciphertext for decryption).
Addition/subtraction are such a pair, but you have to take care for the carry - either use it $\bmod 256$ (i.e. byte-wise), or use it $\bmod 2^n$ with $n$ some block size in bits.
Make ...
4
One important difference between the one-time pad and a stream cipher is the proof of security of the one-time pad. Shannon proved that the one-time pad provides perfect secrecy. He also provided another proof that is interesting to this dicussion. His proof was that no cipher can provide perfect secrecy unless the key is at least a long as the message. ...
4
In an answer to another question, Zooko mentioned the BEAR and LION constructions, linking to this paper: Two Practical and Provable Secure Block Ciphers: BEAR and LION.
These build a block cipher (with large blocks) from a stream cipher and a hash function (a keyed one (i.e. a MAC) for BEAR, a unkeyed one for LION).
The authors basically build block ...
4
No it cannot be used to create an OTP as the technical definition of OTP requires that the pad be truely random and the output of PBKDF2 is not true random, only pseudo-random.
Of course you can generate a large pad from a password and xor it with your random plaintext. What you lose though are strong security guarantees. AES has been hammered at by really ...
Only top voted, non community-wiki answers of a minimum length are eligible
