# Tag Info

2

AddRoundKey. That step takes 16 bytes from the expanded key schedule, and exclusive-or's ("adds" in $GF(256)$ terminology) it to the intermediate block state.

2

The keyword you are looking for is related-key attack, where exactly this kind of different input keys (without the restriction to 1 byte) is used to break the cipher. (Wiki) Related crypto-SE topic: Related-key attacks on AES A related-key attack on AES has been analyzed by Biryukov and Khovratovich Also worth a look: Security section of Wikpedia for a ...

3

If we take some randomly generated key of AES-128 and we change any random 1 byte of that 16 byte key, will this make huge difference in the AES cipher text generated over same input string? Yes. The outputs with different keys differ greatly. If you pick two random keys the outputs must look completely uncorrelated, or an attacker could gain an ...

0

In a Feistel network you can use ANY function and it will be invertible. Of course, in order to get security you need the function to fulfill some property. One of the main reasons to use a Feistel network is to get a pseudorandom permutation. For this to work, you need 3 or 4 rounds of Feistel with a pseudorandom function (with tweaks or independent keys at ...

1

GCM is sometimes called a 1.5 pass AEAD cipher, where the CTR encryption counts for 1 and the GMAC counts for 0.5. So you would indeed expect it to be faster than encryption + CMAC and HMAC with regards to the amount of CPU instructions. That is: as long as the encryption is using AES for both solutions. GCM requires a 128 bit block cipher while CMAC and ...

0

As far as I understood the method of creating the 128 bit counter in the NIST documents is more or less kept open. There are some hints of deriving the counter, but NIST is essentially saying that anything is secure as long as the counter is unique. Using a starting value of 128 bits is certainly feasible and often required. Java providers - for instance - ...

0

No. That would amount to cracking AES, which is not feasible.

4

The simple answer is no, even if one can choose "the original unencrypted (cleartext) file".

20

It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...

0

Solved it by separating the CBC logic from the block encryption logic. Here is the revised code: void AES::encrypt(const char* src, char* dest, size_t length) { //TODO: Handle data lengths < 1 block! //Encrypt all of the data while (length > 0) { //Copy the next source block to the state array memcpy(m_State, src, 16); ...

0

To expand on what kasperd says in a comment. This sort of thing should be handled in the protocol. This would typically be done by adding message authentication code (MAC) in the traditional encrypt-then-mac paradigm or using authenticated encryption. So then instead of doing if (client.aeskey != server.aeskey), print Error, you would be doing if ...

1

There's no practical difference between zero IV and any other constant IV here. With some older ciphers that have a small enough keyspace (or weaknesses that allow reducing it) you could have a rainbow table for the encryption of the zero vector which might make zero IV a weaker choice in some cases, but that would be impossible for AES with its 128-256 bit ...

0

Sorry for not being specific (as I don't know that much about AES itself) but you should go with RSA for messages, generally asymmetric encryption is great, but slow. The best solution is to encrypt AES password with RSA (pgp for example) and then use this password to encrypt messages. This way you can share passwords in safe way. And pgp allows source ...

1

Concatenating two copies of your message is unnecessary and is equivalent to padding out your 64 bit message to the full 128 bits with zeros from a security standpoint (which happens automatically in the encryption process). Would they be able to securely authenticate the message? I assume you mean Authenticated Encryption. The simple answer is no. ...

1

Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ...

4

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. IV of any size For GCM a 12 byte IV is strongly suggested as other IV lengths will require additional ...

2

I'm not an expert yet, but this is how I remember it. DPA or differential power analysis is a side-channel attack on hardware implementations of cryptographic algorithm. All electronic circuits consume different amount of power depending on the activity of individual transistors. For example, more transistors may switch when adding the hexadecimal bytes A7 ...

1

I think it is now valid to answer this question as this course is likely to be over. First observer how CTR-mode works: $C_1=E_K(IV)\oplus P_1$ As you can see, there's a linear relation between the plaintext and the ciphertext. You now use $C_1$ (observed) and $P_1$ (known). You want to make $C'_1$ decrypt to $P_1'$. To obtain this you first construct ...

3

The "interesting" part of your encryption is here: Therefore, I prepend a block at the beginning of my packet. Its content goes as follows: First four bytes: current timestamp in seconds Next 12 bytes: zeros I compute the sha256 hash of the message (32 bytes) I xor the timestamp + zeros block with the first half of the hash I xor the ...

5

At a high level, the major flaw is that you are rolling your own crypto protocol. You should strongly consider using a standardized protocol like DTLS. Some specific problems: Symmetric key distribution is left unspecified. Keys must be changed occasionally to thwart distinguishers. No way to recover from symmetric key compromise. Your message ...

0

Take a look at this chapter (Introduction to post-quantum cryptography by Daniel J. Bernstein). It gives an excellent overview of what is known. (Bottom line, Grover's is the best known today and so this can be thwarted by taking 256 bit keys.)

1

KDFs like PBKDF2 are a work multiplier but they can't get blood from a stone. A PBKDF2 using 10,000 rounds "slows" the attacker down by requiring each "guess" to take 10,000 hashes instead of 1. The problem is that passwords like the ones you described are so weak a 10,000x increase in cracking time is like going from 1 ms to 10 seconds. It really isn't ...

4

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

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

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

3

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

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

5

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.

0

The Pearson product-moment correlation coefficient is what you evaluate, in general, when you perform DPA (CPA would be a better name for this, but DPA is used also in this context). It is defined as: $\rho(X,Y) = \frac{cov(X,Y)}{\sigma_X\sigma_Y}$ Where $X,Y$ are your vectors, $cov$ is the covariance and $\sigma_X$ is the standard deviation of X. In your ...

Top 50 recent answers are included