# Tag Info

## Hot answers tagged block-cipher

25

First : Welcome to Crypto.SE. Even though you are quite young, it should not be a reason for someone to stop you : Alan Turing was 23 (still undergraduate) when he undermined the work of Alonzo Church (on untyped $\lambda$-Calculus). I'm not saying you should always provide your idea, but if you can defend them, have fun. About your cipher : The first ...

12

Honestly, I don't see any obvious reason why a novel cipher design couldn't be the subject of a bachelor's thesis. And presenting it as part of a thesis could even be a decent way to get others to look at it and maybe analyze it. Admittedly, a more conventional choice for a bachelor's thesis might be something like a basic cryptanalysis of an existing ...

10

I'd have to dig up the quote, but one thing you should be ready for is a statement which I believe was made by Bruce Schneier. He commented that if someone presents him with a new algorithm they invented, his first questions are "who are you, and what encryption algorithms have you played a part in breaking?" Because it's so easy to make an encryption that ...

9

It is usually assumed that the length of the message is not secret. Even with padding the approximate length is usually leaked, and necessarily any encryption reveals a maximum length (or at least information content) because the ciphertext cannot in general be shorter than the message. NaCl secretbox does not use a block cipher, but a stream cipher (...

9

AES has a block-size of 128 bits in all its variants. The number in AES-128/192/256 is the key-size. Rijndael, the block-cipher that became AES, also supports 256 bit blocks, but that part was not standardized as AES. Since the block-size is 128 bits, GCM works exactly the same way for AES-256 as it does for AES-128.

9

The fastest block cipher is identity, which leaves input blocks completely unchanged. This is infinitely fast on all platforms; however, it is not secure. So maybe you want the fastest block cipher that still offers some given non-trivial level of security? Then it depends a lot on what you want to implement the block cipher on. With recent PC, you would ...

8

Indeed, ECB is such that encrypting twice the same plaintext leads to the same ciphertext. Even worse, encrypting a plaintext containing twice the same plaintext block leads to a ciphertext containing twice the same ciphertext block. Either is a disadvantage because it goes against the ideal of a cipher: depriving the adversary from any knowledge about the ...

7

I've checked out the source code (well, more or less, it's not that well designed, the main crypto class is 1600 lines) and as Richie guessed, the algorithm is stored together with the ciphertext. Pretty gruesome stuff, but it does do EAX mode for text strings to my surprise. It probably only uses it for text strings originating from the password vault code ...

7

Is Rijndael the fastest block cipher in the world? No. On an Intel 64 Sandy Bridge without AES-NI, AES (a subset of Rijndael) is outperfomed by ChaCha20 (and also likely by Threefish 512 which has about 6-7cpb cost on an older Intel Core 2 Duo with 64-bit ASM (link: original Skein paper PDF)) as opposed to AES' 11 cpb. (7.59 cpb on an Intel Core 2) ...

6

XTEA is a block cipher. It requires a block cipher mode of operation to work. Together with a block cipher mode of operation you can generate something that is secure. For this you require at least an IV, as you may otherwise encrypt identical passwords (for different users) to identical values. Or, if you encrypt each character separately, the same ...

6

You might consider using TEA or its successor, XTEA. Here's the complete C source code for XTEA, taken from the Wikipedia article: #include <stdint.h> /* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */ void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { unsigned int i; uint32_t v0=v[0], ...

6

Dedicated stream ciphers typically are, or at least can be, somewhat faster than constructions based on block ciphers. (If they weren't, there would be no point in using them, since a block cipher can do everything a dedicated stream cipher can.) What you gain in speed (and possibly code size), however, you lose in versatility: A block cipher (in CTR / ...

6

A symmetric cipher design contest was started in Ukraine around 2006, and this cipher (in Ukrainian and Russian: Мухомор) was there. For specifications, look for "Applied Radioelectronics" journal "Прикладная радиоэлектроника", 2007, No 2. http://anpre.org.ua/?q=pre_2007_2 http://dspace.nbuv.gov.ua/bitstream/handle/123456789/61794/06-Dolgov.pdf

5

First of all, there's no such thing as a secure 8-bit block cipher, at least not as such things are conventionally used. That's because there are only 256 possible values for an 8-bit byte, and a block cipher will map each of these values to a different fixed value. Thus, an attacker who can even occasionally guess the unencrypted value of some bytes (or, ...

5

Suppose you do CTR mode as: $E(k,nonce+1) \oplus m_1$, $E(k,nonce+2) \oplus m_2$, $E(k,nonce+3) \oplus m_3$, etc. The wikipedia page is talking about a non-random nonce, with a specific example of a packet counter. So suppose $nonce$ is a packet counter and in each packet you encrypt several blocks. You might end up with the following: In packet #$p$: ...

5

This question is based on opinion. At least kind-of. But the variants from which one can choose are quite a few. As for general construction the sponge construction (like Keccak / SHA-3 uses) are very versatile and can be used for many purposes, for example hashing, authenticating (= "MAC'ing"), authenticated encryption (see “General Overview of the First-...

5

The key size is simply the amount of bits in the key. With AES, like most modern ciphers, the key size directly relates to the strength of the key / algorithm. The higher the stronger. AES is a bit different with respect to the key size in the sense that both the key schedule and the number of rounds are different for each key size. Because of this there ...

5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...

5

The obvious answer to your question is "yes". The kernel mode implementation pointed to by otus clearly shows that it can be done. That it can be done doesn't mean it gets done however. Many Google searches for sourcecode don't show any OpenSSL code that implements this functionality. In general, OpenSSL doesn't rely on the crypto code of the kernel. So, ...

5

It is not a standard mode of operation and I do not know if anyone uses it in practice, but one option is double encryption using counter mode and a non-repeating counter. That is, doing $E_{k_1}(i) \oplus E_{k_2}(i) \oplus p$. The sum of two PRPs is a PRF with better bounds than one. The bound is basically $O(2^{2n/3})$ rather than $O(2^{n/2})$. See The ...

5

You can compute $f(x) = x^{\phi(p)-1} \bmod p$ in constant time, using $O(\log p)$ constant time modular multiplies. If $p$ is prime, this reduces to $f(x) = x^{p-2} \bmod p$ BTW: calling it 'Knuth's' algorithm is, in general, not very helpful; Knuth gives hundreds of different algorithms in 'The Art of Computer Programming'. I assume you mean the ...

5

what if you were to incorporate a Block Cipher Mode into a hand cipher That line is a bit misleading and hints at a potential misunderstanding. A "mode of operation" is more something you wrap around a block cipher… not something you incorporate or embed into a cipher algorithm. if you have a big enough key space, a small enough cipher text, can a very ...

5

The simple answer is that fewer than 3 rounds can be easily distinguished from a random permutation. The 2-round Luby-Rackoff cipher on $2n$ bits, using random functions $f_i$ mapping $n$ bits to $n$ bits, consists of $$F(L, R) = (A, B),$$ where $A = L \oplus f_1(R)$ and $B = R \oplus f_2(L \oplus f_1(R))$. Now consider an attacker that wants to ...

5

Block ciphers are usually used in modes of operation. The security of a mode of operation depends on two things: the security of the underlying block cipher, and the security of the mode itself when you replace the block cipher with an "ideal" permutation. Say you're using a block cipher with block size $n$ bits, so with AES-256, $n = 128$ (the 256 refers ...

5

Block size does not directly affect the security of the cipher. However, if block size is too small, it can prevent you from using the cipher securely. The main effect of block size is due to the fact that a block cipher is meant to be a pseudorandom permutation (PRP). That means that any two inputs will have outputs that differ iff the inputs differ. So ...

4

They're both broken under known plaintext attack, where attacker knows two (plaintext, ciphertext) pairs, $(m_1,c_1)$ and $(m_2,c_2)$: $E'_1(k_1,k_2) := k_1 \oplus E(k_2,m)$ $E'_1(k1,m_1) \oplus E'_1(k1,m_2)=E(k1,m_1) \oplus E(k1,m_2)$ The attacker simply computes $E(k1,m_1) \oplus E(k1,m_2)$ for every possible value of $k_1$ and compares it with $c_1 \... 4 I can make a few comments regarding points 1 and 3: If you are going to encrypt only one block, your first assumption is not that misled. However, you will almost always need to encrypt a file longer (maybe way longer) than the key length (let's say 128 bits). Without considering encryption modes, that means that for every block of 128 bits, you will ... 4 As I understand, your question is about using an involutive function$F$as a block cipher. This function is constructed as$F(x) = D(P(E(x)))$, for some (let's assume secure) block cipher represented by$(E, D)$. I will assume the encryption and decryption keys are equal such that the same holds for$F$. Below is a generic attack that only uses the ... 4 Actually, Maarten isn't quite correct; in most cases, the counter doesn't have to be updated in constant time (because it's not secret); however in one case it does: GCM with an IV size that's not 12 bytes. The reason the counter needs to be secret in this case is not because how it is used, but how it is generated. It is initialized to$GHASH_H(IV||0^{s+...

4

Yes, this is fine. There is a practical disadvantage in space used, if you don't otherwise need to store the size in plaintext. A size field will usually take 32 or 64 bits, whereas typical padding adds one byte on average. Also, if you use encrypt-then-MAC you need to include the length as part of the authenticated data.

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