59

Encrypt your document, and embed a web address (and login details) in the packaging from which a reader can get the decryption key. The website must be trusted. The website logs will tell you when software has requested the key to decrypt it. If you also want to protect confidentiality, encrypt with two keys. One is the usual private key used to protect ...


50

Before answering your questions: GCM is an authenticated encryption mode of operation, it is composed of two separate functions: one for encryption (AES-CTR) and one for authentication (GMAC). It receives as input: a Key a unique IV Data to be processed only with authentication (associated data) Data to be processed by encryption and authentication It ...


45

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted. However, if you MAC-then-encrypt in the ...


40

AES-GCM has the following problems: In the case of nonce reuse both integrity and confidentiality properties are violated. If the same nonce is used twice, an adversary can create forged ciphertexts easily. When short tags are used, it is rather easy to produce message forgeries. For instance, if the tag is 32 bits, then after $2^{16}$ forgery attempts and $...


36

The crucial difference between plain encryption and authenticated encryption (AE) is that AE additionally provides authenticity, while plain encryption provides only confidentiality. Let's investigate in detail these two notions. In the further text, we assume $K$ to be a secret key, which is known to authorized parties, but unknown to attackers. Goals ...


32

In comparison to CBC mode and HMAC, GCM mode is quite a commonly better alternative. But, I'll go to detail where it necessarily is not. Just like Richie Frame, I also do not agree that CBC + HMAC is always the best comparison target. I've added a few other details. Hope you find them useful. Against CBC and HMAC I'll discuss downsides first. The ...


24

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


23

Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom. He also demonstrates two attacks which are possible because of trying to ...


22

With classical information, there is no way as you correctly surmise: someone could always duplicate the data. However with quantum information there is a no-cloning theorem. With quantum information it is possible to bound the amount of information that has been extracted from a system based on the fidelity of the system. This gives the concept of tamper ...


17

The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of ...


17

Would it not be easier simply to send $E(m||s,k)$ where s is a salt shared across the system? Yes, that would be simpler; however, that would not (in general) be secure. The assumption you are making is that if someone modifies the ciphertext in any way, then the last few bits of the resulting plaintext must also be modified. This is often not the case: ...


16

The source of the limitation lies in the fact that GCM has a fixed block counter using a 32-bit integer. Since the block size is $2^7$ bits, the total amount that can be encrypted with the CTR component is $2^{39}$ bits. The first limit reducing this by 128-bits is the fact that the block counter starts at 1 and not 0, at least with a 96-bit nonce. Nonce ...


16

The rationale goes this way: On a "big" system like a PC or a smartphone, ChaCha20+Poly1305 or AES/GCM are very efficient; the latter is fast because the hardware provides dedicated opcodes that implement both AES itself (aesenc, aesenclast on x86 CPU) and the GHASH part of GCM, which is used for the integrity check (pclmulqdq opcode on x86 CPU). On much ...


13

I've been suggested to digitally sign it, thus, I have my private key, and I ship my application with a public key, and the application then uses the public key to check the QR code As long as you can live with the requirements for RSA (signature size, computation), that sounds like an excellent idea. Am I encrypting the whole message using the private ...


13

Not with a file, as you say in your question You can always take a bitwise copy of a file. Always. Even if some specific OS makes it inconvenient, you can change to an OS which does let you. This leaves you with two possibilities for confirming opening. The file is encrypted in some way which requires you to access an external website to get the key, and ...


12

AES-GCM uses single block cipher operation and can be processed in parallel, therefore it should be faster. CTR+HMAC requires block cipher and hash function, which usually can't be processed in parallel. Also it requires 2 keys. It is often miss-implemented (MAC-then-encrypt or MAC-and-encrypt, using single key). Cipher-text length is the same for same ...


12

The definition of DAE security, as given in Rogaway and Shrimpton's original paper (which both defines the security notion and proves that SIV mode satisfies it), does effectively require that a DAE scheme must protect ciphertext integrity. Specifically, the definition of DAE security (definition 1 in the paper) says that an encryption scheme is DAE secure ...


11

The first 32 bytes of XSalsa20 output are used as key for the one-time-mac Poly1305. Poly 1305 needs a new 32 byte key for each message, using part of the key-stream is a natural way to obtain those. Requiring those empty bytes makes implementing the API easier. The implementer only needs to call XSalsa20 on the zero padded input buffer once, receiving both ...


11

Deterministic authenticated encryption indeed provides authenticity and it doesn't require a nonce or IV. In that sense it doesn't provide CPA security as identical messages would result in identical ciphertext. Authentication however doesn't really have to do with CPA security. It is about ensuring that the ciphertext was created by a specific party ...


10

One obvious thing that it is vulnerable to a known plaintext attack that truncates the known message. This attack is quite simple; suppose the attacker knows a message $(P_1, P_2, ..., P_n)$ and the corresponding ciphertext $(C_1, C_2, ..., C_n, T)$ (using some IV; we don't care what it is). Here is how the attacker can generate a ciphertext that would ...


9

The really important thing is, not encrypt-and-mac. The other two, you can debate, but both are at least theoretically sound -- one might just practically be better than the other. Encrypt-and-MAC falls apart for a very simple reason, though: the MAC is not meant to keep the plaintext secret. The MAC is based on the plaintext. Authentication is not designed ...


9

A is acting as a square-root oracle in that protocol. We can use that oracle to factor $n$ and break the scheme. Suppose you are an attacker that wants to impersonate A. You: Pick a random $m$; Send $m^2$ to A; Compute $p = \gcd(m_1 - m, n)$, thus factoring $n$. This works with probability $1/2$ for each attempt.


9

Thought I'd begin with some references for you that might be of interest. These terms are used as key 'selling points' for a number of schemes, including many of the CAESAR submissions. Some examples using the terms specifically are given below - most of which are from CAESER because I have the zoo in-front of me: "Online": OCB, Ascon, CBA, APE, NORX "...


9

It depends on which cipher suites and extensions the client and the server implement, enable and negotiate. The default operation in TLS 1.2 and earlier, is MAC then Encrypt. This corresponds to alternative a in the question. In TLS 1.2 it is possible to use AEAD cipher suites. Such cipher suites (e.g. AES-CCM but not AES-GCM) might correspond to ...


9

You don't need to put the IV in the AAD (Additional Authenticated Data) as already indicated in the comments. The GCM proposal as adopted by NIST (PDF) clearly specifies this in paragraph 2.1 Inputs and Outputs: The IV is authenticated, and it is not necessary to include it in the AAD field. The NIST document SP 800-38d (PDF) does not explicitly specify it,...


8

I suppose one of the problems (they mention several after a short reading) with a mode like GCM is nonce misuse (e.g. reuse). When the key is the same and the nonce is reused, by misunderstanding the concept or by a simple programming error, information about the plain texts can be revealed. Phillip Rogaway has already defined an encryption mode (SIV, ...


8

The encrypt-then-MAC paradigm works as long as the encryption is CPA secure and the MAC is secure under the standard definition. However, such a MAC must be secure for multiple messages. Therefore, using GHASH or Wegman-Carter authentication is not sufficient. (Indeed, in GCM, the result of GHASH is masked and not directly output.) The proof of the general ...


8

You dont need the public key/certificate to be present in the browser. You just need to devise a method to ensure the public key/certificate which is presented by the peer is valid. In a Web Browser scenario this is typically done by a number of known CAs which sign those certificates. But you can also ask the user to authenticate the certificate by a ...


8

One potential issue with GCM is that it can potentially make the problems you get from repeating nonces worse; instead of allowing you to forge, and revealing the plaintext for the packets with the repeated nonces, it can become a key recovery issue. Here's one way it can happen; suppose the AAD is the 128 bit key, and you repeat the nonce with three ...


8

If we were to use CTR, what would you think of using a checksum on plain text then encrypt whole. That's a really bad idea (from a security perspective). Here are the reasons for this: Depending on your checksum, there are immediate obvious attacks on the authenticity of messages. If your checksum is CRC for example then it is linear. This means that an ...


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