50

Encryption algorithms and hash algorithms both belong to the realm of cryptography but are two different things: Encryption doesn't contain hash functions. As stated on Wikipedia: In cryptography, encryption is the process of encoding a message or information in such a way that only authorized parties can access it and those who are not authorized cannot....


20

Encryption implies that with the appropriate key, it is possible to decrypt and recover the original message. Which (in general) is not possible from a hash. Thus “I will encrypt” is not adequate if one is going to hash. While it is possible to construct hashes from encryption primitives (such as block ciphers), and vice versa, they are different beasts.


18

The best solution is out of scope for this website. Just apply an algorithm that converts binary data to human-readable pronounceable text. A simple solution, much like base-64 or diceware, would be to download a dictionary, split binary ciphertext into chunk, and replace each chunk by selecting the nth word in the dictionary. Join the words together using ...


17

The existence of a family of collision resistant compressing functions does indeed imply the existence of CPA secure, CCA secure and even authenticated encryption. This follows from several classic results in cryptography. A family of collision resistant compressing functions is also a family of one-way functions. By the seminal work of Håstad, Impagliazzo, ...


12

I understand that it gives the wrong impression, but I think it is not absolutely wrong, or is it? It is actually. A hash algorithm computes a 'fingerprint' if you will of the input. So just as a fingerprint identifies you, a hash identifies the input document. But just as an entire human being cannot be recreated from just a fingerprint, so the original ...


6

No, If we assume that the mythical computer can brute force the multiple AES encryptions and there are many ciphertexts available which are encrypted under the same key and their corresponding plaintext are not random. The brute-force code can keep track of the meaningful plaintexts for each ciphertext and finally can perform an intersection of possible key ...


5

One possible way to calculate the inner product is by using fully homomorphic encryption schemes. First, you encrypt each vector $$x = (x_1,x_2,\ldots,x_n), \quad y = (y_1,y_2,\ldots,y_n)$$ with your public key $$X = Enc_{pub}(x) \text{ and } Y = Enc_{pub}(y)$$ where $$X = (X_1,X_2,\ldots,X_n), \quad Y = (Y_1,Y_2,\ldots,Y_n)$$ and $$X_i = Enc_{pub}(x_i) \...


4

I don't know of any tools that do what you want, and so likely you'll need to develop something on your own. I assume you want to take a plaintext and generate a 'ciphertext' which is effectively undecipherable (unless you know the key), and looks sort of like text in some unknown language (after some unspecified level of inspection - fooling an experienced ...


4

Well, as often when it comes to "practical security", the answer is: it depends. First things first, there is nothing special about the keys or the way the maths in X25519 works that would make the one or the other more secure: publishing many public keys will not significantly ease the process of recovering any single secret key, although each new key ...


4

Generally for forward secrecy you should not just limit the use of the private key (and thus public key) in time, but also per connection. For that reason, you can assume that in most implementations that require forward secrecy that there will be one ephemeral key pair per connection, not per time frame. Similarly, you're assuming that a new key pair is ...


4

Yes, the one-time pad model provides the technical notion of IND-CPA security. An adversary's advantage at the IND-CPA game is zero if the pad is uniform random. This is a standard—and, once you get past the definitions, trivial!—lemma on the way to proving an IND-CPA security theorem for a practical stream cipher like Salsa20 or AES-CTR. Of course, real-...


4

I'd split the key into two 256 bit keys using HKDF, and use one key for the GCM mode, and the other for the hash over the plaintext. However, I then would use HMAC rather than SHA-256 as it accepts and the key as a separate entity in the application. The advantages of the HKDF key derivation function is that there is more "distance" between the keys used ...


4

Theoretically-speaking, yes: (collision-resistant) hash functions imply* one-way functions (OWF), and therefore they also can be used to build symmetric primitives using the chain of reductions from OWF to PRGs (pseudo-random generators) to PRFs (pseudo-random functions) and finally to PRPs (pseudo-random permutations) or block ciphers (cf. this answer). *...


4

I realize in ChaCha20 the nonce should be random and unique each time… Nope! For the ChaCha stream cipher, it is not safe to choose the nonce at random. At 64 bits long, the ChaCha nonce is too short to be chosen at random. In general, you should use a sequential message number under any single key as the nonce. For the XChaCha variant, like the ...


3

The point is not to make the attack infeasible time-wise. Computational resources (usually, area*time, which is roughly a measure of the monetary cost) needed for the attack is the only thing you can hope to increase here. As you observed, it is always possible to parallelize brute-force search of passwords, so the best you can do is increase the ...


3

Vigenère Cipher Let's look at some different attacks on the Vigenère cipher and determine how much of a role alphabet size plays. From Wikipedia: The primary weakness of the Vigenère cipher is the repeating nature of its key. If a cryptanalyst correctly guesses the key's length, the cipher text can be treated as interwoven Caesar ciphers, which can ...


3

Actually the idea proposed by SEJPM in the comment to use functional encryption is probably the simplest way if you want the third party doing the inner product computation to learn the actual result and not simply the encrypted result. There have been multiple papers about inner product functional encryption schemes in the last few years, but let me first ...


3

Yes, you could use the HKDF-expand function to expand the bits of the key to a certain size and then use HKDF-extract to derive a key from it again. Note that the resulting key is not identical to the key you've started with. You can use the HKDF-expand again to derive one or more multiple keys with any size from the extracted key material. HKDF internally ...


2

One of the features of a good encryption is that the cipher text should be indistinguishable from pseudo random. That means that it'll look like output from a good random number generator. Since there are only 256 possible values for any byte, of course they will repeat if you've got 300 million of them. Repeats tend to occur at the rate of $1 \over 256^n$ ...


2

If the third party is a trusted one, and also we have a key manageing center(KMC), the KMC first generate two random matrix $A$, $B$ and a invertable matrix $M$. Then it calculates the re-encryption key: $$R_A = A^{-1}M$$$$R_B = B^{-1}M$$when the owner of $x$ receving A, compute: $$A'=A^Tx$$ send $A'$ to the third party. When the owner of $y$ recieving $B$, ...


2

When you cascade two ciphers with independent keys, $E_{k_1,k_2}\colon x \mapsto \operatorname{AES}_{k_2}(\operatorname{AES}_{k_1}(x))$, the intelligent adversary will use a parallel collision search for a meet-in-the-middle attack at far less than $2^{128}$ or $2^{256}$ times the cost of a search for $k_1$ or $k_2$ alone. So this technique doesn't improve ...


2

For example when I encrypt message A with key K and it outputs B, can somehow A and B be put together, so it will output K? Except for encryption messages where you are specifically restricted to use a specifc key K only once (e.g. OTP), then no, it is infeasible to recover K from A and B. This is a fairly fundamental requirement on encryption methods (...


2

The Paillier cryptosystem allows to encrypt integers modulo $n$. Therefore, if $m$ is bigger than $n$, encrypting it will lose most of the message - only $m \bmod n$ is retrieved through decryption. To encrypt a message bigger than $n$, you must break it into blocks, which you encrypt separately. You can for example write $m$ in base $n$, as $m = \sum_i m_i ...


2

It is easy. For example: Take first 256 words from the language dictionary, like Oxford dictionary or Merriam-Webster dictionary, and for each byte of your encrypted message use a word with corresponding number. Or take first 65536 words from the dictionary and replace each 2 bytes with corresponding word. Or take each encrypted byte. Add a random multiple ...


2

This is actually slightly less secure than ordinary Vigenère encryption with a small modulus. In particular, all the traditional methods for breaking Vigenère encryption work just as well (or better) with a large modulus: The key length can still be determined by calculating the index of coincidence and/or via Kasiski examination. If the key is ...


2

No, because in order to decrypt it you must pass along the SHA-256 hash too, and now you have leaked a public function of the original message, which an adversary can use to efficiently test a guess offline about what the original message was. If you want a deterministic authenticated cipher, you might consider an existing construction like SIV that has ...


2

No, when an IV is repeated as in $C_1 = \textsf{GCM}(K,IV,M_1)$ and $C_2 = \textsf{GCM}(K,IV,M_2)$, the resulting ciphertexts leak $M_1 \oplus M_2$ to an eavesdropper. This is because GCM is based on CTR mode which has this property. Authenticity also completely breaks in this scenario, although it's not a one-liner explanation. An attacker who sees $M_1, ...


2

The first scheme is similar to what's called Encrypt-and-MAC. It is not ideal, but it is not fatally broken, and it is still used by the SSH protocol securely. You need to include a counter or other unique value in the data being MACed to maintain IND-CPA security (i.e. identical plaintexts don't have identical MACs). The second scheme you present doesn't ...


2

I agree with other answers, but would like to add this: when talking to someone familiar with cryptography or fields using it (e.g. programming), you should indeed use the right vocabulary. But if you try to summarize what you are doing to a client, I would use neither and say something like "we store our password in a secure way" and eventually provide ...


2

You can't. If the user can run the software, they can extract the key from it. There is research on how to make it difficult to extract the key (white box cryptography), but it's not very successful. You need to think about what do you want to accomplish. Does the user encrypt the files to themselves, so that they can decrypt it later? Then you could derive ...


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