Hot answers tagged cipher
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
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 ...
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
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 ...
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
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
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
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
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.
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
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
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 ...
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
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
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
given that the permutation is fixed and the key step is independent of the permutation you can reduce this to an ordinary text-substitution cipher
if the key is as long as the input you have a weak one-time pad (because the per letter change is limited to 10 instead of 26)
however if the key is short then you have a vignere cipher (if you "decode" with ...
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 ...
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
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 ...
1
One time pad is definitely both easy to do and has perfect secrecy, but key management is a pain and can compromise security. Basically a Vigenère cipher with a key as long as the the message should be secure, because different keys can create ALL possible messages with equal probabilities.
Again, it's a one time pad, so no KPA, CPA, or CCA security. ...
1
RSA is slow to get a decent security... AKA 2048-bit or more.
Well, if you want to be ultra-paranoid, then you'll have to accept some trade-offs. Suffice to say, a one-time 2048-bit RSA key-exchange shouldn't eat up too much processing time.
Using SSL is the most reliable way to exchange information securely; it not only takes care of the ...
1
Sticking to monoalphabetic ciphers, Vigenere can be combined with a secret random-like substitution of the plaintext or/and ciphertext alphabet, making it significantly more resistant.
If Vigenere encryption is
$$x_j\mapsto (x_j+K[j\bmod k])\bmod{26}$$
where array $K$ is the key or length $k$, I'm discussing
$$x_j\mapsto (S[x_j]+K[j\bmod k])\bmod{26}$$
...
1
For Vigenère specifically, you can make it harder to break by increasing the size of the key and by making the key truly random. If the key is truly random, longer than the plaintext and never reused, then Vigenère becomes equivalent to a One Time Pad.
Even without going that far, it is possible to strengthen many, though not all, cyphers by lengthening ...
1
If it is okay for the recipients to know that the message was send to at least n people, you can do this:
Create a temporary key/password that is only valid for this message alone. Then use it to encrypt the message.
Encrypt the temporary key/password with the password of each recipient.
Stick the list in front of the encrypted messages.
The recipient ...
1
I'm a bit confused, because the title of your question seemed to imply a different scenario than your actual question.
Is your goal, given one message $m$ to produce ciphertexts $c_1, \ldots, c_n$ such that each recipient can decrypt one of the ciphertexts but not check whether the other ciphertexts encrypt the same message?
This can be achieved using any ...
Only top voted, non community-wiki answers of a minimum length are eligible
