Tag Info

22

If the substitution ciphers belong to the same family, then their composition will also (typically, assuming that the family is closed under composition) belong to the same family. Thus, breaking the combined cipher will be no harder than breaking an arbitrary cipher in the family. For a simple example, combining two Caesar shift ciphers with shifts ...

14

Your punctuation is slightly off: What's in a name? A rose by any other name would smell as sweet. It's a reference to Romeo and Juliet

11

A quick search turns up a quote of Shakespeare from Romeo & Julia. It is often a good idea to simply search the internet, even for (smallish) hexadecimal values or values encoded as base 64. In general it can be expected that decryption has succeeded if the attacker gets English text without invalid words. Words are usually not encrypted separately, so ...

8

The "hard part" about GCM implementation is resistance to side-channel attacks, especially cached-based. GCM is the combination of AES-CTR, and a custom MAC that relies on multiplications in a binary field (GF(2128)). Efficient implementation of that operation classically uses tables, which can lead to cache-timing attacks because the accessed table slots ...

6

It is not possible to reverse-engineer a good encryption algorithm from plaintext/ciphertext pairs alone; it might not even be possible to test the validity of a guess unless a matching key is known (but it is often possible to rule out a guess; e.g. if individual cryptograms are 64 bytes, that's not RSA with a decent key size). Among techniques to ...

6

In my own knowledge, encrypted data can't be decrypted without knowing the key, but BitLocker breaks it. That description indicates you might have misunderstood something there. Bitlocker does not break anything* as Microsoft BitLocker uses recovery keys (read again: “keys”), not code! The related code for recovery is pretty similar to the usual ...

5

Well, that's simple: $2^{64}/2^{30}$ is indeed correct. And since $2^{64}/2^{30} = 2^{64 - 30} = 2^{34}$ then that would be the answer. A simple recalculation would give you approximately 545 years. As you can see, 64 bits is pretty much on the border of being cracked by general computers. Brute force basically scales linearly with the amount of keys. ...

5

No, A is not true. Suppose that $G_1$ is a secure PRG and $G_2(s) = G_1(s) \oplus 1$, obviously $G_2 \neq G_1$ and $G_2$ is a secure PRG. You can see that $G(s) = G_1(s) \oplus G_2(s) = G_1(s) \oplus G_1(s) \oplus 1 = 1$ which is obviously not a secure PRG. Now you have a hint. You should think the rest of the problems.

4

The composition of any number of substitution ciphers is still a substitution cipher, hence no.

4

If the value $x$ is in the set $\{0, 1, 2, .., p-1\}$, which is the "natural" set of residues moduli $p$, then, you just have to check if $x$ is greater than $\frac{p}{2}$ and if so, subtract $p$. If $x$ does not belong to $\{0, 1, 2, .., p-1\}$, then you can first do the usual modular reduction to transform $x$ in a element of this set and then, do the ...

4

Does such an entity exist? No, not really. There isn't any organizations who's in the business of doing public cryptanalysis, and there certainly aren't any organizations that are sufficiently trusted for the cryptographical community to say "we know algorithm X is secure - organization Y said so". Let's go through the likely suspects: NSA (and ...

4

Basically, this part of the paper aims at proving that, as long as the approximate GCD problem is hard, the DGHV scheme is "secure". So, as it is standard in reduction proofs, you go and prove the contrapositive: you show that if there exists an adversary $\mathcal{A}$ that is able to break the DGHV scheme, then there exist an adversary $\mathcal{B}$ that ...

4

No, it is not possible to semi-reliably "decrypt" an encrypted message by using the statistical distribution of symbols, if some modern encryption scheme is used, and its secret/private key does not leak. Modern encryption is practically immune to known distribution or other characteristic in the plaintext. The goal of modern encryption, that it reaches in ...

3

There are some works both theoretical and practical that they do solve your problem efficiently and in a secure way. By efficiently i mean the search efficiency is linear on the size of the searched substring. This is achieved by using auxiliary data structures known as suffix tree. Chase and Shen follow this approach, by encrypting the suffix tree with ...

3

I am afraid you are a little early: searchable encryption is quite a new field in cryptography, and I am not sure there exists any good implementation yet. However, answers to this question suggest cryptdb Also, I do not think the Rabin-Karp Algorithm is easily transposable to searchable encryption. I believe it has many optimisations, which could conflict ...

3

I will give you the simplified answer. The public key encryption does not prevent adversery from computing private key from public key. It just makes it very very very hard. The algorithms use math that allows simple private->public calculation, but public->private has no good mathematical "shortcuts". It would take adversery more time to calculate this, ...

3

In general you want to treat primitives like block ciphers as black boxes. You first analyze and try to break the block cipher. Once it is proven to operate correctly you can use it as primitive for a block cipher mode of operation. The mode of operation can then be proven to be secure assuming that the block cipher primitive operates well. If you don't ...

3

Xor-ing the first half of the encrypted message with the second gives the same result as xor-ing the first and second half of the original message. (When the key is duplicated). This contradicts perfect secrecy as some information can be obtained from the cyphertext.

3

So my question is, if they are the ones who encrypt this, then why can't they also decrypt it? Because it’s not them encrypting your message, it’s the App on your device… which is why it’s called End-To-End encryption. According to the security whitepaper (PDF), WhatsApp uses the Noise Protocol Framework which is based on the Signal protocol (formerly ...

2

I doubt something like this exists, because it would be more or less equivalent to having some internal block cipher in a non-standard mode of operation. Also, changing keys is to be avoided when designing high-performance primitives, because it's pretty slow in most modern ciphers. You'd need a weird cipher that had really high key agility, but then you'd ...

2

Jean-François Gagnon's answer is fine and would serve as an obvious proof that this scheme does not provide perfect secrecy. Now the fault in your thought process is actually that an attacker doesn't know that the key is "copied". This is a simple form of a key schedule which is assumed to be known to the attacker along with the encryption and decryption ...

2

No, you're not weakening your data in that case. You could even use ECB in to encrypt random data. Symmetric key wrapping often just uses ECB. But beware that it depends on how many bytes you encrypt. You may want to make sure all bytes are random (if you know the plaintext size in advance). Think about encrypting a single random byte and filling the rest ...

2

There are different arguments going on and there is some context guessing involved on part. The argument to stay using CTR+HMAC seems to be, basically: Never change a running system (without the need to). The security of CTR+HMAC is fine per se. If you have a good, working implementation and the computatational complexity is not biting you, you ...

2

I'll assume R is secret, and is the key; and the ciphertext is given as a list of values x in decimal, as in the example given x = 0.559425856. This is totally insecure: even without knowledge of R, it is trivial to reduce candidate plaintext letters to almost nothing, just by knowing the corresponding x. e.g. if we assume R is an integer in range ...

2

You should read this article about Security of DGHV Encryption. Oracle machine is an abstract machine used to study decision problems. It can be visualized as a Turing machine with a black box, called an oracle, which is able to decide certain decision problems in a single operation. The problem can be of any complexity class. Even undecidable problems, ...

2

I would not consider your case to be a cascading encryption. The reason why is the fact you need multiple interventions before getting access to your file. Here is what I would consider a cascading encryption (let's go crazy) : $$E(k_1,k_2,k_3,m) = \text{KEYAK}(k_1,\text{NORX}(k_2,\text{AES}(k_3,m)))$$ which you would decipher with : ...

2

If you ask about the protocol itself, as a theoretical construct, then it is safe. In theory it indeed provides all the feature that it promises. And now for the "but..." part. When you use a protocol to communicate, you are actually using one implementation of the protocol. The implementation tries to do exactly what the protocol says. However you can ...

2

Scheme is not IND-CPA for any message longer than one block. I'll include a image of CBC mode below for reference (Source: Wikipedia). Suppose instead of block cipher encryption we have plaintext xor-ed with the key as you propose. You'll note that for message block 1, $M_1$, the ciphertext block $C_1 = M_1 \oplus IV \oplus Key$. Similarly \$C_2 = M_2 ...

1

This depends on the level of authenticity you want to provide with your system. A lot of public petition systems do not enforce authenticity of petitioners at all. Basically, anyone can submit a petition in behalf of their neighbor, for example, simply by introducing relatively public info about them (name, address, ID number, etc). In this case, public-key ...

1

Yes, GPG (a.k.a. PGP) or S/MIME. For additional security, you may also want to use a PGP smartcard and generate your encryption keys in the PGP smartcard. This way, even you don't know your own private key and can't accidentally leak your private key. The only way to leak private key with PGP smartcard is if you lose your card or if there's a vulnerability ...

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