Why use symmetric encryption in a protocol like UPORT?

UPORT: A PLATFORM FOR SELF-SOVEREIGN IDENTITY ~ DRAFT VERSION (2016-10-20)

I noticed it states :

Let A be an attestation. Suppose we wish to share this attestation with only identities X, Y and Z. We first generate a random symmetric key k, and encrypt A symmetrically. We denote this ciphertext sym(k, A).

Now we assume that X, Y and Z each have a public encryption key. Let asym(U,V,d) denote the asymmetric encryption between identities U and V of some data d. Specifically asym(U,V,d) = sym(DH(U,V),d)

Where DH(U,V) is a symmetric key generated from the public key of U and the private key of V using a Diffie-Hellman key exchange.

Create a random and ephemeral public/private key pair R, and create the data blob made up of ( sym(k,A), asym(X,R,k), asym(Y,R,k), asym(Z,R,k) )

Why is A encrypted symmetrically?

Reading the Security.SE questions “Why is symmetric encryption still used? [duplicate]” and Asymmetric vs Symmetric Encryption a potential reason for using symmetric encryption is speed but I don't see the context reasoning for using it in this specific case?

• Only asking for clarification: Since the Security.SE question you linked to is a “duplicate” of another question, did you check the answers to that Security.SE question Asymmetric vs Symmetric Encryption too? – e-sushi Nov 17 '16 at 21:05
• @e-sushi yes, but I do not 'see' what the reasoning is in using symmetric encryption in this whitepaper. Perhaps this is a question for the whitepaper authors. – blue-sky Nov 17 '16 at 21:39
• Thanks. Hmmm, as the linked UPORT paper is a draft, things might still be explained in a later version. Contacting them might indeed be an option. Btw: if you happen to find the answer, please don’t hesitate to post it here. (If only, to grain some additional upvotes/reputation.) You never know who stumbles over the same question, and having an answe rhere tends to come handy in those cases. ;) – e-sushi Nov 18 '16 at 20:12

You have some secret ($A$) which you only wish to share with parties $X,Y,Z$ for which you also know the public key. So what you do is that you first pick a random public-private-keypair $R$ yourself and derive a new shared secret with each of them. Now you have three shared secrets which would mean you'd have to encrypt three different copies of your message $A$. Instead you only encrypt a key $k$ three times using the shared secrets (using DLIES) and then in turn use $k$ to grant access (by means of symmetric encryption) to $A$. This approach saves you quite a bit of bandwidth and computational power there as you only need to encrypt a large message once instead of three times.
In a graphic, this process would look like this (don't forget that $k$ is small and $A$ is potentially large):