# Tag Info

3

A Vigenère cypher can be unbreakable if, and only if: the key is random, the key is at least as long as the message being encrypted the key is used only once. In that case a Vigenère cypher is mathematically equivalent to a One Time Pad, and the same mathematical proof of unbreakability applies. You proposal is closer to being unbreakable than standard ...

0

While I can confirm that your “feeling“ is indeed correct, the rest of your question is not that easy to answer. I’ll try to give you some insight nevertheless. Generally… The number of rounds depends on the design and security parameters of the individual ciphers. This makes it rather impossible to generalize things in form of “structure $A$ should use ...

1

There are generic constructions along the lines of a PRP is a PRF, which can be extended to have larger input and output, which can then be used in the Luby-Rackoff Feistel construction. You can also use more specific block cipher modes like EME. I would expect these to be more efficient than more generic constructions.

1

The cascade construction extends a PRF (in particular, a PRP) with fixed input length to a PRF with an arbitrarily large input length. If you want a PRP with large input length, you can use the Luby-Rackoff/Feistel transformation on the large-input PRF obtained from the cascade. The cascade construction is analogous to the Merkle-Damgard paradigm for ...

2

There are many possibilities here, depending on the particulars of where exactly you will use it. Your use case may require a random looking derived key, where the 1024 bytes of entropy have been distributed evenly over all the bytes of the final key. In that case there's no avoiding a key derivation function. You will have to use either a block cipher, a ...

2

You would need (at least) 3 pairs of vectors in order to determine the 3*3 matrix.

4

The sum of PRPs is a secure PRF. That paper gives as a security bound for a sum of two independent PRPs $q^3/2^{2n-1}$, where $q$ is the number of queries and $n$ the block size (i.e. 128 for AES). That means that your construction, correctly used, is more secure than a single PRP, for which the bound is $q^2/2^n$. If you wanted to give an adversary an ...

4

No, this is safe. In fact, if you show a way of distinguish the stream $AES_{k_1}(C) \oplus AES_{k_2}(C)$ from a random stream with fewer than $2^{64}$ outputs, you have just demonstrated a way of distinguishing AES from a random permutation. Here is how this works: suppose we are given Oracle assess to a permutation $P$, which might be $AES_{k_1}$ for ...

5

Nobody can tell you not to "have fun with it" but I would strongly recommend you to first study attacks on other ciphers. Spritz (Rivest & Schuldt) fortunately mentions a lot of research on its predecessor, RC4. This makes it a rather good starting point in my opinion. It is necessary to understand the linguistics and mathematical constructs that are ...

1

Poncho's answer seems to have the right general idea: to slow down decryption while keeping encryption fast, make the decryptor solve a proof-of-work puzzle. His system seems a bit unnecessarily complicated, though, so let me try to present a simpler one. This scheme is based upon the commonly used practice of key wrapping, where the actual message $m$ is ...

0

Since both the other answers let the attacker try more than the specified ~1000 keys per second, here's a solution that doesn't. Use 256-bit authenticated encryption, like AES GCM or AES CTR + HMAC-SHA-256. Use a 128-bit key. Derive the encryption key from the 128-bit key using PBKDF2-HMAC-SHA-256 with e.g. a million iterations – or more, whatever gets you ...

1

The obvious way to come up with a 'fast encryption/slow decryption' algorithm is to make it a puzzle; that is, to encrypt, you randomly select a puzzle (which is fast), to decrypt, you must solve the puzzle (which is slow). Here is one way to come up with a tunable puzzle (which can be solved in deterministic time, and for it is rare that a descriptor ...

0

Just encrypt with a random key, then throw the key away. The recipient must use brute force to try all keys. To reduce the decryption time from "impossible" to "slow", keep an appropriately-sized part of the key.

3

This sounds like "fair exchange," the subject of many good research papers. In general you need a third party to give any security guarantees, but "optimistic fair exchange" involves the third party only when one of the parties tries to cheat (i.e., when both play honestly there is no involvement from the third party). Incidentally, Diffie-Hellman is most ...

Top 50 recent answers are included