# Tag Info

4

In GCM, the plaintext is computed without the tag. But the decision about whether it's safe to release the plaintext depends on the tag! If the tag is not correct, you must return an error. Without the tag "guarding" the release of the plaintext, it is trivial for an attacker to modify the contents of a ciphertext.

3

Does the output (PT) depend on Tag value (T)? No it doesn't, unless you assume that returning an error is also considered output. This output is often denoted as $\bot$ in descriptions, although your reference denotes it simply as "FAIL". In the end, the encryption used within GCM is simply counter mode encryption (CTR or SIC). The only trick is ...

3

Q1: What is the additional benefit we gain from using this additional signing? There are a few benefits that I could see, although in the end it is the use case which should indicate the possible benefits. only the party with the private key could have signed the document. With a MAC, both parties are able to sign using the shared secret key; the ...

3

Q1: Why is confidentiality of the messages lost when using the same IV twice? From the principle I could only see that the result XOR(p1, p2) can be inferred because the upper line of data is the same - but not the p1, p2 itself. Actually, in quite a lot of cases, knowledge of $p_1 \oplus p_2$ can be used to recover a good guess of $p_1, p_2$. That is ...

3

An AES key must be generated completely at random. It's 256 bits, which in practice are encoded as 32 8-bit bytes. Note that these are bytes, not characters. With a multibyte encoding, the key may have a variable number of characters, and in fact it often cannot be converted to a character string because a random byte string has a large chance of not being a ...

3

The key and IV should be completely random bytes with no relevant interpretation as human readable characters. You can derive a key from a human readable password using a key derivation function. The IV and salt should just be sampled completely random, such that the entropy is high enough (e.g. 128 bits). Say the key is 128 bits (=16 bytes) long - each bit ...

3

First, to define the construction. AES-GCM when used in the suggested way is equivalent to $$\operatorname{KDF}(K,S,I)=\operatorname{AES}_K(S\|0^{32})\oplus \operatorname{GHASH}_{\operatorname{AES}_K(0^{128})}(I)$$ where $\operatorname{GHASH}_H(M)\approx \sum_i H^iM_i$ for message blocks $M_i$ of size 128-bit and the multiplications and additions being done ...

2

"Straightforward" is a relative term. There are algorithms. The basic outline for one of them is First factor the polynomial into square-free factors using the Square-Free Factorization Algorithm. For each square-free factor found in step 1, factor it into a products or factors of the same degree (Distinct Degree Factorization). Use the Cantor-...

2

Forget the other websites for comparison, you can fall into traps of inconsistent codes. Either use the OpenSSL as a comparison or better use the NIST test vectors; GCM Test Vectors (SP 800-38D)

2

I know this is an older post but I would just like to chime in with comments since developers who are new to crypto may find this and propagate a common but critical mistake. In the OP, there is the following line $app_cc_aes_key = substr($hash, 0, 32); This is an incredibly dangerous line of code unless you absolutely know what is occurring behind the ...

2

The obvious market for such a cipher is for lightweight internet-of-things devices where production costs need to be kept small and battery life needs to be maximised (e.g. if device access is hard such as with a pacemaker or satellite component). Minimising the circuit size and power consumption in these constrained circumstances is highly desirable. It is ...

2

I've seen other people say Poly1305 has a 128-bit security level but haven't found much about the security level of either. Well, in terms of security level, there are two potential attacks: One in which you attempt as an evesdropper to recover the secret key; the security of both Poly1305 and GMAC is essentially the same as the underlying block cipher. ...

2

Whenever a request comes in, I split the api key into (id, keybytes), lookup the client in the database by id, then calculate sha256 (id + keybytes + salt-from-db) and check if it matches the database stored hash. The requirements from the corporate security team was to not store api key in the db but store a hash of it (just like an user password). I also ...

1

Yes, you can decrypt a single AES-GCM partially. AES-GCM uses counter mode encryption, and you can decrypt counter mode from any specific offsite, assuming you know the nonce and method to calculate the counter values. Here is a Java implementation that takes GCM encryption and decrypts the ciphertext without verifying the tag and here is a way to run CTR ...

1

AES-GCM falls category A5 in the paper. In AES-GCM doesn't support $\texttt{no-AAD}$, even you don't use AAD during encryption, AES-GCM convert his as a $\texttt{zero-length-AAD}$. See in the NIST Special Publication 800-38d, page 15; Algorithm 4: $GCM-AE_K (IV, P, A)$ … 4. Let $u = 128\cdot\lceil\operatorname{len}(C)/128\rceil - \operatorname{len}(C)$ and ...

1

A generic term for input/output to cryptographic algirthms: Cryptogram.

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.

1

Yes, we don't send the keys directly. One must keep the keys secret, all the time! Instead, we send the key with a public key cryptosystem like RSA-KEM or better apply key agreement like Diffie-Hellman Key Exchange (DHKE) and better use Elliptic Curve version (ECDH). If you looking at some existing libraries look at libsodium or the age libraries for ...

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