Tag Info

Hot answers tagged

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

I can make a few comments regarding points 1 and 3: If you are going to encrypt only one block, your first assumption is not that misled. However, you will almost always need to encrypt a file longer (maybe way longer) than the key length (let's say 128 bits). Without considering encryption modes, that means that for every block of 128 bits, you will ...


3

Would this help preventing brute force attacks? It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000. Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely ...


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

Regarding points 2 and 3, cipher designers want to ensure that the relationship between the plaintext, the ciphertext, and the key are complex, so that no attacker can efficiently untangle them. If the ciphertext can be expressed as a linear or sufficiently low-degree system of functions of the plaintext and key then attackers can use efficient algebraic ...


2

I will specifically address your question 3; that is, quite a lot of block ciphers (and hash functions) consist of a regular round structure (where you repeatedly do the same thing over and over); why is this? Well, one incentive for doing that is that it makes the cipher easier to analyze; we can study the round function in depth; once we've done that, we ...


2

I ("SEJPM" as of now) have contacted the authors asked them the same questions as in my question. I'm posting this as community wiki, as it's not my answer to this question but rather theirs. Now the responses follow: First off, the authors are working on a design rationale in english for their new cipher. As soon as it's published, it will be linked ...


1

To do EEA on a finite-field, you can't perform the operations using the operations in the ring of the integers (and they're not precisely the same operations in the field either, as you're working with bit vectors, not field elements). In particular: When you do "addition", you need to perform the addition as done in even characteristic fields (that is, ...


1

many thanks to everyone. When I was reading originally the FIPS 197 document I made one big mistake: I assumed that the appendix C had only the cipher portion, similar to the appendix B, and missed the uncipher portions. Answering my own question, yes, translation of the variable temp to the one I proposed initially was correct. However, my error come ...



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