# Tag Info

-1

I just quickly read the TLS specification and the document that introduces GCM into TLS. It is stated in the definition of GCM-ciphersuites that a 12-byte nonce is supplied (8 bytes per packet and 4 bytes from the handshake, as you correctly stated). First I'd like to say: Very often there's a (very good) reason why a decision was made (like here) in ...

1

If the MAC'ing is done right (after the encryption) and if you pad the CBC data correctly there's no security risk. Howver changing to CTR or even better to GCM would be better, as both don't operate on whole blocks and GCM even provides authentication.

2

Without Mix Columns, every byte of the ciphertext would not depend on every byte of the plaintext, but only on the one byte at the same position. This would fully break AES, because we don't have an avalanche effect on the whole text anymore. Without the Row shifting, every column of plaintext would only affect the same column of the ciphertext. This would ...

1

The ZFS file system uses AES in CCM or GCM modes. This works because in ZFS the data and file system metadata is encrypted but the block pointers are in the clear, the AuthTag (MAC) is stored in the block pointer. ZFS also has a SHA256 based merkle tree based on the block pointers that is used for data integrity for resilvering and navigation purposes. ...

2

You can use your HardwareID as basis for the encryption key. If the ID provides enough entropy it'll work. However, if anyone can somehow obtain the ID (which might be quite easy to do) one can decrypt the file. For CFB-Mode the IV must indeed be unpredictable (but need not be secret), so random is just fine, but DO NOT REUSE AN IV. Encryption large ...

0

In literature there are 2 ways to show the affine transform for a given polynomial, and that depends on the location of the MSB in the input as a polynomial. The polynomial representation of the full transformation, in the format of the original Rijndael paper, is: $b(x) = a(x)(x^7 + x^6 + x^5 + x^4 + 1) + (x^7 + x^6 + x^2 + x) ~~mod~~ x^8 + 1$ Where ...

1

AES sub-bytes is defined over the finite field $GF(2^8).$ This field has 256 elements. Its multiplicative group $GF(2^8)^{\ast}$ has 255 elements. In any multiplicative group $a^N=identity$ for all $a$ in the group. This means the multiplicative order of all the group elements (the smallest power they can be raised to and obtain 1) divides $N.$ Here, by ...

0

As this question is still on the list of "questions without answers", I'll quickly answer it (Basically repeating all of the above comments). Increase iteration count to something larger (1 Million?) You don't want to attach your HMAC of the plain-text after the contents. Rather authenticate either the ciphertext or (even better) use CCM/EAX/GCM mode. ...

3

I add my whitebox AES implementation on GitHub in: C++ Java C++ version implements both Chow's (mixing bijections, input/output encodings, external encodings) and Karroumi's (dual AES in each column) whitebox AES scheme plus Billet's key recovery attack on both schemes. Java implements Chow's scheme only. PS: Due to low reputation I post links to ...

0

An AES decryption with the correct key will return the original message, but an AES decryption with an incorrect key will produce garbage data as an output. The AES cipher itself provides no indication that the key was wrong - there's no point during the decryption at which the algorithm says "hey, wait a minute, this doesn't make sense!" and terminates with ...

0

Usually you require a mode of operation for a block cipher such as CBC or CTR to encrypt data. CBC or CTR is then configured with the given block cipher & key. The mode takes an IV or nonce as additional parameter, but I'll leave the IV out of my answer as the IV value is inconsequential if the wrong key is used. A block cipher such as AES will simply ...

1

It depends on the mode of operation. If you use an AEAD mode (which contains a message authentication code, to ensure that the message wasn't tampered with en route to you), then decryption will fail because the MAC is invalid for that message with that key (the whole point of AEAD is that someone without the key can't create a valid ciphertext, so a ...

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

Top 50 recent answers are included