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....


29

...why go through the trouble of creating a cipher in the first place? Why not simply use a ridiculously long key, if you're gonna create a cipher that only takes as long as an exhaustive key search anyway? Designing a cipher is significantly less hassle then using a ridiculously long key. Designing a cipher only needs to be done once by a competent ...


23

A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly random”, then you don't have a one-time pad, you have a broken stream cipher. Concretely, if the nearly-...


23

Why is it a good practice to use only the first 16 bytes of a hash for encryption? As you noted, it isn't. But, the problem is not with the "16 bytes" part of the statement, or the concern for collisions. The problem is with the "hash" part. 16 bytes As stated in one of the links you shared, AES only uses key sizes of 128, 192, and 256 bits (or 16, 24, ...


22

We're not computers. We'd have to do calculations in our heads while talking about something other. There are quite a few parts of the brain active when we're talking, it would be tricky at best to put something in between. There is the notion of code talkers but those used their own language such as some of the Native American languages to communicate. ...


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.


19

Edit: I wrote the below on autopilot with the definition in the question. I have since realised an additional mistaken detail: the rule about no attacks better than key exhaustion is not called Kerckhoff's principle. Kerckhoff's principle is a related rule of cipher design that the key is the only component that can be relied upon to be secret. When you ...


19

The decompression of compressed-then-encrypted data is not possible without the decryption key, at least for compression and encryption schemes independent of each other. We can make a theoretical argument for that: compression schemes compress only a small portion of possible plaintexts (that happen to be the ones where compression is used in practice), and ...


18

Are all encryption algorithms with fixed-point free permutations inherently flawed? Yes - when fixed points, or the lack of them, is knowable and detectable. This is a violation of multiple modern semantic security definitions. For example, this means that plaintexts with repeating symbols are distinguishable with high probability from plaintexts that ...


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, ...


16

Are all encryption algorithms with fixed-point free permutations inherently flawed? No, they are not inherently flawed. Consider the following cipher: Let $k_0$ be a key for AES-256, and let $k_1$ be a key for a hypothetical Advanced Derangement Standard, ADS-256. To encrypt the $n^{\mathit{th}}$ message $m$, the ciphertext is $$c = m \oplus \bigl[\...


16

But advices received from partners and relatives encouraged me to experiment with the idea. I know that some schemes were patented in their beginning: DH, RSA, DES, NTRU, some schemes on ECC. Note that there is considerable reluctance in significant parts of the community to use any algorithm with any intellectual property claims. If you patent your ...


15

PKCS#1 v1.5 describes a method (formally known as RSAES-PKCS1-v1_5) that turns textbook RSA into a (heuristically) secure encryption scheme for small messages (PKCS#1 v1.5 also describes a signature scheme, which the question and this answer do not consider). For a $k$-byte ($8k-7$ to $8k$-bit) public modulus part of public key $(N,e)$, the message to be ...


12

It is the keypair that is doing the encrypting, not the one doing the decrypting, that the expiration date applies to. And yes, they will be able to decrypt it after one week. In fact, they will always be able to decrypt it. The expiration date only applies to the key and is nothing more than a gentle reminder that the key is supposed to be replaced and ...


12

RC2 RC2 is a 64-bit source-heavy unbalanced Feistel cipher with an 8 to 1024-bit key size, in steps of 8. The default key size is 64 bits. It was designed in 1987. It has a heterogenous round structure with a total of 18 rounds (16 "MIXING" rounds and 2 "MASHING" rounds). It is a complex cipher using secret indices to select key material. It performs ...


12

And in which case would it be more interesting to use one or another? So SHA3-$n$ offers $n$ bits of security against preimage and second-preimage attacks and $n/2$ bits of security against collision attacks. On the other side SHAKE-$n$ offers at $n$ bits of security against preimage and second-preimage attacks and also $n$ bits of security against ...


12

If you are unsure, then always choose Argon2id. Only choose Argon2d if you need maximum security at the expense of side-channel risk, and only choose Argon2i if side-channel attacks are the primary threat. The number of passes just increases resistance to time-memory tradeoff attacks (TMTO). What you are probably remembering is that Argon2i is more ...


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 ...


11

xoring the output of the cipher with the plaintext message Xoring the message into the ciphertext removes the ability to decrypt the ciphertext. If all you have is $k, c = E_k(m) \oplus m$, then you need to know $m$ in order to strip the external $m$ off of $E_k(m)$ before you can apply $m = D_k(E_k(m))$; Basically, you would need to know the message in ...


10

My question is... why? There are a number of different algorithms that perform $GF(2^{128})$ multiplication, all with different trade-offs (speed on specific platforms, program size, memory usage, complexity, side channel resistance, etc). NIST doesn't care which one you use, as long as you get the expected result at the end. As for why NIST decided to ...


10

The Structure of PKCS#1 v1.5 as follows; The message $m$ is padded to x = 0x00 || 0x02 || r || 0x00 || m and the ciphertext calculated as $c=x^e\bmod N$ not by $m^e\bmod N$, where $r$ is a random string. Cube root attack cannot be applied since the padding guarantees that messages are not short. The random $r$ make the encryption probabilistic so that ...


10

The Hill cipher is vulnerable to known-plaintext attack. Once the attacker gets $n$ plaintext/ciphertext pair it can break the cipher by solving a system of linear equations. Consider AES, it is not proved but considered secure against known-plaintext attack, see this question for details. And, also, key size itself doesn't represent the security. High key ...


10

We can't make satisfactory Electronic Voting Machines. Their design face conflicting goals that are impossible to reconcile, even in the simplest conceivable use case: a yes/no vote, a single machine. Count votes (or at least: determine if there was more yes than no) with the result public. Limit voting to one per registered voter. Keep individual votes ...


10

The one thing no one else has touched on is speed. Any cipher that you have to think about consciously will be too slow to be practical, and too easy to break to be effective. It would also be vulnerable to an eavesdropper writing down on pen and paper, and then cracking it later (not sure if that counts as recording). Ciphers like Rövarspråket and the B-...


10

It is possible with the old Pohlig-Hellman cipher. Here's how it works: The global parameter is a prime $p$ A secret key is a value $k$ which is relatively prime to $p-1$ To encrypt a message $M$, you compute $C = M^k \bmod p$, and that's you To decrypt a ciphertext $C$, you compute $k^{-1} \bmod p-1$, and then compute $M = C^{k^{-1}} \bmod p-1$ With this ...


9

Distilling your question down to these two salient points:- Why don't we use OTP in every case, what is the downside? leads directly to Why wouldn't everyone encrypt with a One Time Pad? and I won't add to the confusion, but that question might provide some insight. It also deals with the authentication /malleability issues. I have a stream of ...


9

Decryption process in CBC mode is performed as \begin{align} P_1 =& Dec_k(C_1) \oplus IV\\ P_i =& Dec_k(C_i) \oplus C_{i-1},\;\; 1 < i \leq nb, \end{align} where $nb$ is the number of blocks. If you know the position of the target byte, then you can modify the corresponding ciphertext position in the previous ciphertext block. For example; if you ...


9

Let's take AES-CBC for example—a typical cryptosystem that requires a randomized IV. Suppose I can predict the IV in advance. Then I can start by asking for the encryption of $\mathit{iv}_0$, which is $\operatorname{AES}_k(\mathit{iv}_0 \oplus \mathit{iv}_0) = \operatorname{AES}_k(0)$, and proceed by asking to be challenged on the messages $m_0 = \mathit{...


9

You say you want to decompress the data coming from A so B can do incremental backups and recovery. Were A's data not encrypted this would make perfect sense. But A's data is encrypted and that changes everything. Let's think this through. Let's say A compresses its data and then encrypts it. And let's say B could somehow decompress the data from A without ...


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