Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

Public key authenticated encryption and why you want it (Part II)

0
0

InPart I, I made the argument that even when using public key cryptography you almost always want authenticated encryption. In this second part, we’ll look at how you can actually achieve public key authenticated encryption (PKAE) from commonly available building blocks. We will concentrate only on approaches that do not require an interactive protocol.

authentication noun

:an act, process, or method of showing something (such as an identity, a piece of art, or a financial transaction) to be real, true, or genuine

Merriam-Webster online

First, a brief digression about the nature of authentication and trust models. What do we mean when we talk about authentication? We often talk about authentication as if it was synonymous with identification, but the two are not identical. When I see an old friend in the street, I know who they are immediately (identification). I do not need to ask to see some proof of identity (authentication).

Authentication is the process of verifying that some claims are genuine. When you log in to a website, you claim to be somebody (your username) and you provide credentials (a password) to back up that claim literally, to lend credence to your claim.

When we talk about authenticated encryption, we are interested in authenticating the content of the message received, regardless of whether it makes any claims about who sent it. Should I trust this message? Does it come from a trustworthy source? On first glance it may seem that in order to evaluate the trustworthiness of the source I need to know who the sender is, but this is not actually true.

In symmetric cryptography, all legitimate parties in a conversation share a secret key. Any individual with access to that key can create a message that is indistinguishable from a message made by any other individual in the group. The trust model is implicitly that anyone who has access to the key is trusted, otherwise don’t give them the key. (Typically we therefore keep the number of parties that have access to any given key as small as possible, preferably just one or two). Authentication in this case just means ensuring that a message came from anybody in the trusted group, but didn’t come from somebody outside the group.

In public key cryptography, everyone has their own keys, and so the space of possible trust models becomes much richer. We could try to mimic the symmetric situation, for instance by only giving our public key to known trusted parties. However, the benefits of public key cryptography are rather lost in this scenario, and the security proofs for public key cryptosystems tend not to consider the secrecy of public keys to be a concern, for obvious reasons. So your “secret public” key might not remain secret for long.

In some cases, we may want to explicitly identify the sender of all messages. Perhaps we want to be able to hold them accountable for their actions, or be able to prove to a 3rd party (such as a judge or jury) who said what. In other cases, we may prefer that this not be possible we want to know who we are talking to at the time, but would prefer that nobody be able to prove who said what afterwards. Digital signatures are often used in the first case, while the Signal messenger takes the latter approach. It is therefore important to remember that in PKAE there is not a single trust model or single definition of authentication in play, but rather a spectrum of possibilities. In all cases, we are trying to answer the basic question should I trust this message?

Option 1: Combining encryption with digital signatures

Perhaps the most obvious approach is to combine a public key encryption scheme for confidentiality with a digital signature scheme. For instance, we could encrypt a message using RSA OAEP and then sign it with an RSA signature. But should we sign the message first and then encrypt it, or perhaps encrypt it first and then sign the result? By analogy with the symmetric case, where Encrypt-then-MAC was the right choice, we might think that Encrypt-then-Sign would work. However, this is usually not the right choice for a number of reasons:

Firstly, if you are using signatures for legal reasons (to use as evidence) then in some jurisdictions a signature over an encrypted ciphertext may not be acceptable. Secondly, somebody else can simply remove the signature and then add their own to claim that they sent the message. For instance, imagine a competition where the first person to solve a puzzle and send you the solution wins a prize. If you use Encrypt-then-Sign then an attacker could intercept a legitimate submission and change the signature to claim that it came from them, without ever knowing what the correct answer was! The recipient of a message may be able to find (calculate) adifferent message and public key pair that would encrypt to the same ciphertext that you signed. The could then claim that you actually sent them this different message rather than the genuine one.

In fact, no nave combination of encryption and signatures achieves PKAE in general, as shown in this paper from 2001. They claim (page 6) that even if the cipher is IND-CCA secure, the generic composition of Encrypt-then-Sign may fail to be IND-CCA secure itself (although the definition of IND-CCA is slightly different for PKAE than it is for normal PK encryption). They offer a secure combination that they call ESSR Encrypt Sender-key then Sign Receiver-key :

First encrypt the message using the receiver’s public key, butinclude your own (sender’s) public key in the encrypted message. Next, sign the encrypted ciphertext plus the intended receiver’s public key.

This has the property of binding the key-pairs used in the construction of the message. An attacker that strips the signature and replaces it with their own will fail because the wrong sender key will be found inside the encrypted ciphertext. Binding the receiver’s public key to the signature prevents the malicious recipient attack mentioned in point 3 above, as they are not able to change their public key after the fact. This latter property is known as receiver unforgeability (RUF) and is a relatively strong property related to notions of non-repudiation.

Including the full public keys of both parties would bulk the message somewhat. RSA public keys in particular tend to be quite big, and some post-quantum cryptosystems have even larger public keys . First, note that the recipient’s public key doesn’t actually have to be sent (we can assume the recipient has it), it just has to be included in the signature calculation. Secondly, we can replace the sender’s public key with a secure hash of it in step 1 to reduce the size.

Option 2: Authenticated Encryption from Diffie-Hellman While achieving PKAE from separate encryption and signature primitives turns out to be surprisingly difficult, construc

Viewing all articles
Browse latest Browse all 12749