Score:0

Crypto

CPU cost of signing vs. encrypting

Per

11/29/23, 4:50 PM

I'm protecting communication between some microservices using public/private key encryption, where the sending container has a public key and the receiving container has a private key. This both verifies the sender (only sender has the public key via a credential manager), and protects the data in case it may be buffered, e.g. in a Redis.

But for transient communication, I'm wondering if signing is really what I should be doing instead of encrypting. I only need to verify the source container, the data isn't potentially stored anywhere, and I trust the AWS VPC network traffic to not be intercepted.

So the question is, are signing and encrypting computationally equivalent? If signing costs the same as encrypting the data, I'd just encrypt it. But if signing is much cheaper than encrypting, I might choose to just sign for some communication.

For reference, this is in Go, and encryption is done with ParsePKIXPublicKey() and EncryptPKCS1v15(), and decryption is done with ParsePKCS8PrivateKey() and DecryptPKCS1v15().

253

1 + 8

fgrieu

11/29/23, 5:04 PM

_"only \[some smurf\] has the public key"_: This is a contradiction in terms! If something is **public**, attackers should be assumed to know it!

A. Hersean

11/29/23, 5:09 PM

Maybe this question should be move to security.SE?

fgrieu

11/29/23, 5:17 PM

@A.Hersean: I only migrate questions that have matured to the point of being consistent. Here we have that public key which is not; use of "signing" when the primitives used and the text suggest asymmetric encryption; no indication of the direction of the data to protect; no definition of "protect" in the first place (authentication and/or confidentiality); no indication of if the context allows to negotiate a key using asymmetric cryptography and reuse it with symmetric crypto, e.g. AES-GCM. Also, the title suggest something on-topic, so no urge to migrate.

Per

11/29/23, 5:31 PM

Perhaps I'm not being clear. The public key isn't public, it's just the key held by the sender. If microservice A has a public key (delivered into it by a credential manager), and microservice B has a private key to decrypt traffic from microservice A, then no one else can impersonate microservice A, and an attack on microservice C will not yield any keys allowing it to send traffic to microservice B impersonating microservice A, limiting lateral movement in a compromise.

fgrieu

11/29/23, 5:47 PM

@ Per: it's extremely un-academic, and possibly dangerous, to have a design relying on the assumption that _"The public key isn't public"_. Beside the contradiction in terms, it's not a design goal of cryptographic protocols and implementations to keep public keys confidential, and there sometime are ways to deduce a public key by observing exchanges (e.g. that's easy when observing PKCS1-v1_5 signatures of two known messages). There are several other issues with the question, including not defining if "protect" has goals authentication and/or confidentiality; and if that's in both directions.

Per

11/29/23, 6:08 PM

@fgrieu But it's stated clearly that it's in one direction, between exactly two services. And keep in mind that any signing key or API key would be equally vulnerable to a compromise of microservice A, which in ANY world reveals the necessary codes to communicate with microservice B. Please accept the assertion that the public key is only known to microservice A, delivered by a VPC key manager based on container IAM roles. Only microservice A running in the correct environment can obtain the public key. Please realize that if we doubt the key manager and IAM, we have another kind of problem.

fgrieu

11/29/23, 6:16 PM

@ Per : sorry I misinterpreted "communication between some microservices" to be bidirectional, because microservices often return an answer. I see no "signing key" or signature function in your setup: EncryptPKCS1v15 does not sign; it encrypts.

Per

11/29/23, 6:18 PM

@fgrieu Yes, the signing options weren't mentioned, I only added the ciphers for context. But I think I answered the question below when you asked about symmetric vs asymmetric, that asymmetric has no edge over symmetric in this scenario since the sending key can be recovered or recreated with an attack on any of the two endpoints.

Score:3

Crypto

A. Hersean

11/29/23, 5:06 PM

Signing and encrypting are not interchangeable: they have different purposes.

If you need authentication of a user or a service, then sign. If you need authentication of data, you can sign it or use a MAC (message authentication code).

If you need confidentiality, then encrypt the data.

If you need both authenticity and confidentiality, you have to encrypt the data then sign (or mac) the encrypted data.

Performance-wise, symmetric encryption usually use the AES-NI instructions of the server's CPU, which makes this operation extremely fast, oftentimes it's not even noticeable over the transmission delay.

Asymmetric encryption/decryption needs to first encrypt/decrypt the symmetric key, before encrypting/decrypting the data. This encryption/decryption of the symmetric is roughly equivalent to a signature operation.

Signature and asymmetric encryption are comparatively much slower than symmetric encryption. Depending on the algorithm used, its impact can be quite noticeable. Depending on the algorithm used, MACs computation can be hardly noticeable, for example in the AES-GCM algorithm, or they can necessitate a second pass on the data and double the encryption time.

+ 4

Per

11/29/23, 5:34 PM

Not completely answering the question, but closer. You have to imagine a public key only held by microservice A and a private key only held by microservice B and unidirectional traffic. In this scenario, the possession of the public key verifies the identify of the sender. But so does signing with reversed keys. This is why the question is straight-up whether the signing operation *or* the encryption operation is more expensive. "Public" key doesn't mean everyone has it, it only means that one microservice has it, beamed into it by a credential manager.

fgrieu

11/29/23, 6:07 PM

@Per: _"whether the signing operation or the encryption operation is more expensive"_ depends enormously on if you are considering symmetric or asymmetric encryption. Cost of DecryptPKCS1v15 is comparable to the cost of RSA signature. Cost of EncryptPKCS1v15 is typically 10 to 500 times lower, and comparable to RSA signature verification. Symmetric encryption/decryption/authentication is much faster, and does not have the message size limitation of EncryptPKCS1v15 (245 bytes with 2048-bit RSA, or like 240 bytes if we want a modern security level).

Per

11/29/23, 6:13 PM

Asymmetric. If we accept the assertion that only two services have half a key, then the question is the comparative cost of encryption with a public key and decrypting with a private key, versus reversing the keys, signing with a private key and verifying with a public key. The point is that if microservice G is compromised, it doesn't yield the tools to send to microservice B as microservice A.

Per

11/29/23, 6:15 PM

But truly, I might not be gaining anything over symmetric. If the public key on service A is compromised, you can send to service B. And if the private key on service B is compromised, you can make a new public key and send as that. In at least that way, the point is moot.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: CPU cost of signing vs. encrypting

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.