Tag Info

Hot answers tagged

5

Yes, $E$ will be always be secure. This follows from a standard type of proof called a hybrid argument. Giving the full details would be tedious, so here is a sketch in case you are familiar with hybrid arguments: We define games $H_0,H_1,H_2$. We let $H_0$ be the IND-CPA game, but with the game's secret bit hardcoded to $0$. So the game always outputs ...


5

First, remark that the desired commutativity is incompatible with security under Chosen Plaintext Attack, which (under the name IND-CPA) is considered a requirement for modern encryption systems. Proof, expanded following tylo's comment, using the IND-CPA game as played for symmetric encryption (see the CPA indistinguishability experiment in section 3.5 of ...


4

Timelock puzzles solve this problem. For instance, consider the function $f(x) = x^{2^t} \bmod n$, where $n$ is a RSA modulus and $t$ is large. For people who don't know the factorization of $n$, computing $f$ takes $t$ squarings modulo $n$. If you do know the factorization of $n$ (the private key), then computing $f$ can be done with $O(\lg n)$ ...


4

Theoretically, there are several ways to turn a hash function into an encryption system. However, the Devil is in the details. A cryptographic hash function is a function which is resistant to preimages, second preimages, and collisions. As far as I know, it has not been proven that these conditions are sufficient to build a stream cipher. In fact, what we ...


4

There is no risk if the attacker knows part of the plaintext. This doesn't help to recover the rest of the plaintext. Even if the attacker knows all the bits but one, with any decent encryption algorithm, the attacker cannot tell what the last bit is from the ciphertext. After all, it happens all the time with known data formats. For example, if you ...


4

As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant. As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and ...


3

From RFC 4880 - Open PGP Message Format (emphasis added) OpenPGP implementations SHOULD compress the message after applying the signature but before encryption. As the signature provides authentication, and you specifically ask about authentication, I think that quote from the RFC should answer your question. Compression does not affect ...


3

Does re-encrypting the same value with multiple keys reduce security? The answer is "it depends"; there are some attack models and encryption methods where the security is reduced, there are other cases where there appears to be no security reduction. Let us go through some models where we actually see a security reduction: Plaintext guessing attack ...


3

I am using chunks of 1MB and give them a GUID as filename That is fine although unnecessary, the entire input file can be encrypted. These chunks are then first compresses using DEFLATE to minimize attacks based on known Content VERY BAD idea, since you are breaking the input file into pieces, you are now exposing the entropy of specific file ...


3

Sure. Encrypt John's private key under Adam, Emily, and Scott's public key. When you revoke Emily and change John's keypair, encrypt John's new private key under Adam and Scott's public key. If Adam or Scott need access, they can decrypt. After the key change they will still have access and still be able to decrypt it, same as they were able to before.


2

Read about the CRIME and BREACH attacks. They are the classic example where compression before encryption can leak information about the input. The length of the compressed data leaks information about the contents of the data itself. See also http://security.stackexchange.com/q/19911/971 and http://security.stackexchange.com/q/20406/971 and ...


2

There are arguments for both sides: Yes, you can. In Feistel networks, the $F$ function is always evaluated in the same direction, not need for inversion. Similar constructions work as well. Or just XOR a hash value to your message (like in a stream cipher, but block-wise), and make the hash value dependent on the key (and any other input of your choice). ...


2

No. These codes are not secure. They are not secure against a known-plaintext attack or chosen-plaintext attack, if the cryptanalyst has enough known/chosen text. Nowhere does the paper claim that these codes are secure enough for practical use. It appears that the paper looks only at ciphertext-only attacks, but security against ciphertext-only attacks ...


2

TLS does not support any cipher suite combination with a symmetric key size larger than 256 bits. Asymmetric key sizes are available up to 15360 bits, which correspond to a 256-bit symmetric security level. RFC5246 lists the available cipher suite combinations for TLS 1.2 It should be noted that the symmetric security of TLS is not the weak point, and ...


2

There are no known dangers or attacks from this construction. I agree with the quote from the TAHOE-LFS paper. I would find it quite surprising if this use of the key material introduced some special weakness. I can't prove it, but based upon my professional judgement, this is probably far from the biggest risk to your security -- it is very unlikely that ...


2

Unless you are absolutely sure that you don't need to and that the cost is going to be significant then I would absolutely say you should use authenticated encryption. One reason is bit-flipping attacks - flipping a few bits at the 'right' point in your encrypted message might lead well to a message that is legal (the classic example is if someone learns ...


2

For simple XOR-based encryption algorithms such as OTP, the key size must be the same as the message size. If you choose a smaller key and try to divide the message into chunks, you would not have a perfectly secure scheme anymore. Now, since you tagged java, I'm assuming that this increase in time for smaller key sizes is due to the code trying to divide ...


1

I don't know if it has a name, but I can tell you that it is a bad idea. A very bad one. The only thing I have to do to break the encryption is to try all the possible combinations of 4 bytes in the total 24 byte string. Intuition may tell some people that there are many combinations, but really? How many combinations are possible? The answer is 255024. This ...


1

I found the paper. At a glance, this seems to be a solution in search of a problem. Unless I've missed something, there is essentially no attempt in their paper to cryptanalyze such a construct. Nor do they appear to build upon, relate to, or even reference any preexisting concepts in modern cryptography or information theory such as computational ...


1

I guess the problem is to find the generator $g$. Denote the factors for $p-1$ to be $p_1 =2, p_2 =2,p_3 = 37, p_4 = 709$. With $p$, and the factorization of $\phi(p)$ you can find a generator in the following way: Randomly choose an element $x$ from $Z_p$ and test whether $x^{\phi(p)/p_i}$ mod $p \ne 1$ for every $i =1,2,3,4$. If this is the case, $x$ is ...


1

SHORT: The key remains the same. CBC mode is one of the ways which allow block cipher to securely process multi block input. Block cipher with single key produces same output for same input, as it is relatively common for input to contain duplicate blocks, instead of using block cipher as is, a more complex construct is needed. The idea of CBC mode is ...


1

In "Applied Cryptography" by Bruce Schneier, section 14.11, “Using One-Way Hash Functions”, he shows how to use a hash function as a block cipher in CFB mode: $$ C_i = p_i \oplus H(k || C_{i-1}) \\ P_i = Ci \oplus H(k || C_{i-1}) $$ Schneier continues: The security of this scheme depends on the security of the one-way hash function...While these ...


1

The problem is not with compression and encryption, it is with the protocol that is being used, and the type of data being compressed (or not) prior to encryption. The most damning leaks are on protocols that were either designed to be compressed without encryption, or encrypted without compression. The best example I have is VOIP systems that use a ...


1

From my recent experience, it's not always compatible. Using the latest version of GnuPG and Symantec PGP, I was able to confirm at least the fact that a 16384-bit RSA key pair (with 4096-bit subkeys) generated in GnuPG will not be usable in Symantec PGP. All of the cipher, hash algorithm, and compression preferences will be displayed as none, the expiry ...


1

Alice must send enough data for both Mocking Jay and The Hobbit. But there may be a plausible reason for all that data. Alice encrypts Mocking Jay using a method that produces ciphertext indistinguishable from random. Alice appends random data to that ciphertext to bring it to the length of The Hobbit (presumed at least as long as Mocking Jay). Alice sends ...


1

Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom. He also demonstrates two attacks which are possible because of trying to ...



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