Hot answers tagged

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


10

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


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


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


8

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.


8

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


8

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


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


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

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


6

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


5

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


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


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

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

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

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(n^{2n/3})$ rather than $O(n^{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 ...


4

Yes, EME is a wideblock cipher. Theorem 1 (in Section 4, top of page 5) states that EME is secure as a wideblock (tweakable) cipher under the assumption that AES (or whatever blockcipher you use) is secure. Specifically, to someone who doesn't know the key, EME will look like a set of random, independent permutations (one for each tweak). This is true even ...


4

There are two well-known Encryption modes, that can construct a $mn$-bit tweakable blockciphers from a $n$-bit blockcipher ($n=64$ for DES) with $1\le m\le n$. The older one is CMC, being not parallelizable. It was superseeded by Encrypt-Mix-Encrypt (EME), which is parallelizable. The basic idea of the two algorithms is to encrypt each block of input data ...


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

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


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.


4

What you are looking for is a definition of PEM, privacy enhanced mail. Obviously PEM is not just used for mail anymore. The definition of the header lines seems to be best described by section 4.6: "Summary of Encapsulated Header Fields" of RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication ...


4

One of the basic security requirements of a block cipher mode of operation is that it is indistinguishable under chosen plaintext attack (IND-CPA). Essentially, this means that, if an attacker chooses two messages $m_A$ and $m_B$ and the defender randomly returns either $\text{Encrypt}(K, m_A)$ or $\text{Encrypt}(K, m_B)$ (with $K$ kept secret from the ...


4

Some amount of known or controlled plaintext is clearly required for the attacker to get the block cipher output. Actually, that's not much of an issue; we can often get a reasonable amount of known plaintext from real encrypted messages. In fact, the known plaintext for each message doesn't have to be the same, and you don't have to have completely ...


4

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



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