Hot answers tagged authenticated-encryption
43
I'm assuming you actually know all of this better than I do... anyway, this paper neatly summarises all these approaches and what level of security they do or don't provide. I shall paraphrase it in English, rather than Mathematical notation, as I understand it, here:
Encrypt-then-MAC:
Provides integrity of Ciphertext. Assuming the MAC shared secret has ...
27
@Ninefingers answers the question quite well; I just want to add a few details.
Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ...
13
This is something I tend to disagree somewhat with Colin Percival on.
You should use Encrypt-then-HMAC if and only if you can get it right. The biggest pitfall is using a short-circuiting string comparison versus a constant-time string comparison. Given the former, people can use timing attacks to forge valid HMACs for arbitrary ciphertexts. With an ...
10
Hugo Krawczyk has a paper titled The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?).
It identifies 3 types of combining authentication (MAC) with encryption:
Encrypt then Authenticate (EtA) used in IPsec;
Authenticate then Encrypt (AtE) used in SSL;
Encrypt and Authenticate (E&A) used in SSH.
It proves ...
9
Those "magic numbers" are related to the security proof behind the HMAC construction.
In their Crypto'96 paper, Bellare, Canetti and Krawczyk first prove that $\mathrm{NMAC}_{(k_1, k_2)}(x) = F_{k_2}(F_{k_1}(x))$ forms a secure MAC ("message authentication code") provided $F_k(.)$ is an iterated and keyed compression function enjoying some good security ...
9
Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key ...
8
If you look closely at the definition of authenticated encryption modes, you will see they all are, actually, the combination of symmetric encryption and a MAC.
Using traditional encryption and an independent MAC has a few tricky points, none of them being unsolvable:
The encryption mode will use a key, and the MAC will also use a key; using the same key ...
8
Because OCB is patented.
And there are other good solutions for authenticated encryption that aren't patented. This makes them more suitable, in most situations. I can recommend, e.g., EAX, GCM, or CWC. EAX and GCM have been used in some standards, and AES-GCM has been standardized.
For pointers where you can learn more, read Wikipedia. And try using ...
6
The original security proof of HMAC, as well as a new one not requiring collision-resistance of hash, are for the construction hash(o_key_pad ∥ hash(i_key_pad ∥ message)) with o_key_pad different from i_key_pad (and both filling a block). That's the rationale for at least one of the constant. The other plays no role, it just must be different from the first. ...
5
INT-CTXT and INT-PTXT are usually on considered for private-key encryption. For public-key encryption, no correct encryption scheme can satisfy those requirements. (Proof: The adversary can run the encryption algorithm on an arbitrary message and submit it as its output. Since it made no queries to its encryption oracle, this ciphertext violates both ...
5
To get non-repudiation, you must have a "proof" which can be used against the signer himself. Symmetric cryptography, by itself, will not help you there, because a cryptographic proof can only come from some "secret" which is under exclusive control of the signer, and the symmetric model assumes that there is a shared secret between two entities. The concept ...
5
The idea that cryptography alone can provide non-repudiation is a myth. I realize it is one that is taught in many crypto textbooks -- but the textbooks are wrong.
See, e.g., my answer here and here.
I could suggest some constructions (e.g., sign the message, append the signature to the message, then encrypt it using an authenticated encryption mode of ...
5
I don't have my Real 802.11 Security book present, so my answer is based only on what I could glean from the CCMP and CCM page on Wikipedia.
As stated there, CCM is only a mode of operation providing authenticated encryption (using CTR-mode for encryption and CBC-MAC for authentication), whereas CCMP is a protocol which utilizes the CCM-mode of operation. ...
5
As D.W. mentioned, the patent on OCB really is a killer; who would want to go through the legal hassle and expense of licensing OCB, when there are free authenticated encrypted modes available.
Another, considerably more minor issue, is that OCB does not support 'Additional Authenticated Data'. This is data that both the encryptor and decryptor provide to ...
5
I'd use HKDF's "expand" step to generate multiple keys from one masterkey.
Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2.
//Extract
MasterKey = PBKDF2(salt, password, iterations)
//Expand
AES-Key = HMAC(MasterKey, "AES-Key" | 0x01)
MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01)
(where | ...
5
As pointed in the question, a conservative API to authenticated encryption should only ever release authenticated plaintext on the deciphering side. Anything else is too open to attacks (padding, timing, denial of service, unamit).
In a streaming API, this forces aggregation of data into blocks, each authenticated. The simplest method is fixed size ...
5
Clearly, if you had been using AES-256-CBC for confidentiality and AES-256-CBC-MAC for authentication, it would not be secure to use the same key for both confidentiality and authentication. Hence, using the same key for confidentiality and authentication cannot generally be secure; you need additional premises to arrive at that conclusion. In your case it ...
4
The paper you cite (Deterministic Authenticated-Encryption...) gives quite a bit of useful information (but I'm assuming you already knew that). It looks like a pretty good read (I'll let you know if that assumption holds after I finish it).
For why simpler constructions (CBC/CTR with a MAC or even AEX mode) don't satisfy (emphasis added):
A key-wrap ...
4
If you go through the math, it appears that exactly the expected amount of ciphertext expansion is happening. Here's what's happening:
The GCM takes the plaintext as a byte string of size N, and generates a ciphertext which is a byte string of size N+28, where 12 of the 28 is the nonce, and the other 16 is the authentication tag.
Then, that octet string ...
4
GCM mode already incorporates any params that could affect the outcome of the decryption. The associated authenticated data is there to allow you to rely on context for your decryption.
For example, say you are encrypting some records associated with a user. You may want to include the user's database ID as the authenticated data. If a user found a way to ...
4
You got some notation wrong. There is no algorithm like "AES-GCM-SHA-256".
AES is a block cipher, i.e. a pseudorandom permutation of 128-bit blocks. It itself only allows encryption for messages of size 128 bits (= 16 bytes), with a limited security guarantee.
When you mean "encrypt the data using AES", you actually mean "use AES with some mode of ...
4
CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol.
Among positive things there are to say about CRAM-MD5:
The password is not exchanged in ...
3
I currently manually append the "tag" property to the ciphertext, is this the correct method of authentication?
That is a perfectly acceptable method. In the end, there needs to be some protocol which tells the other party where the ciphertext is and where the authentication tag is. In your case, the other party knows that the last 128 bits of the ...
3
I see no reason why that would not be secure. If you want to play it safe, though, you could always go with a standardized key derivation function, such as HKDF (RFC 5869) or one of the other KDFs listed in this draft standard. (The draft itself seems to be expired, but it's the most convenient list of standardized key derivation functions I could find.)
3
I'm not sure which of the inputs in your HMAC is your key and which one the message. The secret should be in the key position here.
Also, you might want to include the message (either plaintext or ciphertext) itself in the MAC - otherwise you are vulnerable to an attacker which can change the data (even if he can't read it, and does not exactly know to what ...
3
Encrypt-then-MAC has been standardized in ISO/IEC 19772:2009 hence it is safe to assume all the properties that you mentioned.
To the best of my knowledge, the best way to perform EtM is:
E = ENCRYPT(PLAINTEXT)
I am assuming that you are using a block cipher such as AES and
appending the encryption IV or nonce to the start of E unless of course you ...
3
First, convert the string which is to be encrypted into a sequence of bytes. UTF-8 is easy enough; you may reduce the size a bit, depending on what you know on the input strings (e.g. if the strings are domain names, they are ASCII-compatible, so you need only 7 bits per character -- actually a bit less). For the rest of this post, we need to assume that the ...
3
Well, no, it is not safe to use a GCM authentication tag as a hash. If you know the key, it is straight-forward to find preimages; that is, find a message that hashes to a specific target value. Note that you asked for second preimage resistance; not only does it fail to provide that, it fails to provide the weaker preimage resistance.
CCM and OCB have ...
3
The answer to your question is yes this is possible, but if we don't use assymetric cryptography, we need an alternate source of assymetry. One option is using time-delayed schemes. In such schemes, the key for the MAC is not initially disclosed, but only after some time interval.
See here for TESLA that accomplishes this. TESLA has a drawback in that it ...
3
I think (emphasis on think) that treating the data as a series of packets is okay, as long as you verify each packet. You are only releasing authenticated chunks of plain text (or rejecting tampered packets). However, you also need to use some kind of implicit or explicit counter in the nonce/IV, so that the stream can't have packets sent out of order ...
Only top voted, non community-wiki answers of a minimum length are eligible
