17

When there is no known weakness in the hash function we talk about their generic1 resistances Pre-image resistant: given a hash value $h$ find a message $m$ such that $h=Hash(m)$. E.g., consider storing the hashes of passwords on the server. An attacker will try to find a valid password to your account. Second Pre-image resistant: given a message $m_1$ is ...


9

A n-bit hash can be brute forced $O(2^n)$ operations. If you run the numbers, you find that a 256-bit hash is completely immune to brute force attacks. $2^{256}$ is so large that it would literally take a good chunk of the available energy in our galaxy to break it. So in that sense, they are both "completely secure against brute force." However,...


6

I think the most simple ciphers that are available are stream ciphers. Of course there are secure and non-secure stream ciphers. But e.g. LFSR's based ciphers are pretty easy to understand, and generally you just have to deal with bitops and basic possibly (modulo) addition. Those operations are generally easy to perform "by hand". Of course, to ...


5

With this in mind, one would obviously want a cipher that is mathematically provable to be resistant to KPA. Any scheme that has a message space larger than the key space and is unconditionally provably resistant against known-plaintext attacks while being efficiently computable immediately implies $P\neq NP$. As we don't know for sure whether $P\neq NP$ ...


4

When combined with your comments, I can say this is unsafe in the sense that it is highly advised against "rolling your own encryption." It looks to me like you are layering multiple encryption methods together without too great of a concern for understanding the attacks made against them. Is this secure? Maybe. In theory, we designed these ...


4

Why don't most encryption algorithms use perfect secrecy? Perfect secrecy can only achievable if the $\text{key size} \geq \text{message size}$ and the key is never re-used. It is not suitable for modern usage, where a lot of messages are sent/received and that is impractical since one has to send the key beforehand in a secure channel and this is not ...


4

How would one go about constructing such a cipher? Has it been done? Can it be done? If you have a key which is at least as long as the message (and don't reuse the key to encrypt a second message), we know how to do that (and it isn't that hard). Other than that, no, we don't know how to do it; we don't even know that it can be done. The closest we can ...


3

I would say MiMC is the simplest block cipher with plausible security. The idea is to cube the state, add a random constant, and repeat. This is typically done in a large prime field, but it is trivial to implement field arithmetic in any language with big integer support. Here's a Python implementation: def mimc(x, p, k, constants): x = (x + k) % p ...


3

The one time pad technically meets all your criteria and I think it's the simplest. It gets used all the time within encryption schemes where it's usually called blinding. Otherwise I would look into small block ciphers. For example, RC5 and skip32. These are probably the simplest beside the OTP.


3

A third possible reason one might do this is to allow quick erasure. Suppose you want to securely delete Text1, that is, make sure that no one, not you, not a hacker, not the TLA that gains access to the computer, can possibly recover it. Now, E(Text1) may be lengthy, and scrubbing it from the files may take more time than we would care to take (and we ...


3

If the ciphertext is the same size as the plaintext, then yes with 100% probability. There are only finitely many values the ciphertext can take. So repeatedly encrypting the ciphertext, means that a value must repeat eventually. If this cycle doesn't include the original message, then there is some ciphertext that has an ambiguous decryption (because two ...


2

It sounds like you're looking to implement something very similar to what was asked about here, with the addition of a signature of the ephemeral public key. But as poncho's answer points out, the potential malleability of the XORed key and the ciphertext could potentially pose some problems. The way the shared secret is derived may also introduce the ...


2

Hint: $\text{bytes_to_long}(\text{m_dash})^3 < n$


2

The function to calculate a MAC takes a message and a key, and outputs a tag. To verify a MAC, you want to take a message and a key, and output a boolean (true if verified, false if not) instead of a tag. Thus, the two functions can't be the same, since they have two different type signatures. In C-like pseudocode uint8_t* MAC(uint8_t key[], uint8_t message[]...


2

Signing and signature verification are concepts related to public key cryptography. In case of message authentication codes, there is a single secret key and one function: T = MAC ( K, M ) Where: T - tag MAC - MAC function K - secret key M - message Messages can be signed by either the client or the server and verified by the other, depending on the case. ...


2

In TLS 1.2 the Client proposes a list of suites of primitives they are willing to use for TLS. This takes place in clear in the ClientHello message. You could examine that list and decide one of three things: The list has a nice modern Forward Secret Diffie-Hellman-style key agreement method you're comfortable using with RSA signatures. You present ...


2

You seem confused about a few things. Bear with me, this is a very common confusion! Encryption is defined with the intent of confidentially transporting information: if you encrypt information, it is meant to be hidden until decrypted by the receiving party. Note that in your pseudo code hash = doHash(message) signature = doAsymetricEncrypt(hash, ...


2

A secure cipher is required to produce ciphertexts that are computationally indistinguishable from random strings, so somebody might naïvely think that this is sufficient for your iterated ciphers to be safe. But no, it's not sufficient, because for the iteration to be safe the ciphers also need to be statistically independent of each other. On trivial ...


2

Is the assumption that AES is "best" a valid one, alongside the assumption for AES_GCM? Opinionated, but Microsoft doesn't implement a lot of modern ciphers, so AES is the tried and true one. If GCM mode is best depends on the use case really, but as it is an authenticated mode - it includes a MAC - it is generally better than e.g. ECB / CBC which ...


1

That's not a mode, that's the same mode used four times. And yes it's as secure as doing all the blocks sequentially.


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