# Tag Info

7

I assume you mean AES-GCM. Nonces must be unique for any use of a key. Given that $n = H(k)$ is constant for constant key $k$, this implies that such a nonce may only be used once, ever. Nonce reuse is particularly catastrophic in GCM mode (as with any other CTR-based mode), as it causes the keystream to be identical. Essentially, you wind up with two (or ...

7

DES is slow in software because it was designed back in the early 70's even before the 8086 processor existed, and uses several bit oriented operations that are just not implemented efficiently in a processor with a word oriented instruction set. Its intended product was ASIC hardware designs, in which DES runs quickly. DES hardware processors are quite ...

6

DES is slow compared to AES including in hardware because for comparable security we must use 3DES, which triples the number of rounds per block, to 48 for 3DES versus 10, 12, or 14 for AES; DES's block size is 64 bits, half of AES's 128 bit; so when encrypting a sizable block of data, 3DES does more rounds that AES by a factor of 96/10, 96/12, or 96/14; ...

5

This begs the question, why would you in any real-world circumstance wish to reduce the difficulty for an attacker to break your cryptosystem? To answer your question practically, the only reasonable way I can think of to accomplish this is to simply reduce the entropy in the key. At 100%, all 128 bits of the key are used. At 50%, 64 bits of the key are ...

4

Of those you listed, AES is the best to study. Not only is it the standard that is used everywhere, it has a huge literature of people explaining it and analyzing it, far larger than any of the others on your list. Also, compared to the others on your list it is easier to understand why AES strongly resists certain major classes of attack (like linear and ...

4

First, it is important to learn the basics behind all symmetric ciphers. You can get this from Handbook of Applied Cryptography, see Chapter 7, especially 7.1, 7.2, 7.3. If you understand those three sections, you will be off on the right foot. From there, I would suggest just diving right into AES. It isn't that terribly difficult (yes, there are easier ...

4

The most likely rationale to change the AES design is political. It's a NIST standard, designed in Western Europe. It's a bad idea! How much scrutiny has it received? Almost none. How much will it receive? Almost none. Bad idea.

3

You cannot encrypt 720 bits plaintext using just AES-128. AES is a 128 bit block cipher. Such a block cipher has an input of 128 bits of plaintext and an output of 128 bits ciphertext; and that's it. You need some kind of construction to make block ciphers encrypt larger or smaller plaintext. Such constructions are known as (block cipher) modes of ...

3

Among several aspects of the question, I'll cover only protection against replay of commands. A common technique (among several) is to have commands tied to a nonce, that somewhat is accepted only once by the slave device receiving the command. The nonce is included in the input of a MAC or public-key signature algorithm that protects the integrity of the ...

2

You say I have never studied a cipher before In that case I would recommend the following: Sign up for the Stanford online class on Cryptography on Coursera. This is a great introduction to Cryptography and this will conver block ciphers. Get a library card with your local public library and ask them to get some textbooks on Cryptography for you. ...

2

Idea 1 is similar to what TLS actually does (and begs the question "why aren't you using TLS?"). Modern thought is that it'd be generally better if you first encrypt, and then perform the MAC, as in: E := AES(M) Send IV, Encrypted HMAC(IV | Encrypted) But no radical problem is known with your idea (unless you send M1 and M2 at different times; if ...

2

It seems to me that you could prefix the Defcon level with a 15 byte counter and then encrypt it using a single block ECB (also known as AES used as a block cipher). Decryption will give you the counter to validate and the Defcon level. For a slightly tricker to implement scheme use a 7 byte counter and an 8 byte AES-CMAC, and encrypt that. This does expand ...

2

Your scheme turns AES into a one way function. As you already found out from the comments this scheme doesn't preclude collisions. There is a good reason why hash functions have a larger output size than the block size of most block ciphers as the birthday problem is applicable for this newly build PRF and normal hash functions. The chance of a collision is ...

2

As pointed out the nonce must be unique so hash of key only is not going to work. You could however hash the key and plaintext together to produce a secure nonce: $n = H(m|k)$. Note that this would still result in the same ciphertext for identical plaintext. So it doesn't fulfill the requirements for the ciphertext to be indistinguishable.

1

The "many attacks" you're referring to, don't exist. There are two main attacks on AES. One needs related keys and drops security level signifantly (to about the half of the bits). You're referring to the other one, the biclique attack on AES. This is the first attack on the full-rounded version of AES (without related keys) that performs better than ...

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