# Tag Info

## Hot answers tagged algorithm-design

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} ... 10 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 ... 9 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 ... 9 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} = ...

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

9

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

9

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

8

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

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

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.

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

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

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

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

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

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

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

6

EDIT: The following block of text (between the lines) was written as an answer to the original question, which did not explicitly state that the secret was used for any blocks after the initial one. Hmmm, I assume that the goal of this algorithm is to provide privacy; that is, to create an encrypted message, and someone that hears this encrypted message ...

5

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

5

This has more to do with how Microsoft decided to implemented their certificate inspection GUI, than about the actual fields of the certificate. Most signature algorithm identifiers present in contemporary certificates specify both the public key algorithm (RSA in this case) and the digest algorithm (SHA-1 in this case). The identifier "sha1RSA" is most ...

5

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

5

I think that a stream cipher would be the natural progression from a Vinegere, (before moving onto a block cypher). ARC4 would be my choice and there are good argument for that made by Arnold Reinhold over on http://ciphersaber.gurus.org/

5

Here's the cryptography theory perspective. We want block ciphers to resemble pseudo-random permutations (PRPs). PRPs are a desirable modeling goal because a block cipher under a given key is a permutation on the input, and a PRP is simply a random collection of permutations. The block cipher's key can never be better at creating permutations than an actual ...

5

The fragment " what to do about padding the key ? " of the question looks scarily like transforming a password into a cryptographic key using some padding mechanism. Doing this would be a known, serious, often made and often exploited mistake. A standard security assumption for ciphers is that the key is chosen at random, and a padded password is not random ...

5

As D.W. notes, you can use the output of any conventional hash function to key a stream cipher (or a block cipher in a streaming mode like CTR), and then take the output of the cipher as your digest. However, there has been a trend in modern hash function design to support arbitrary-length output directly, without the need for additional layers. For ...

5

The Skein family of hash functions (submitted to NIST for the SHA-3 competition, but not selected as the winner) has a really well-written paper that tries to go into detail for how it was designed, how constants were chosen, etc. It might be a good place to start.

5

Points 3 and 4 are a secure way of storing the input to bcrypt (with appropriate choice of parameters for bcrypt). Points 1 and 2 aren't necessary but don't harm: they would add a small amount of extra computation for an attacker is possession of the password database that wants to do a dictionary attack; the attacker wouldn't be able to straight-out use ...

4

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

4

The SHA-256 algorithm works by applying an encryption function in Davies-Meyer mode and Merkle-Damgård chaining. Merkle-Damgård works by first dividing the message to-be-hashed into chunks. In the case of SHA-256 these chunks are 64 octets long. Because Merkle-Damgård chaining is used, the internal state after processing the first 64 octet chunk depends only ...

4

Yes, it is possible for the composed scheme to be less secure, but the answer is a bit wonky -- and has to do with the way we define security for encryption schemes. If ENCRYPTB is secure under Chosen Ciphertext Attack (IND-CCA) and ENCRYPTA is secure under Chosen Plaintext Attack (IND-CPA), then the composed ENCRYPTAB is /not/ necessarily secure under ...

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