# Tag Info

10

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

6

First, the fact that the data is "easy" to guess (in the sense that an attacker has a one-in-2^32 or a one-in-2^64 chance of guessing correctly) doesn't mean much if the attacker has no way of checking if his guess is correct. Or at least, it's not a problem with the cryptography. Second, even if he does have that ability, the problem of protecting your ...

5

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

4

Encrypting big amounts of data is no problem for block cipher - if you remember a few important things. You can't encrypt plaintext which is bigger than the block size. You need to do some addition work. Most cipher operation modes first divide the plaintext into blocks of the size of the cipher. Now you can do different things: How about just encrypting ...

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

2

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

It seems that you are trying to implement your own KBKDF (Key Based Key Derivation Function) using HMAC. Maybe it is better to use a pre-defined one. It would be more sensible maybe to use an HSM that is FIPS certified for NIST SP 800-108. These use one of the KBKDFs defined in NIST SP 800-108. You can still use the idea of the random by putting it in the ...

2

SHA is related to AES in that they are both US government standards. They are not similar algorithmically. SHA and AES are cryptographic primitives, TLS is a protocol. As the name describes SHA is a family of hash algorithms. AES is a block cipher. TLS uses many encryption algorithms, including AES in various modes, and several hash algorithms, including ...

2

According to the following link (Slide 5) and to what I studied last semester, http://www.ee.ic.ac.uk/pcheung/teaching/ee4_network_security/L02DESIDESAES.pdf During the final round (Round 16) before the inverse permutation, the left and right halves of the bits will be swapped then the inverse permutation will be applied.

1

(You should take a look at page 18 of FIPS 197 where it describes the MixColumns transform). You're close. Swap the order of your matrices so that you have: |02 03 01 01| |d4 e0 b8 1e| |01 02 03 01| |bf b4 41 27| |01 01 02 03| |5d 52 11 98| |03 01 01 02| |30 ae f1 e5| And then you compute the new columns. i.e. the new first column is: |02 03 01 01| ...

1

One way to derive the values $\lambda_0, \lambda_1, ..., \lambda_7$ would be to formulate the eight simultaneous equations in GF(256): $$\lambda_7 01^{128} + \lambda_6 01^{64} + \lambda_5 01^{32} + \lambda_4 01^{16} + \lambda_3 01^{8} + \lambda_2 01^{4} + \lambda_1 01^{2} + \lambda_0 01^{1} = Aff(01)$$ \lambda_7 02^{128} + \lambda_6 02^{64} + \lambda_5 ...

1

Is it necessary to factor time into this equation for devices that communicate infrequently with the same key? No. Time would only matter for attacks that require a lot of processing by the attacker. Basically, key recovery attacks, through either brute force (impossible with AES key size) or maybe weaknesses in the cipher (even known related key ...

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

1

TLDR: Don't invent your own protocol, use an existing one. Reusing an initialization vector with the same key is always a problem, even if the attacker is read-only. For CBC, you can see whether a beginning part of one message is the same as the beginning part of a different message (and you get to know the length of the common prefix, on block-level). ...

1

Wrapping my (now deleted) comments into an answer… OMAC, as described in the OMAC spec and its addendum, is what Rogaway et al provide security proofs for in their EAX paper. If you take a quick look at RFC 4493, you’ll notice that it states: The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message ...

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