# Tag Info

40

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

29

"Hint: XOR the ciphertexts together, and consider what happens when a space is XORed with a character in [a-zA-Z]." 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 ...

23

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

17

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

15

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

15

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

15

XSalsa20 uses the same cryptographic core as Salsa20 and comes with a security proof that it's secure if Salsa20 is secure. It doesn't use the core of ChaCha and thus has worse diffusion. The way XSalsa20 works is that it hashes its 256 bit key and the first 128 bits of the nonce using HSalsa down to a 256 bit key and then uses that key together with the ...

15

By the modern definition of a cipher, it must be possible to encipher several messages with the same secret key. That's also a practical necessity, due to the difficulty of securely establishing a shared secret key. That issue is solved with the nonce, which is not secret, and can be transferred as part of the ciphertext (typically: at the beginning). ...

14

Salsa20 has strong rotational symmetry. The main point of these constant is that they're not invariant under rotations, introducing an asymmetry. The precise value isn't very important, as long as it's sufficiently asymmetric. Bernstein - Salsa20 security says: Notes on the diagonal constants Each Salsa20 column round affects each column in the same ...

13

The internal state of RC4 consists of a shuffled 256-element array and two pointers into that array. Thus, there are a total of $$256! \times 256^2 \approx 2^{1700.00}$$ possible states. Since the state update function of RC4 is reversible, it acts as a permutation on this set of possible states, so that every starting state will eventually recur after ...

13

AES-CTR is a stream cipher, of a particular kind where the keystream is obtained by encryption of a counter. So the question reduces to: what are drawbacks of AES-CTR compared to other stream ciphers? The main ones compared to ChaCha20 are: Without hardware support, AES can fail to cache-timing attacks. Without hardware support, AES is slower. Without ...

12

A block cipher by itself does map n bits to n bits using a key. i.e. it's a keyed pseudo-random permutation. It cannot accept longer or shorter texts. To actually encrypt a message you always need a chaining mode. ECB is one such chaining mode(and a really bad one), and it's not the pure block cipher. Even ECB consists of "add-on processing operations". ...

12

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

12

Synchronous stream cipher, or just stream cipher. In a synchronous stream cipher a stream of pseudo-random digits is generated independently of the plaintext and ciphertext messages, and then combined with the plaintext (to encrypt) or the ciphertext (to decrypt). In the most common form, binary digits are used (bits), and the keystream is combined with ...

11

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 know how to exactly compute the period size, which very ...

11

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

11

An OCB like mode seems impossible with stream-ciphers. It's coupled tightly to the concept of a keyed permutation i.e. a (tweakable) block-cipher. Many authenticated encryption actually combine two distinct primitives. It's just that the specification and API only expose the combination. Essentially these xor a key-stream into the message to encrypt it (i....

11

...wouldn't key still get repeated every few hours or so - i.e. you come to the end of the PRG(K)... This is where you are mistaken. Modern cryptographic PRGs simply do no repeat within any conceivable time frame. That is, starting from a seed, a well-constructed PRG (and this is true even when they are not so well constructed, like RC4) will simply never "...

11

Before we start answering the subquestions, let's bring up some background knowledge. The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as a generalization of both hash function (var->fix) and stream cipher (fix->var). Since ...

10

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 =... 10 If there was no non-linearity, then every bit of keystream output would be a (known) linear function of the unknown key bits. Consequently, in a known-plaintext attack scenario, each bit of known keystream output would allow us to write a linear equation on the unknown key bits. If we have a 128-bit key, there are 128 boolean unknowns (variables), so once ... 10 eBACS, as given by CodesInChaos, is a great resource, and it provides much more data than I could hope to give in this answer. However, the page is not explicit about whether or not AES-NI was used — looking at the results, it doesn't seem so. For an extremely shallow analysis, but allowing us to know for-sure about hardware acceleration, we can use ... 10 Many stream ciphers work by transforming a short key (and optionally a nonce) into a long key-stream that's xor-ed into the plaintext to produce the ciphertext, which is exactly the construction you're proposing. Wikipedia calls these Synchronous stream ciphers. Most popular stream ciphers fall into this category, including block ciphers operated in CTR or ... 9 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 ... 9 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 ... 9 There are several ways to answer your question: You cannot "replace" RC4 in SSL. SSL is a standard protocol in which any algorithm may be used only if both client and server support it and agree to use it. Thus, in practice, you do not get to replace algorithms as you wish, unless you control both client and server code; and even then, it would not longer ... 9 Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}\$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...

9

Pulling information from the wikipedia entry on Salsa20: eSTREAM selection Salsa20 has been selected as a Phase 3 design for Profile 1 (software) by the eSTREAM project, receiving the highest weighted voting score of any Profile 1 algorithm at the end of Phase 2.[6] Salsa20 had previously been selected as Phase 2 Focus design for Profile 1 (software) ...

9

Let's consider CTR mode encryption with a random IV for a block cipher (essentially the same as stream cipher, but simpler to analyze since the formalization of stream cipher security is not fully standardized). On the one hand, it seems like it should be CCA1-secure since there is nothing that an attacker can do in the CCA1 queries that can help later. ...

9

For stream ciphers, IND-CCA1 and IND-CPA security differ precisely in that an attacker can choose the IV in the CCA1 game (because that's part of the ciphertext that can be submitted to the decryption oracle); but in the CPA game is constrained to whatever choice of IV the cryptosystem makes. We can artificially construct a stream cipher vulnerable under ...

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