Tag Info

Hot answers tagged

94

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


44

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


38

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


23

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


14

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

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


12

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


11

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


11

Very short answer: No Quite Short answer: No, because a scheme can only be a One-Time-Pad if the entire pad is perfectly random and secret. Concise answer: It sounds like you're trying to build a stream cipher. The security of it really comes down to how much of the scheme you think can be kept secret. If I listen in to your wifi and hear you requesting a ...


10

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


10

Let's assume that the plaintexts consist only of spaces and ASCII letters. Given the hint, that seems like a reasonable assumption to start with, even if it might turn out to be only mostly correct. Now, take one of the ciphertexts and XOR it with each of the others. Of course, the XOR operation cancels out the keystream, so you end up with the plaintext ...


10

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


9

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


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

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


8

A block cipher is a deterministic and computable function of $k$-bit keys and $n$-bit (plaintext) blocks to $n$-bit (ciphertext) blocks. (More generally, the blocks don't have to be bit-sized, $n$-character-blocks would fit here, too). This means, when you encrypt the same plaintext block with the same key, you'll get the same result. (We normally also want ...


8

Yes, this would be secure. CTR (Counter) mode based on keyed function $F_K$ is secure as long as its output $$ W_i = F_K(i) $$ is unpredictable given previous outputs $$ F_K(1),F_K(2),\ldots,F_K(i-1). $$ This requirement is essentially the definition of a pseudo-random function (PRF). Most HMAC instantiations with widely used hash functions are believed to ...


7

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


7

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


7

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


7

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


7

It is quite simple and stems from the idea that flipping one bit in the ciphertext flips the corresponding bit in the plaintext. So, say the ciphertext is $1011$ and we know the plaintext is $0101$ (thus the key is $1110$). Say we want a plaintext of $0000$, we just have to change the ciphertext to $1110$ (notice where the bits have been flipped) and we ...


6

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


6

By definition of Salsa20 used as a stream cipher, it uses a 64-bit block counter and 64-bytes blocks, limiting its capacity to $2^{73}$ bits. After that, the counter would rollover, and thus the output. In a sense, this is the period. RC4 has no such explicit limit on the size of its output. We do not known how to exactly compute the period size, which very ...


6

Mathematically, a block cipher is just a keyed pseudorandom permutation family on the set $\{0,1\}^n$ of $n$-bit blocks. (In practice, we usually also require an efficient way to compute the inverse permutation.) A block cipher on its own is not very useful for practical cryptography, at least unless you just happen to need to encrypt small messages that ...


6

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


6

The property desired of stream ciphers, just like for any random number generators, is indistinguishability from true randomness — and indeed, any RNG that fails a statistical test suite is obviously not a good stream cipher. However, to be considered secure, a stream cipher must not only withstand a generic battery of statistical tests; its output ...


6

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


6

The Berlekamp-Massey algorithm is an iterative method for finding the shortest LFSR that can generate a given sequence of bits. The given sequence might or might not be generated by an LFSR: the Berlekamp-Massey algorithm does not care. It just finds the shortest LFSR that can generate the given sequence, and if the sequence has been generated by an LFSR of ...



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