# Tag Info

62

These decisions are driven by silicon. Most specifications for hardware are built around a minimally viable CMOS implementation (ex: MPEG-1, lightweight cryptography via NIST 8114). This is particularly true in commodity parts, such as cell phones. When you make wireless ICs, you have two clocks in the system at a minimum, which are the carrier frequency ...

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

16

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

16

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

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

13

Ericson's white paper lists them as The strong and well-proven security algorithms from the 4G system are reused. These are encryption algorithms based on SNOW 3G, AES-CTR, and ZUC; and integrity algorithms based on SNOW 3G, AES-CMAC, and ZUC. The main key derivation function is based on the secure HMAC-SHA-256. Notably, all of them are stream ciphers ...

12

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

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

12

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

12

The Insecurity of Proposed Scheme It is not as secure as it seems, in modern cryptography standards it is totally insecure. It is vulnerable to basic Known-Plaintext attacks (KPA) and in Modern Cryptography, we want a cipher secure against at least Chosen Plaintext Attack (CPA) or better Ind-CPA. Now take the idea $$K' = H(X\mathbin\|K) \mathbin\| H(H(X\... 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 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 ... 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 "... 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 ... 10 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 ... 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) and as ...

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

"Is it possible to actually obtain a key by XORING message(plaintext) and ciphertext?" Of course it is; it's actually pretty easy. On the other hand, those specific key bits were used once; their only use is to protect that specific plaintext; if the attacker learns (by whatever method) what those keybits were, he learns what the plaintext is. If the ...

9

As long as your encoding of $K$, $N$, and $i$ is injective (i.e., for each encoded string you can uniquely derive $K$, $N$, and $i$) and fixed-length, this is almost certainly a decent stream cipher. It won't break any speed records, obviously! But collision resistance is not relevant here, and I have no reason to suspect that the distribution of $x \... 9 Role of IV in stream cipher? Like in block ciphers; it helps to achieve randomized encryption. Also, using different IV under the same key prevents the crib-dragging attack like in all stream ciphers. This enables us to reuse a key without causing the crib-dragging attack ( that works on two or many-times pad) by using different IVs. If the IV repeats ... 8 I doubt you will find a fast implementation of Salsa20 in Java (having spent much time attempting to achieve just this). Salsa20 mutates a 512 bit state made up of 16 x 32 bit integers, which means that implementations that don't take advantage of SIMD (on Java or otherwise) will probably not perform well - there are too many independent state parts to keep ... 8 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 ...

8

What you've described is generally called a "book cipher" or "Ottendorf cipher", where the "key" is knowing which publication is being referenced, as well as the algorithm for recovering information from it. A hundred years ago they were quite secure because not only were books fairly rare, but trying every book against an unknown cipher was very time ...

8

If you are constrained by the embedded environment, you should consider CCM instead of GCM as AES mode. One of the major constrain when implementing GCM is that the authentication part (the GHASH) is totally unrelated to AES and should be implemented in its own way. And, to make it reasonably fast, you have to use key-depended look up tables which will ...

8

If a large file enciphered using RC4 is partially corrupted, the uncorrupted portions remains fully decipherable, including what's after a corrupted portion if the corruption modifies this data's value, but not its length (a length corruption could occur e.g. for serial communication, but is unlikely on a hard disk). This is a property of all stream ciphers. ...

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