# Tag Info

0

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

0

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

3

Yes, Poly1305-AES can safely be modified to use AES-256 rather than AES-128; but if AES is implemented in software beware of not introducing a timing vulnerability in the implementation. Change of the cipher in Poly1305-AES is explicitly endorsed; quoting D. J. Bernstein's The Poly1305-AES message-authentication code There is nothing special about AES ...

0

You shouldn't have to call doFinal more than once. Although in CTR Mode the blocks are independent, you can call the API functions just like you would with any other mode. The Cipher implementation will take care of increasing the counter between each block. So, with private static byte[] encrypt(final byte[] plaintext, final byte[] aesKey, final byte[] ...

1

The standard approach is to have the sender pick his nonce (either randomly, or as a counter), and send it with the packet. The decryptor then knows what nonce to use to decrypt, because it's right there. Because nonces aren't assumed to be secret, this works.

4

Your fault attack scenario correspond to this paper : A Differential Attack Technique Against SPN Structures with Application to AES and KHAZAD (Piret & Quisquater - CHES 2003) This paper describe how to retrieve four bytes of the last round key with at least two pairs of ciphertext/faultytext. Each pair of ciphertext $C$ and faultytext $C^*$ could be ...

0

For a definitive answer, you really should see the documentation for the data format you're dealing with, but just quickly looking at the XML response, it would seem that you're dealing with a hybrid encryption scheme. That is, your encrypted message consists of two parts: The actual data (in xenc:EncryptedData), encrypted using AES-CBC with a single-use ...

1

AES is asymmetrical in this regard. It is down to the key schedule, which generates a sequence of round keys from an initial key. In a modern desktop environment, the round key sequence is simply generated before encryption/decryption starts, so the difference in speed is minimal. In a memory-constrained environment like a smartcard, this may not be ...

0

I just noticed that you take the time for encryption and sending the result over a serial line. Serial line transmission is - I guess - significantly slower than AES operations on the Arduino. Your calls to micros() should be as close to aes_encrypt() as possible, otherwise the measurement is falsified. If the size of the data sent over the serial line is ...

2

Yes, there are modes of operation that achieve the property that you are describing. For example, the Propagating Cipher Block Chaining (PCBC) mode of operation: This mode is similar to CBC but the output for each block is propagated to the input of the next one, so a small error will propagate indefinitely, both for encryption and decryption. There may ...

2

Based on your description, you will not be able to recover the original encrypted file. Since you specify that you used a password and do not indicate the use of an IV, my assumption is that you did, in fact, use a passphrase rather than a secret key. When you encrypt a file with a passphrase, OpenSSL assumes that it is a low-entropy string unsuitable for ...

17

In short: You must authenticate the IV. Which particular attacks apply if you don't depends on the block cipher mode; I will give two common examples. In CTR mode, an attacker who fiddles with the IV can forge authenticated messages, but the content of the corresponding plaintext is beyond his control (since he doesn't know the key). Depending on the ...

4

The Encrypt then MAC is done in general in order to be sure to decrypt into the correct plaintext, without risking of parsing a non-authentic plaintext message. If you don't MAC the IV, then Mallory (attacker that can tamper with messages as a man-in-the-middle) can modify the IV and your MAC will be still validated as good. So you will decrypt into an ...

0

From what I understand, I can use the IV as a counter, and the IV only has to be unique for each key (generating unique IVs isn't a problem). Correct? Not exactly. The IV needs to be unique for each block per key. You can use a message counter for the Nonce component of the IV, then the block counter component is incremented from 0 in CTR. IV = [ ...

0

I decided to just implement something that's known to work, namely CTR with HMAC SHA256. So you are implementing your own mode after all? Don't. Combining MAC and encryption is actually tricky. You should use a standard authenticated encryption mode, such as GCM (which is CTR plus MAC done right). From what I understand, I can use the IV as a ...

1

Take a look at this article it explains the IV can be publicly known once you have encrypted your data. Is using (and storing) a different iv for each file sufficient? (Am I correct in thinking that I'd need to store the iv with the encrypted data?) Yes, as a matter of fact i would not recommend using an IV twice, just for safety. Is this safe? ...

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

0

We know this is theoretically possible, but your search space is 2^126 right now and no sign of this improving. Good luck building enough supercomputer (all the computers on the planet combined aren't even close right now).

2

No, that's not really possible without blatant flaws of the implementation. Modern modes of operation of ciphers are resistent to attacks even if you know many pairs of plaintext and ciphertext - and the IV is public knowledge. Knowing it is the normal case. You also didn't mention what operation mode was used. Well, of course you could brute force the key, ...

2

Welcome to crypto SE. I guess, you are referring to the mix columns operation from the point of view with polynomials over $GF(2^8)$. A detailed explanation of this can be found at Wikipedia. It is a quite unusual structure, but it behaves just like you would consider any $GF$. The columns are first considered as polynomial, or better: as coefficients ...

0

First I find the question legitime and trying to evaluate the complexity is not a easy problem. But to the question how it's look like, I would mention beforehand that AES or any other crypto algorithm could be write in many others different ways. See for example https://www.iacr.org/archive/asiacrypt2002/25010159/25010159.ps BTW any crypto function ...

Top 50 recent answers are included