# Tag Info

23

Most encryption is based heavily on number theory, most of it being abstract algebra. Calculus and trigonometry isn't heavily used. Additionally, other subjects should be understood well; specifically probability (including basic combinatorics), information theory, and asymptotic analysis of algorithms. There's also more math that's worth knowing to be a ...

18

17

People found MARS to be clunky and overly complex, leading to more effort for implementation and optimization, and also a less clear overall security picture. Assessments of "security" are, in fact, extremely subjective, because they rely on speculations about unknown future cryptanalytic attack, empiric traditions (e.g. "more rounds" = "more security"), ...

16

It's a good question. As pg1989 said, this is the basis behind stream ciphers, which are very fast in practice. I thought I'd quickly expand upon your statement that "the one-time pad is the perfect cipher and impossible to crack." This is true, in a sense, but it's worth pointing out that sometimes an attacker wants to do something simpler than "cracking" ...

13

Well, the exact reason for an IV varies a bit between different modes that use IV. At a high level, what the IV does is act as a randomizer, so that each encrypted message appears to be encrypted to a random pattern, even if those messages are similar. In general, IVs disguise when you encrypt the same message twice (and more generally, when two messages ...

13

The algorithm (now reasonably clear) is reminiscent of a block cipher in CFB mode, with $random$ as the IV (which can be public), $secret$ as the key, and MD5 used as keystream generator instead of the block cipher. Decryption works as in CFB: $$M_1 = C_1 \oplus \operatorname{MD5}( secret||random )$$ $$M_n = C_n \oplus \operatorname{MD5}( secret||C_{n-1} ... 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 ... 12 The really great thing about Diffie-Hellman is how light it is, network-wise: both parties send each other a single message; neither has to wait for the message from the peer before beginning to computing his own message. If you can tolerate something heavier, you can have a look at what @Paŭlo describes; with n participants, it requires n-1 messaging ... 11 If the key is: generated with an unpredictable truly random uniform generator (not a pseudo-random generator); as long as the data to encrypt; used for only one message ever; then this is the One-Time Pad model, and you can encrypt data by a simple bitwise XOR (no need for an explicit function, just XOR). Otherwise, there is no solution which resists ... 11 The standard Diffie-Hellman key exchange algorithm (or family of algorithms) works in an cyclic group with generator g, and relies on$$ {y_A}^{x_B} = (g^{x_A})^{x_B} = (g^{x_B})^{x_A} = {y_B}^{x_A}, $$where y_A and y_B are publicly transmitted, while x_A and x_B remain private. With three parties, we still have$$((g^{x_A})^{x_B})^{x_C} = ...

11

Many cryptographic algorithms are expressed as iterative algorithms. E.g., when encrypting a message with a block cipher in CBC mode, each message "block" is first XORed with the previous encrypted block, and the result of the XOR is then encrypted. The first block has no "previous block" hence we must supply a conventional alternate "zero-th block" which we ...

11

First, and I know this isn't exactly the answer you're seeking, but I'd mull over it for a while. Hopefully you have read Schneier's Memo to the Amateur Cipher Designer; it speaks the truth. In short, before you try to go the route of publishing your algorithm, here are some things you should consider: What makes your scheme compelling to study? Is it ...

10

The combination between addition modulo $2^{32}$ (not modulo $32 = 2^5$) - indicated by $\boxplus$ in the diagram - and XOR (i.e. bitwise addition modulo $2$) - indicated by $\oplus$ - makes the algorithm more non-linear. Each of them for itself is a linear operation, but over different groups (addition in $GF(2^{32})$ vs. addition in $Z/2^{32})$, and the ...

10

If a block cipher is linear with respect to some field, then, given a few known plaintext-ciphertext pairs, it is possible to recover the key using a simple Gaussian elimination. This clearly contradicts the security properties one expects from a secure block cipher.

10

Sure. If you want a $b$-bit hash of the message $m$, then use the first $b$ bits of AES-CTR(SHA256($m$)). That'll do the trick. In other words, compute SHA256($m$) and treat the resulting 256-bit string as a 256-bit AES key. Next, use AES in counter mode (with this key) to generate an unending stream of pseudorandom bits. Take the first $b$ bits from ...

9

Timing attacks rely on operations which do not always take the same time to execute, depending on the processed data. For instance, on a typical software platform (say, a PC) implementing SHA-256, all operations are 32-bit additions or rotations or bitwise combinations which take a constant time to execute, regardless of the actual operand values. SHA-256 is ...

8

There are some approaches. In many algorithms it for the security doesn't really matter what constant is used, as long as it is not too simple, like initialization vectors for hash functions. (And of course, we need to use always the same number.) Then mathematical constants like binary expansions of irrational numbers like $\sqrt{2}$ (or roots of other ...

8

First of all, I think I want to correct you at one point; in step 2, you aren't actually that interested in whether the operation is commutative, what you're actually interested in is that the operation is associative, that is, if $(a \oplus b) \oplus c = a \oplus (b \oplus c)$. In essence, your operator $\oplus$ in step 2 turns out to be a group operation. ...

8

In general, each combination of a (secure) hash function for input with a (deterministic) pseudo random number generator for output will work here - one "state of the art" example is the one given by D.W. (using AES-CTR as PRNG and SHA-256 as hash). Another way is similar to what PBKDF-2 does to have output with the right length: hash the input (or a hash ...

8

It's not clear from your decryption what the algorithm is used for. But you should be aware that while at first glance it provides privacy : it's a weird mode CFB with md5 used as a block cipher ; it doesn't provide authenticity. A simple bit flip of the ciphertext will result in the corresponding bit being flipped in the plaintext and such a bit flip ...

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

Mostly yes: usual cryptographic operations, including hashes, are defined using operations on integers and bit vectors, not Floating Point Numbers. I think the main reason is that in cryptography, we need different computers (e.g. the one that hashes a file to protect its integrity, and the one that verifies the integrity) to get the exact same result, and ...

7

Vanilla textbook RSA does not include "padding and stuff", the term "textbook RSA" generally refers to simply encoding a plaintext message as an integer and raising it to an exponent. Implementing this is pretty easy, just follow the steps outlined on Wikipedia. You can easily translate those steps into some given programming language. Based on the rest of ...

6

As you suspected, there's a very close relationship between white-box cryptography and obfuscation. (Good instincts!) White-box cryptography is basically all about obfuscating an encryption implementation. White-box cryptography is obfuscation of crypto code. Imagine that you took an AES implementation, picked a random AES key, and then hardcoded that AES ...

6

If you use a concrete-security definition of security for a PRG, then this statement is true. The proof is a good exercise. If you know enough to pose the problem and to understand the definition of security for a PRG, you should be able to find the reduction proof without difficulty. Start by tracing out what the definition is saying. A general comment ...

6

In your construct: EncryptAB(K1||K2, PT) = EncryptA(K1, EncryptB(K2, PT)) it is easy to show that, as long as the keys K1 and K2 are independent, that this cannot be any less secure than the stronger of EncryptA and EncryptB. Here is a sketch of how this is shown; suppose that there is a chosen plaintext attack against EncryptAB; that is, the attacker ...

6

Schneier's "A Self-study Course in Block-Cipher Cryptanalysis" is an excellent resource for what you are looking for. In particular, FEAL-4 would be a promising cipher to look at as it is breakable by almost every cryptanalysis technique. One thing you will notice when going through Schneier's course (or when looking at cryptanalysis research in general) is ...

6

SHA-256 uses an internal compression function $f$ which takes two inputs, of size 512 and 256 bits respectively, and outputs 256 bits. Hashing works like this: Input message $M$ is first padded by appending between 129 and 640 bits (inclusive), resulting into a padded message $M'$ whose length (in bits) is a multiple of 512. $M'$ is split into $n$ ...

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

This is a case for public-key cryptography (in the form of digital signatures, or a key exchange algorithm). In the simplest case, the program (Alice) would know (embedded in the source or in a configuration file) a public key, and the user (Bob) would have the corresponding private key. Bob would then send the message which should be authenticated, and ...

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