# Tag Info

14

In complete honesty: if you have to ask this question, it's overwhelmingly unlikely that you have actually succeeded in breaking the security of AES. At best, you may have discovered a well-known attack against misuse of particular block cipher modes; for instance, plaintext recovery with a chosen-ciphertext attack against ECB, or blind manipulation of the ...

9

Assuming you really had broken AES or another frequently used algorithm that is thought to be secure, the first step would be to prove it. Write the code for the attack. Verify that it works on randomly generated data of the kind it requires. If it can break some challenge (e.g. these), do it. Post the results to the challenger or show the results ...

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

5

First, it's not said that AES is unbreakable, merely that none of the currently known attacks reduce the computational cost to a point where it's feasible. The current best attack on AES-128 takes 2^126.1 operations, if we had a computer (or cluster) several million times more efficient than any current computer and could operate at the thermodynamic ...

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

Assuming for the moment that your claim is correct, I would suggest caution in revealing the details of your findings. After having your results validated by one or two people with the skills to do so (and whom you trust to keep things confidential), then some sort of general announcement (without specifics) would be best, to give people time (say three ...

2

What you are looking to do can be done, but if you expect it to just work, you are mistaken. Performing the calculation of the inverse here is the easy part, the hard part is the choice of affine transform polynomial and vector, as incorrect choice will lead to an insecure s-box. Multiplicative Inverse The most simple method of calculating the inverse is ...

2

No, it won't "leak" information, as long as you're using a modern symmetric algorithm that's resistant to known-plaintext attacks. However, depending on the encryption mode used (and whether there's integrity checking or not), there can be other security implications, such as the data in the known spot being substituted.

1

As I have duplicated your question by mistake and non of us have had an answer, I request help to the authors to know why those parameters where selected like that. The affine transformation is a vector space operation $(\mathbb{F}_{2})^8$, and the simplicity comes from the fact that, from the bunch of possible transformations the one used can be also ...

1

Finally I've went to the source and I've mailed the Rijndael's authors. They have answered very fast and very nice. I've understood the other way around. The affine transformation is over the vector space $((GF(2))^8$ and what they've say as simplicity was that, between all the possible affine transformations they select one that can also be described as ...

1

The key schedule uses constants that differ between the key sizes. For arbitrary sized keys you would have to define an algorithm for deriving them. Each key size also uses a different number of rounds, for which you would have to do the same. Also, what's the point? 256-bit keys are enough for all eternity. Using a longer keylength variant would likely ...

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