Tag Info

Hot answers tagged

8

Enigma is not a Feistel cipher. A "Feistel cipher" is a block cipher with a specific structure, namely the whole business with the two halves, the combination of one half with a (one-way) function of the other half and a reversible operation (e.g. XOR), and the swap. See the Wikipedia page which has nice schematics. So considering Enigma as a kind of ...


6

Mathematically, it can probably be done. There has been research into trapdoor block ciphers. See, e.g., A family of trapdoor ciphers by Rijmen and Preneel, and follow-up papers. In practice, though, the problem statement is not realistic. The assumptions are just not realistic. Today, there's no reason why Red would be limited to using Blue's ciphers. ...


6

First of all, this no block cypher at all. It's a stream cypher. Thus you can use every key only once, and you can't use any cypher modes built on block cyphers. Your scheme is vulnerable to a known plaintext attack. If the attacker knows 32 aligned(or 63 unaligned) bytes of plaintext, he can calculate the state of your cypher: $ S_i = P_i \oplus C_i $ ...


6

Main drawbacks of DES are: Small key space (56 bits). Small blocks (64 bits). Terrible performance in software, due to all the bit-juggling. Relative weaknesses with regards to linear and differential cryptanalysis. Changing any of these will imply heavy changes, not little tweaking. Doing that while maintaining or increasing security is no mere feat... ...


6

It is probably not the case of your example, but in some sense "asymmetric hash functions" do exists: they are called trapdoor hash functions (or also chameleon hash functions). Very briefly, they are collision resistant only if you don't know their trapdoor secret key. Such functions take 2 arguments (instead of the usual one), and the second argument is ...


6

Not only we can turn block ciphers into hash functions, but we do. The usual hash functions (MD5, SHA-1, SHA-256...) use the Merkle-Damgård construction which relies on a block cipher E. A running state r is initialized to a conventional value. Then the input data is split into a number of chunks, each chunk being used as key for the block cipher: r is ...


6

Neither of those really represent how confusion might get introduced into an encryption function. Confusion typically gets introduced during the computation of the ciphertext, not before or after. As an example, we can look at AES. AES is a substitution-permutation network. This means the encryption is done by doing several rounds of substitutions and then ...


5

Your cipher looks a bit like the output feedback mode of operation for block ciphers. While OFB for block ciphers is considered safe (as long as it is used right), OFB for a hash function like you are using it has the problem that the key is only used at the start, to generate the "initialization vector", not at each step of the algorithm. Thus, as ...


5

Hashes like SHA-x are symmetric and unkeyed. I have never heard of asymmetric hashes. Your question is based on a misunderstanding. You can implement computations in an asynchronous fashion, where you request some computation, then your thread is free to do something else, and at some later point when the computation is finished you do something with the ...


4

When we consider that a Playfair key consists of the alphabet (reduced to 25 letters) spread on a 5x5 square, that's $25!$ keys (another formulation consider any string to be a key; then strings leading to the same square are equivalent keys). The rules of Playfair are such that any rotation of the lines in the square, and any rotation of its columns, lead ...


4

Well, to figure out this sort of thing, it's easier if we work backwards. So, we start at the back (the fact that we can store up to 512 characters in a database field), and consider how much binary data we can store. Well, base-4 takes 3 bytes of binary data, and encodes it in 4 bytes of base-64. Thus, we can store 3*(512/4) = 384 bytes of binary ...


4

A key, in the context of symmetric cryptography, is something you keep secret. Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.). (There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which ...


4

The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret. A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something ...


3

No, it's a rotor machine and more importantly, a stream cipher that operates on a character-by-character basis. Block ciphers operate on a chunk at a time. Feistel ciphers are a way to construct block ciphers. We could talk more about Feistel ciphers or more basically block ciphers, but that's not your question. At its most basic, Enigma is a stream cipher ...


3

There are several systems that sound vaguely similar to your description. Would either one (or both) of the following systems work for you? If not, what exactly about systems is unsuitable for your application? deniable encryption You give a unique key to each of a bunch of people. You think up a unique plaintext message intended for one and only one ...


3

The Vigenère cipher has many weaknesses, but perhaps the most obvious ones are: An attacker, who knows (or can guess) as many consecutive characters of any plaintext message as there are in the key, can trivially recover the key and thus decrypt all messages. (In fact, the characters need not even be consecutive, they just need to cover the entire key, or ...


3

The one-time pad has this property. Specifically, letting $\oplus$ denote the bitwise XOR operation, the binary OTP is defined as: $$E(K,M) = D(K,M) = K \oplus M.$$ From the commutativity and cancellation properties of $\oplus$, it then follows that $$\begin{aligned} D(K_1 \oplus K_2, E(K_1, E(K_2, M))) &= (K_1 \oplus K_2) \oplus (K_1 \oplus (K_2 ...


3

The design of DES might give some insight into the problem. The NSA altered the S-box of DES. Many people thought they planted a backdoor. It wasn't until later that differential cryptanalysis was independently discovered by Biham and Shamir that people realized that the NSA actually made DES stronger. So the lesson to learn from this is: clearly the NSA ...


3

Don't bother with changing the actual cipher algorithm. Read about Kerckhoffs's principle: you should only change things like the key and the IV, not the actual algorithm. In order to test your avalanche, flip one bit in your key. That should change about half the bits in your output. For cipher design, Applied Cryptography has already been suggested. ...


3

Yes, it is possible to construct a hash function, or even a message authentication code (MAC), from a block cipher. The easiest way is to simply encrypt your input data with a pre-selected key, in a chaining mode such as CBC, and use the last output block of the cipher as your hash. However there are problems with this simple approach. Depending on the ...


3

That sort of thing is known as multi-party computation, and you should use a Socialist Millionaire Protocol for your particular instance.


2

I can't tell you which method is the best, but I can point out some places to look. The longer the message the easier it is easier to identify. How long is the message? n-gram frequency: Look at the likelihood that groups of n-letters appear next to each other (often called n-grams). For example is does the n-gram AAA appear frequently (not many languages ...


2

If I understood your code correctly, what you are doing is encrypting a message $m$ with a key $k$ by: $c=m\oplus h(k)$, in an ECB mode where $h$ is some hash function. Take two encrypted blocks $c_1$ and $c_2$ and add them: $c_1\oplus c_2 = m_1 \oplus h(k) \oplus m_2 \oplus h(k)=m_1\oplus m_2$. Moreover, you may loose entropy if the initial secret is ...


2

Not sure if this fits your requirement, but, here goes. Using the homomorphic properties of ElGamal, you could turn $E_{pk}(b_0),E_{pk}(b_1),E_{pk}(b_2),E_{pk}(b_3),E_{pk}(b_4),\cdots,E_{pk}(b_n)$ (where $b_i\in\{0,1\}$, i.e., individual bits), into $E_{pk}(b_0||b_1||\cdots||b_n)$ (where $||$ is concatenation). This is done by using homomorphic scalar ...


2

The real security of Vigenere is difficult to quantify. A million character plaintext with a 10 character password is easy to break. But a 10 character plaintext with a 10 character randomly chosen password is essentially a one-time-pad and theoretically unbreakable. Given the data you've told us (plaintext: 100 to 5000 characters; password: 30 to 100 ...


2

Eek! The Vigenere cipher is completely and totally insecure. You should never use it. Instead, use a modern authenticated encryption scheme. If you are protecting data in transit, I recommend using TLS (or SSL). If you are protecting data in storage, I recommend encrypting it with GPG (or PGP). This is the simplest, easiest way to get well-vetted ...


2

As @fgrieu mentioned, what you're after is FPE. The papers he linked deal with FPE on a very small domain, but it looks like you're interested in encrypting longer strings. For that, you need a wideblock cipher. Unlike traditional blockciphers, these typically allow different input lengths, which is a plus. They meet your criterion of not revealing shared ...


2

What you are looking for is a histogram plot. For example, the distribution of letters in the english language looks like this: The plot of a ciphertext from a strong cipher should have all bars about the same height (a fairly uniform distribution).


2

Yes it definitely is possible. For an example that is widely in use today, see bcrypt, a password hashing algorithm based on the blowfish cipher. To quote from wikipedia, Provos and Mazières took advantage of this, and took it further. They developed a new key setup algorithm for Blowfish, dubbing the resulting cipher "Eksblowfish" ("expensive key ...


2

Measuring the size of the key space in transposition algorithms is not important, because their security is far less than the size of the key space would suggest. Therefore, any measure of effective key length will be misleading and will not give an accurate picture of the true security of the scheme. In general the standard way to compute the effective ...



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