What problems did we have?

When working with Jetpack Compose, we encountered performance issues related to the stability of composable functions. Our primary goal in working with composable functions was to make them as stable as possible, or “skippable” in Compose terminology. In this context, “skippable” means that if a composable function is recomposed and its parameters haven’t changed since the previous recomposition, Compose will skip the function and reuse the previous values.

With Compose, we can see significant performance improvements because even minor improvements can reduce recomposition count levels throughout the app. To assess the stability of composable functions, we can leverage the Compose Compiler plugin.

The Compose Compiler plugin

Compose Compiler is a plugin that can generate reports and metrics for components or code written in Compose. These reports provide detailed insights into the behavior of our Compose code. The plugin was added in version 1.2 of the Compose library.

With this detailed insight, we can begin making improvements to our code.

How does it work?

The Compose Compiler plugin is a Gradle task that generates reports for composable code within a module. It assesses the stability of the code, offering the flexibility to run it locally or in a CI pipeline when necessary.

It is recommended to generate the report in Release builds.

To ensure that the plugin works perfectly, we first need to configure it in the project’s Gradle file.

The first part of the code generates reports, while the second one generates metrics for those reports.

To run this code, we use the Gradle command as follows:

Generating a report on release builds is recommended.

When the execution is completed, it generates a file in the build folder like the one below.

Where,

*-classes.txt: contains information about classes referenced from a composable function.

*-composables.csv: CSV version of the TXT file

*-composables.txt: contains a detailed output of each Composable.

*-module.json: provides detailed statistics as a comprehensive view.

In our case, we’re primarily focused on the *-composables.txt files and will be working with those.

The image above displays the generated value for only one module. However, for NordVPN, we have multiple UI modules, and each module generates its own compose_metrics folder (that has its Compose code) with all relevant reports included.

Refining the generated report

With all of our modules generating reports, here’s an example of how an individual -composables.txt file can contain multiple blocks of code like:

Each of these files contains numerous functions that exhibit a Kotlin-style code structure. Additionally, each module with Compose code has a dedicated text file. Before delving into the details, let’s take a closer look at the significance of this code:

Restartable: When Compose detects changes in the function inputs, it restarts the function, invoking it again with the updated inputs.

Stable: This parameter in the provided function is stable; if they have not changed, Compose will skip it.

Unstable: This parameter in the provided function is unstable and Compose always recomposes it when the parent is recomposed.

We then merge all the *-composables.txt files into a single text file within our project using a script we’ve created for this purpose. This combined file plays a crucial role in our development process. Let’s see how we utilize it.

How do we use it in our day-to-day development?

At NordVPN, we’ve seamlessly integrated this workflow into our CI pipeline for every pull request we create, ensuring that we merge only stable Compose code (whenever possible) into our main branches.

However, before implementing this process, we conduct a thorough review to ensure that all of our Composable code contains no unnecessary unstable parameters. This proactive step guarantees that when we introduce this to our pull request flow, we initiate with a clean slate.

Let’s take a closer look at the steps in our pull request workflow:

1. Create pull request: The process begins with the creation of a pull request (PR).
2. CI job: A Continuous integration (CI) job is triggered for the current PR if there’s a change in any of the UI modules. The CI job performs several tasks:
a. Generate report: We generate a report on the release branch, which results in the creation of multiple text files in each module containing Compose code.
b. Merge the text files: At this stage, we execute a script that combines these text files, retaining only the functions containing unstable parameters.
c. Create a markdown table: Next, we create a markdown table that lists the function names along with their associated unstable parameters.

d. Post comment: We post this markdown table as a comment within the PR. This informs developers about any potential instability introduced in the PR.
e. Fix: If instability issues are identified, we proceed to fix the affected functions and commit the changes.

The entire process is then rerun, and if the unstable parameter issues have been addressed, no further comment will be posted. Any previous comments on the matter can be resolved.

This practice aids us in utilizing the Compose Compiler plugin as a lint check for our Composable code, which maintains coding standards and contributes to improved performance for the NordVPN Android app.

Identity-based encryption

Wouldn’t it be great if we could just encrypt emails directly with a key derived from the email of the recipient? This question was first formalized by Adi Shamir, the co-inventor of the Rivest-Shamir-Adleman algorithm, or RSA, in 1984. The resulting cryptographic concept was called “identity-based encryption.” It took another 17 years until this concept was proven to be secure by Dan Boneh and Matt Franklin using the Weil Pairing.

Identity-based encryption (IBE) solves the problem of trusted public key distribution by letting users calculate the public key of recipients based on their identifier. An identifier can be any kind of string — the email address of the recipient, for example. The concept introduces a central authority whose job it is to generate respective private keys for identifiers.

Since the sender (let’s call her Alice) can calculate the recipient’s (Bob’s) public key offline based on his email address, Bob doesn’t even have to exist in the system yet. When Bob registers in the system, he just requests his private key from the central identity authority and then decrypts the data.

This design also solves the problem of key expiration — a complicated procedure in classic trusted web applications usually requiring expiring certificates. By making the identifier user+currentYear()@example.com, Alice forces Bob to request a new private key from the central authority every year.

Bob could also act as his own central authority, allowing Alice to send emails that could only be decrypted by certain departments. Imagine a scenario in which Bob is a company administrator and he needs to be able to view all company emails. However, he also wants to make sure that no department can decrypt emails from any other departments. The solution? Bob can set up a central authority and Alice can send emails to security@company.com, press@company.com, and info@company.com (all hypothetical email addresses invented for this example), each encrypted under their own identity public key. Best of all, these emails could all go to the same inbox without compromising confidentiality.

So why is identity-based encryption not used widely for email encryption? The biggest hurdle to this system is setting up the central identity authority to manage the generation of private keys. That might be practical in a company where it’s not unusual for administrators to have a master key to access employee data, but what about other non-corporate contexts?

Imagine that you have an image that you would like to show to your doctor — an X-ray from a previous appointment, for example. Maybe the doctor needs to consult another specialist, like a radiographer. You would like to encrypt your X-ray image in such a way that it could be shared among doctors and specialists.

Identity-based encryption wouldn’t allow the first recipient (your doctor) to safely share the data with someone else. For that, we would need something more flexible that would allow us to embed access policies within a message’s ciphertext. We need attribute-based encryption.

Attribute-based encryption

Attribute-based encryption (ABE) is the next generation of identity-based encryption. Instead of binding public keys to identity strings, they are instead bound to attributes.

Relying on attributes allows the sender to craft a ciphertext over a chosen access policy, combining different attributes with “and”/“or” gates to formalize access conditions. This approach is called ciphertext-policy attribute-based encryption (CP-ABE).

You can also do it the other way around — associate the user’s key with an access policy. Doing so is known as key-policy attribute-based encryption (KP-ABE). Similar to identity-based encryption, an attribute authority is responsible for managing attributes and their private and public key pairs. The owner of the attribute authority has global decryption power over all its attributes.

It is simple to make and own an attribute-based encryption scheme. Let’s introduce a central attribute authority, which stores a map of attribute identifiers to (normal, RSA) public keys. For example, imagine the following mappings:

If Alice would like to craft a ciphertext that can only be decrypted by general doctors who have her as a client, she would encrypt her secret text like this:

Cipher_client-alice = enc(text, PB_client-alice)
Cipher_client-alice&general-doctor = enc(Cipher_client-alice, PB_general-doctor)

Note that Alice herself doesn’t need to have access to the attributes. Only people who have access to both private keys of the attribute “has Alice as a client” and “general doctor” can decrypt the ciphertext. First Bob removes the outer layer of encryption by providing the “has Alice as a client” private key and then additionally applying the “general doctor” private key to retrieve the plain text.

Additionally, Alice would like to give all radiographers (Charlie) access to her photo scan. She creates the following ciphertext:

Cipher_x-ray-specialist = enc(text, PB_x-ray-specialist)

She can now combine both ciphertexts into one message and send it to her doctor:

Cipher_x-ray-specialist || (client-alice&general-doctor) =
Cipher_x-ray-specialist || Cipher_client-alice&general-doctor

As we can see, the ciphertext can be decrypted by radiographers (who will decrypt the first part of the ciphertext) or by any general doctor who has Alice as a client (decrypting the second part of the ciphertext).

As with most simple cryptography schemes, this system has some issues. In this case, our simple ABE schema is not collusion resistant. That means that if Eve is a general doctor and Dave is a psychologist who has Alice as a client, nothing stops Dave from just providing Eve with the private key for the attribute “has Alice as a client,” allowing Eve to escalate access.

Attribute-based encryption schemas must be collusion resistant. In practice, collusion resistant means that even if users exchange private attribute keys, they cannot gain additional knowledge about plaintexts beyond their access level.

This could be done, for example, by creating an individual user-bound attribute private key for each attribute, essentially combining the identity element from identity-based encryption with attributes. Additionally, ciphertext should not grow in size the more policies are added to them. Contradictorily, in our self-made schema, a ciphertext would grow larger and larger if we had multiple “or” conditions in our access policy.

Nevertheless, one problem remains. The central attribute authority can globally decrypt ciphertexts, allowing it to impersonate any user and issue any attribute to itself. Having this trusted central authority in the medical context is a bad idea, since medical information is highly sensitive and should only be decryptable and accessible by authorized parties. For the corporate context, attribute-based encryption makes more sense because an administrator could issue attributes to users and is allowed to decrypt and access any file in the company. But what if we have multiple companies, each with its own attribute authority?

Multi-authority attribute-based encryption

Multi-authority attribute-based encryption (MA-ABE) is an attribute-based encryption variation where multiple attribute authorities are responsible for managing distinct attributes. Why don’t we set up multiple individual attribute authorities? Well, we still want to be able to combine attributes from other companies with attributes from our own company to enable cross-company sharing.

Overview of an Multi-Authority Attribute-Based Encryption system for different companies

In such a system, it becomes a problem to establish globally known parameters for each attribute authority. MA-ABE introduces a new central server that is responsible for setting up new attribute authorities and bootstrapping the system overall.

Early MA-ABE schemes required this central server to have global decryption power over all attribute authorities. On the other hand, modern MA-ABE schemes such as DAC-MACS (effective data access control for multi-authority cloud storage systems) are close to what we need to implement for MA-ABE in real-world scenarios because they don’t require the central server to have global decryption power.

MA-ABE offers some useful new approaches to data encryption:

1. ABE schemes are group centric, meaning that a single group can be described with a single attribute. This makes encrypting and decrypting for groups easier. On the other hand, encrypting information for single individuals becomes more computationally intensive compared to traditional encryption schemes because these individuals usually don’t share common attributes.

2. When an attribute gets revoked from a user, the attribute key and all ciphertexts using this attribute need to be rotated and re-keyed. This can be done by the attribute authority or a proxy-reencryption service.

3. Proxy-decryption is a technique where a server helps the user during decryption. It does so by using the user’s private attribute keys. As the ciphertext is additionally protected with the user’s identifier (IBE), confidentiality is not compromised. Proxy-decryption can be used to help mobile clients with the computationally intensive decryption process.

Is MA-ABE ready to be deployed in modern secure cloud storage solutions such as NordLocker Business or NordPass Business? Personally, I would say no.

Even though the modern MA-ABE schemes fulfill most of the security requirements for end-to-end encrypted cloud storage systems, their system implementation is complex, and the underlying cryptographic principles like pairings are not yet widely adopted in cryptographic libraries. In addition, pairing operations are computationally intensive and not suitable for mobile devices, which require low power consumption for a good user experience.

With the world shifting increasingly further to the mobile side, proxy-decryption might help to decrease the computational overhead on the mobile device, but it requires the user to be always online to access their encrypted files. Finally, MA-ABE can only be cryptographically beneficial if users change their attitudes around encrypting files — away from sharing data with individuals, and towards attributing access policies over their data. It is yet to be seen if users and companies are willing to adopt this mindset change.

The existence and proven security of attribute-based and identity-based encryption schemes show that we are just scratching the surface of what is cryptographically possible with elliptic curves. However, the practical applicability of schemes in real-world scenarios is yet to be seen.