# Tag Info

2

Just an additional point of information from the field. The NIST spec is strict in not allowing this, and it has good properties if an API does not do this. For example it protects against naive usage of the API which streams partial responses to some processing code which might execute commands or reveal timing information in side channels. However the ...

4

There are several reasons for an authenticated decryption (with AES-GCM or any other AE or AEAD mechanism) not to return any plaintext if the ciphertext is not authentic (i.e if the tag does not match). One danger is if the calling code starts using the partially decrypted plaintext. Suppose the caller does something with the beginning of the plaintext, then ...

5

Is it acceptable to return the wrong plaintext if the tag is incorrect? No. For one, it's against the spec quoted in question. How bad is it to return the wrong plaintext anyway? It's bad at least because if the AES-GCM API returned the wrong plaintext, then the software on top of the API might unwillingly use that wrong plaintext, just ignoring that it's ...

14

There is an article* that answers the question in the negative for GCM and CCM. The article introduces the first formalization of the Releasing Unverified Plaintext (RUP) setting. The related security notion is the Ind-RUP. The security question is can an adversary forge messages with unverified messages? In this game, confidentiality is not relevant, since ...

10

how can we prevent the cipher from being returned in case the tag is wrong ? As far as I understand, to compute the tag the decryption process must be done entirely. Actually, GCM decryption can be done in a two-step procedure: Step 1: compute the expected GCM tag (which is a function of the ciphertext, AAD, teh secret H value, combined with the nonce and ...

2

Unless you have a non-standard version of AES decryption, the decryption round keys should just be the encryption round keys in reverse order. In the notation of the wikipedia article, it sounds like you have $W_4,\ldots,W_{59}$ and you want to know $W_0,\ldots, W_7$ ($W_4,\ldots W_7$ represent the penultimate decryption round key; $W_8,\ldots W_{11}$ ...

1

JoJoTheCodeDude's answer is correct. I just want to add some detail which may clear up some possible misunderstandings and followup questions. AES is a block cipher. Contrary to the name Advanced Encryption Standard, it's not actually useful for practical encryption of anything. That's because, like any block cipher, it can safely encrypt exactly one block ...

2

It really depends on the block mode that you are going to use. If you want to use something like CBC, have a look into PKCS#7. If you were to use CTR mode, then you do not require any padding, as the input will always be in chunks of 16 bytes, and you use as much of it as you require.

1

Auth Data 1 as shown in the diagram is the optional "Additional Authentication Data". It's optional & need not be passed if your use-case doesn't need it. You can use it for stuff which is not secret (like version number of your protocol, address of recipients or anything else) The purpose of AAD is to send information along with the ciphertext ...

1

The relationship between Auth Data and Plaintext can be compared with that of a network packet header and payload. Modern ciphers provide provision to "authenticate" additional data that's not encrypted so that more robust protocols can be designed. Of course, if you don't have header, you can pass an empty bit string to it.

3

It seems that the question you're asking is about how to add a public (unmasked?) value to a secret-shared value. I suggest you edit the question a bit to clarify that this is not related to AES directly. With that aside, adding a public value to a secret-shared value depends heavily on what secret-sharing scheme you're using, and also the algebraic ...

-1

The Following Code Is Now Using The Password Derive Bytes Function, All Values Will Be Changed Accordingly string Password = "Example"; byte[] IV = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}; byte[] Salt = Encoding.ASCII.getBytes("Salt Example"); PasswordDeriveBytes pdb = new PasswordDerivedBytes(Password,Salt); Aes Alg = ...

0

This Example Is Using The Built-In PasswordDeriveBytes Function Aes Alg = Aes.Create(); byte[] IV = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}; byte[] Salt = Encoding.ASCII.getBytes("Example Salt); string Password = "Example"; PasswordDeriveBytes pdb = new PasswordDeriveBytes(Password,salt); Aes.Key = pdb.CryptDeriveKey(&...

1

I cannot see why such values are required for AES-192 and AES-256. That's because you have a correct understanding of the situation, and the answer manual is wrong. Your analysis in "what I tried" is correct; there's not a whole lot I can add to it...

1

So, AES is more secure than one-time-pad in this case. No, the one-time pad is perfectly secure, so it cannot be less secure than AES. What's tripping you up is you're not understanding a subtle detail of what perfect secrecy means. People often misunderstand it to mean "the attacker cannot learn what the plaintext is," but in reality it means ...

0

Thank you all for all of the excellent help. I am happy to say that with your help I have found the answer to my initial question and more. The code below accepts a [string] password, [hex string] salt, [int] key size, and [int] iteration count, and returns a tuple containing the correct key and IV for PBKDF2. OpenSSL PBKDF2 uses 10,000 iterations by default....

0

Yes it is safe. Assuming you get everything else right(Proper encryption mode), proper padding, secure random key, proper key management and avoid problematic other usages of same key, etc... You have to provide the encrypted key to the legitimate user, if you have two different transfer systems with independent weaknesses you could transfer separately but ...

0

In the context of the encryption of a mariadb database, according to the documentation. choosing-an-encryption-algorithm There are 2 modes of choice of encryption algorithm: The AES_CBC mode uses AES in Cipher Block Chaining (CBC) mode. The AES_CTR mode uses AES in two slightly different modes in different contexts. When encrypting table space pages (such ...

0

In general, it ends up being mode specific, but as it turns out the limit generally is about 64 GB, though it also depends on your risk tolerance. Schneier et.al. recommend $2^{32}$ blocks with CBC and $2^{60}$ blocks with CTR mode. However, later research said that CTR mode was about as leaky as CBC mode so you may want to limit yourself to $2^{32}$ blocks ...

0

AES-GCM uses AES-CTR to create confidentiality internally. Counter mode turns AES into a stream cipher, where the plaintext is XOR'ed with a generated key stream. This key stream can be applied bit by bit or - practically speaking - byte by byte (with the leftover key stream bytes after encrypting the last counter simply being discarded). Specifying any ...

1

AES-GCM is not the same thing as AES. AES-GCM uses a 96-bit IV, or transforms a non-96-bit IV into a 96-bit IV before use. The particular constraints of the RBG and Deterministic constructions mean that not all of those 96 bits are expected to change between invocations. An IV collision (two uses of the same IV with a given key) is catastrophic to GCM's ...

3

A few data points for AES-128. In 2018 Bar-On, Dunkelman, Keller, Ronan and Shamir described a 32-bit attack on 5 round AES (attack complexity here is the maximum of data, memory and computation requirements) and claimed a 99-bit attack on 7 round AES. The 2011 biclique cryptanalysis paper of Bogdanov, Khovratovich and Rechberger claims a 125.4-bit attack on ...

1

Yes, for sure. Commonly block ciphers are used for disk encryption algorithms because disks (or partitions) have a particular size. So there is no place to store an IV or authentication tag. They are also optimized for local changes to occur w.r.t. confidentiality and locality of the change. Finally they have to operate for a specific sector size. A stream ...

5

This is called a related-key attack. There are many types of related-key attacks and the AES key schedule is vulnerable to some of them, but not the one you describe. From the linked answer: The key owner can somehow be persuaded to compute three other keys $K_B$, $K_C$ and $K_D$, from $K_A$, using a specific derivation algorithm ($K_B$ is equal to $K_A$ ...

1

Let's start with a couple bad assumptions you made The app needs to operate in offline mode. That's why I hardcode keys in the application. Anytime you hardcode keys into an application, you have NO security. ALWAYS assume that an attacker can get your source code or reverse engineer it and can get what they want. You should only consider an ...

Top 50 recent answers are included