Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to compose with configuration flags ? #316

Closed
aPere3 opened this issue Apr 27, 2022 · 5 comments
Closed

How to compose with configuration flags ? #316

aPere3 opened this issue Apr 27, 2022 · 5 comments

Comments

@aPere3
Copy link

aPere3 commented Apr 27, 2022

Hello 🙂

I am currently trying to transition from a dependency on aes_soft to the aes crate. I would like to make sure that I am using the software variant of the blockcipher, and not the aesni version.

I saw that you transitioned from feature flags to configurations in #284 . Before that I would have used a dependency like:

aes = {version = "...", features = [ "force_soft" ]}

With the new way, I don't know how to do 😕. Is there a way to have the same behavior?

Also, out of curiosity, I tried to understand the rationale of this decision but could not find any good points to that. Could you quickly explain what made you move to this configuration approach ?

Thanks !

@newpavlov
Copy link
Member

I think the aes docs reasonably cover the question of how to enable the software backend. You can not do it in Cargo.toml, it has to be enable for a whole build.

See #245 for the discussion which led to the current approach.

Why do you want to make sure that you use the software variant?

@aPere3
Copy link
Author

aPere3 commented Apr 27, 2022

Thanks for pointing the discussion out !

So we use the aes blockcipher in a csprng (see concrete-csprng), and we want to expose multiple objects, which all implement the csprng api (defined by a trait in our crate). Each of those objects represent a specific implementation, and it is important for us to give the ability to the user to know for sure which implementation is getting used at run-time (basically, which one of those objects is used). This is part of our api: we do not take decisions on users behalf.

I am not sure I completely understand the details of #245, but I would say it is sad that the transfer of the aes-soft ended up making the available api smaller, by making this variant out of the users control 😕 .

From my (very) limited understanding of the library, the aes crate is supposed to be the go-to library for aes implementations in rust. If it is true, I would say it would benefit from exposing the different implementations in their own right in the API (be it via a direct existence in the api, or modification of the implementation of a type by feature flags). This of course would not prevent an automatic variant to be exposed in the same spirit of what you have today.

Anyhow, this is just an humble opinion 😉 I obviously don't have all the constraints of the library in mind, and I am sure you guys all try to make the things as best as possible !

@newpavlov
Copy link
Member

newpavlov commented Apr 27, 2022

Why do you want to expose separate variants like AesSoft and AesNi instead of a single Aes? For users only the used algorithm should matter, not underlying implementation. Hypothetical AesSoft and AesNi both will result in the exactly same output. If user CPU has hardware implementation of AES it should be preferred to the software-based one.

Users will be able to remove the AES-NI backend or force it using the configuration options, but I don't think it should be concern for your library.

@aPere3
Copy link
Author

aPere3 commented Apr 27, 2022

I don't agree that the underlying implementation does not matter to all users. In our case, here are a few reasons:

  • I want to be able to execute, test, benchmark with both code paths knowingly.
  • Also, in our case, we don't want to pay for the runtime detection here, because we will implement a larger autodetection at a higher level.

Anyway, I guess you already answer my question about whether or not this was possible. Thanks for the explanations !

@aPere3 aPere3 closed this as completed Apr 27, 2022
@newpavlov
Copy link
Member

newpavlov commented Apr 27, 2022

The first point is handled well with the configuration options. For reference you could take a look at our CI.

The second point, unfortunately, will not work with the current state of Rust. For example, the AES-NI based implementation requires that the aes target feature is enabled. Currently we can only partially enable it for functions. We can not enable it for a type or a crate. We will need something like target restriction context to properly expose it. To work around this limitation (e.g. when we want to combine cipher and MAC implementations) we have to use the somewhat painfull API reliant on rank-2 closures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants