# Tag Info

7

The Simplified AES uses the Galois field GF(16), which can be represented by polynomials over the F_2 field: hex ... bin ... polynomial 1 ... 0001 ... 1 2 ... 0010 ... x 3 ... 0011 ... x + 1 4 ... 0100 ... x^2 ... ... n ... abcd ... ax^3 + bx^2 + cx + d ... ... F ... 1111 ... x^3 + x^2 + x + 1 with multiplication defined as ...

5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...

4

The only limitation that you really have to consider is that of nonce collisions. With 128-bit random nonces, you would expect collisions after about $2^{64}$ nonces due to the birthday bound. Even if you stored all 30 fields of all 50 million rows thousands of times (you need a new nonce if a field is rewritten), you would still have a chance smaller than ...

4

The obvious answer to your question is "yes". The kernel mode implementation pointed to by otus clearly shows that it can be done. That it can be done doesn't mean it gets done however. Many Google searches for sourcecode don't show any OpenSSL code that implements this functionality. In general, OpenSSL doesn't rely on the crypto code of the kernel. So, ...

4

What you are looking for is a definition of PEM, privacy enhanced mail. Obviously PEM is not just used for mail anymore. The definition of the header lines seems to be best described by section 4.6: "Summary of Encapsulated Header Fields" of RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication ...

3

Strictly speaking, we can't know for sure that the output of AES is indistinguishable from random noise. It's conjectured to be true but no "proof" of that fact exists. For most commonly-used ciphers, it is conjectured that their output is indistinguishable from random. Specifically, modern ciphers are conjectured to be "strong pseudorandom permutations", ...

3

Yes, the principle to use a common password and a unique salt per file with a key derivation function is a good and acceptable practice, as you generate the salt randomly and with the right size. The uniqueness of the salt guarantees a different password per file (actually one password per salt, so: do not reuse a salt, use a csprng). You forgot to mention ...

3

This answer is based on Intel® Advanced Encryption Standard (AES) New Instructions Set whitepaper (Revision 3.01, September 2012) by Shay Gueron. No, the keys are not identical (within order) for encryption and decryption. The first and last key used in decryption are indeed the last and first one used in encryption; but the other decryption keys are the ...

2

When you get the first part of the decryption wrong, but the rest correct, it almost always means that you got the IV wrong. However, with CBC mode, what usually happens is that you get the first 16 bytes wrong; instead, you got only 6 bytes wrong; that may indicate that you got the first 6 bytes of the IV wrong (and the other 10 bytes correct). In ...

2

A similar question as been asked before: Use cases for CMAC vs. HMAC? To resume it, AES-CMAC is a MAC function. It can be seen as a special case of One-Key CBC MAC1 (OMAC1) which also a MAC function that relies on a block cipher (so AES in the present case). HMAC is also a MAC function but which relies on a hash function (SHA256 for HMAC-SHA256 for ...

2

The answer is simple. AES is in itself a pseudorandom function, so an output from a single block encryption will produce 128-bits of pseudorandom numbers. Now to use AES to generate longer sequences, you will have to use a block-cipher mode that lets you do the same. Here is a small list of a few very popular modes ment for PRNGs: Counter(CTR): Counter ...

1

I am answering on the basis of this paper (pdf) linked in the comments, as well as some of the related papers it cites or is cited by. I am not aware of more realistic attacks on HMAC. It assumes a DPA side channel that leaks the number of bits flipped when a new value is read into a CPU register (or in another instruction in some of the papers). I.e. it ...

1

Well, as SEJPM and Mok-Kong Shen pointed out, it's described in FIPS 197, but let's explain it in details: Here's the Key Expansion algorithm pseudo-code from FIPS 197: Where $Nk$ is the number of $32$-bit words that composed the key $Nr$ is the number of rounds $Nb$ is the number of columns in the state block (which is always $4$). $word$ is a ...

1

Basically you would be constructing an AEAD scheme. You will need to perform HMAC over the IV, the ciphertext and possibly over additional associated data (AAD). If you just need to authenticate the ciphertext then you may simply leave out (or leave empty) the AAD - but not the IV during the HMAC function. Fortunately somebody already thought about ...

1

What you're describing is a ciphertext-only attack on AES. No, there's no (known) ciphertext-only attack on AES. Condition one: We know none of the weaknesses and similar plain-texts in these two blocks, I just mentioned, how easily could we discover it? By the lack of an transmitted IV, an attacker can learn whether the two messages are equal and ...

1

well it probably varies on how you want to access the key, one of the most extreme version could be an HSM which should keep it really safe but is also rather expensive. another way would be encrypting it with a key that just you know with plain AES and storing the base64 somewhere for example, that's what I do for some of them if you want to require ...

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