Tag Info

6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...

6

Plenty of ciphers come out of the USA from government research or selection competitions. AES and DES are examples. Indeed, the US is known from some crypto-related competitions that were/are ope to anyone and they surely will do ample of government research related to cyptology, but you need to be sure that you differ between “they selected it” and ...

6

The point of cryptography is having algorithms that are secure even when the attacker knows them. Google security by obscurity to see why it's bad. I'll add the following based on otus comment. Python can be reverse engineered, so you can't hide your algorithms. Basically, if someone can run your code, they can reverse engineer the algorithms. The point of ...

5

I think this would work, although whether it's practical is another matter. For large $x$ it won't be. It's basically an application of mental-poker. First, choose a secure commutative encryption algorithm that is not vulnerable to known plaintext or chosen ciphertext attacks. Everyone generates a random encryption key. Everyone but Alice uses their key ...

5

I'll assume that the plaintext consists entirely of capital ASCII letters as in the example. This implies the high 3 bits of each byte of plaintext are 010. It is useful to visualize how 3 consecutive bytes of plaintext map to 4 consecutive Base64 characters. 1. Frequency analysis of the last character of 4-char blocks in ciphertext We see there is a ...

5

XSalsa20 uses the same cryptographic core as Salsa20 and comes with a security proof that it's secure if Salsa20 is secure. It doesn't use the core of ChaCha and thus has worse diffusion. The way XSalsa20 works is that it hashes its 256 bit key and the first 128 bits of the nonce using HSalsa down to a 256 bit key and then uses that key together with the ...

4

You are actually doing the right thing, however you do not include the "_" as part of the characterset. Assuming the alphabet consists of 27 letters (A-Z and "_"), and using the appended JavaScript script (you can simply paste it into the console), returns one sentence which actually does make sense: THE_FAILURE_MAY_BE_BOTH_DELIBERATE_AND_CLANDESTINE var ...

4

The permutations in your question are given in Cauchy's two-line notation, where the upper line gives the input index to the permutation function, and the lower line gives the resulting permuted index. For example, the definition $$\sigma = {1\ 2\ 3 \choose 3\ 1\ 2}$$ means the same as $$\sigma(1) = 3,\quad \sigma(2) = 1,\quad \sigma(3) = 2.$$ Thus, if we ...

4

I'd treat your input as one 192 bit input instead of thinking about 5 separate inputs. If you don't need security, you can always reduce the number of rounds of cryptographic primitives. If you merely need statistically random output, 20% of the usual number of rounds should be fine with many hashes. A few suggestions: SipHash has good performance for ...

3

What you're looking for is that zero knowledge proof, that some public number is not equal to a couple of secret numbers. It is possible to prove that two numbers are not equal, but it is not that easy to do so, and it is mostly theoretic work. Let's consider two integers $a$ and $b$ for simplicity and prove their inequality: Consider the numbers in their ...

3

Here is a quick idea that came to mind: $n$ be the number of participants. Let $p := 0.5 / n$. Have every participant choose a number not equal to his own, and announce it publicly. After all the numbers were announced, each participant answers with no, if one of the announced numbers match their private one or if a random Bernoulli experiment with sucess ...

3

Since you encrypt just a single letter, there are $26^2$ combinations of $p$ and $c$ where $c=E(p)$. This is because there are $26$ possible shift keys in the key space, an therefore each $p$ can be mapped to one of $26$ letters in the code space. Now, assuming that the key is distributed uniformly in the key space, each of those combinations of $(p,c)$ has ...

3

What is the significance of the repetition? Does it mean that a 6 character key was used and repeated across the same characters within $P_1$ and $P_2$? I'm assuming your assumption about this being an xor cipher with the pad used twice for two ciphertexts. It does not mean a 6 character key was used. A one time pad used twice could result in this ...

3

If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ...

3

$ROT(n)$ can be thought of as a character based stream cipher. It works because addition - the encryption method used - is commutative, i.e. $ROT(x, ROT(y, m)) = ROT(y, ROT(x, m))$. Another well known commutative function is $XOR$. It is used by the one time pad, but - more practically - also for block ciphers in streaming mode. So you can encrypt using AES ...

3

Permutation A “P-box” is a permutation of all the bits, meaning: it takes the outputs of all the S-boxes of one round, permutes the bits, and then feeds them into the S-boxes of the next round. A good P-box has the property that the output bits of any S-box are distributed to as many S-box inputs as possible. Substitution An “S-box” is usually not ...

3

Compared to fixed rotations, data-dependent rotations improve resistance to differential and linear cryptanalysis. A fixed rotation has no effect (beyond helping with diffusion) in the probability of a (xor-)differential characteristic, whereas a data-dependent rotation also introduces differences in the rotation amounts, which brings probabilities down. ...

2

Worth reading: Can I use HMAC-SHA1 in counter mode to make a stream cipher? This is basically the same construction with the difference that you don't call it counter mode and don't assume a specific hash function. However, you should read both answers to that topic, because the second one (0 upvotes, not the accepted answer) has a very reasonable quote ...

2

This somewhat reminds me of “How do I test my encryption?” but that question was more specific than this one, which seems to be too broad in it’s current state. Nevertheless, there’s an easy answer to your question: Check and verify all the security aspects you target with your cipher. When done, simply respect Kerckhoffs' principle and make your cipher ...

2

This question boils down to, "Are there known-plaintext attacks against AES-256-CBC?" The answer is: No, no such attacks better than brute force are known. This would constitute a catastrophic break in AES-256-CBC, and any cipher broken in such a way would be abandoned rapidly.

2

It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ...

2

I think frequency analysis is the preferred approach for breaking substitution ciphers. The more ciphertext you have, the better it is. My suggestion would be to do the following: First, you compute two probability distributions: a distribution that contains the probability of the symbols in a reference text of the same language and technical area than ...

2

Yes, this should be solvable and should be doable in a reasonable amount of computation time, using a pretty cool homomorphic cryptosystem. Here is one approach: the participants jointly pick a random number $y$, publicly commit to $y$, and then they all prove/check in zero knowledge that $y$ is different from their numbers. If it isn't, they go back to ...

2

The standard random number generator, in languages like Java or Python, does not generate real random numbers but pseudorandom numbers determined by an initial seed value. If an attacker can somehow guess or determine this seed value, they can reconstruct the entire sequence of pseudorandom outputs. Furthermore, the default pseudorandom number generators ...

2

You should not just "pick the highest frequency character and assume it should be E" because it will probably fail most of the time, except if your ciphertext is really long. If your alphabet is small enough (usually either 26 or 255), it would be wiser to try all the possibilities for each group, and to check if the output looks like real english ...

2

Python is a scripting language, so if you've got the program, you usually also have the source code. So you don't even have to reverse-engineer. That doesn't matter much for two reasons: other languages are pretty easy to reverse engineer (or they are complex for both the programmer and the attacker); the algorithm does not have to be kept safe anyway, due ...

2

The encryption is weak This encryption is more susceptible to frequency analysis than original "substitution ciphers" because the frequency tables should be much more Non-uniform. In my opinion, it should be less secure than substitution cipher although the key space is much much bigger (compare $64!$ to $26!$). Some evidences of the weakness If I assume ...

1

This would usually I think be more suited as a comment, but you were looking for guidance instead of a complete answer as it were, and I don't have enough reputation to comment. I'd highly recommend Claude Shannon's introduction (the literal introduction, he developed the concept) to the question you pose. Here’s the paper (PDF) and the section is Part 10 ...

1

I guess because because foo.txt has a lot of redundancy and thus can be quite significantly compressed. Consequently, the compressed file foo.txt.zip is much smaller (you should take a look at data compression).

1

To answer the question "why does a block cipher use a Mode of Operation", we need to first examine the question "what is a block cipher?" A block cipher is a keyed operation that converts a string of N bits to a string of N bits (where N is usually fixed by the block cipher; for AES, N=128), in a way that, without the key, looks like a random permutation, ...

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