Software fallback for other cpu architectures

[AlexanderSchuetz97]

Hello,

a fallback that uses non intrinsics for any other (not x86 and aarch64) cpu architecture would be appreciated.

could that be made possible?

As far as I can see all that would be required would be implementing each of the functions in the "low" module generic mod/folder one by one. Id be willing to contribute "naive" implementations on a one by one basis. Naturally it should be obvieus that the generic functions will be much worse in all aspects compared to your inline assembly variants. In my opinion this would make adoption of graviola easier if it just worked everywhere in some degraded form until eventually most common targets (like for example riscv64gc) are supported with inline asm.

[ctz]

Yes I think this will eventually be needed for certain uses. It is obviously a large amount of work (writing and validating 35,000 lines of assembly in pure rust), and the result would be very unlikely to be as high-assurance as the assembly (but hopefully I could do a better job than no verification at all?).

The other option would be to take and wrap rustcrypto dependencies for those platforms. That would be easier, but discard performance, assurance and build simplicity all in one.

[AlexanderSchuetz97]

Hi!

The reason I use graviola, vs rust crypto is that rust crypto requires a c compiler for some reason. It also seg faults on a tier 3 target I use. Graviola just worked.

I therefore I dont think that wrapping rust crypto would provide much if any benefit to me.

As mentioned my offer stands to begin implementing naive implementations of one function after the other in the low crate and make pull requests. I would write tests and fuzztests for them that they do the same as the amd64 variant. If you also want to work on that at the same time then it will just be faster and we have to somehow coordinate it to prevent duplicate work. Tell me if your intrested in me working on this.

I think it wouldnt be a bad idea to feature-gate the pure rust implementation and only enable it if a user enables a "unverified" feature or something. This would probably mitigate your concerns for verification. I think a "make it work and verify later" approch is best as long as that is properly communicated to users of graviola.

Sincerely
Alexander Schütz

Sidenote:
As prompted by pinkforest below I tried to further investigate the seg fault of rust-crypto. I have since been unable to reproduce the mentioned seg-fault of rust crypto. I think it was an issue on my end as I had to build rustc from source for this openbsd tier 3 target and probably messed up there or used an unfortunate commit. Doesn't change the fact tho that graviola worked back then, its just that rust crypto now also works. This revelation naturally makes me more open to using parts of it for non supported cpu architectures such as riscv64

[pinkforest]

@AlexanderSchuetz97 mind filing issue with details so we can 👀 ? I don't think this originates from rustls-rustcrypto / rustcrypto crates. I don't see any issues about either C compiler or tier3 SIGSEGV in https://github.com/RustCrypto/rustls-rustcrypto/issues

We moved to cfg overrides (which are suited for mutually exclusive knobs where as features are incremental code) elsewhere given features leave the control to the deps in between which may or may not also relay them downstream where as cfg leaves the control to the top level binary (in exchange of learning curve for people to use them who need them)

• Simplifying backend selection dalek-cryptography/curve25519-dalek#414

[DemiMarie]

Yes I think this will eventually be needed for certain uses. It is obviously a large amount of work (writing and validating 35,000 lines of assembly in pure rust), and the result would be very unlikely to be as high-assurance as the assembly (but hopefully I could do a better job than no verification at all?).

Is this code all hand-written or is it generated somehow? If it’s generated, then perhaps the code generator could be ported instead.

[ctz]

Is this code all hand-written or is it generated somehow?

s2n-bignum is mostly hand-written and then formally-verified assembly.