You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In theory, RustCrypto got support for Deoxys-II fairly recently, including the variant that we use (Deoxys-II-256-128).
Unfortunately, as far as I can tell, the performance of RustCrypto's implementation is total garbage despite using AES-NI, due to the lack of vectorization everywhere else. Encrypting a 2 KiB message (our benchmark includes 64 bytes of AAD, RustCrypto's does not) on a Ryzen 5600X, our implementation clocks in at ~2.34 cpb, while RustCrypto manages ~57.5 cpb (nb: boost enabled because all I cared about is a rough ballpark comparison).
As it stands, a ~25x performance degradation is not a good trade-off for "someone else will maintain it", especially in light of our implementation having received an external audit and extensive testing.
This issue is mostly to document why we continue to use our own implementation (the alternative is too slow), and to serve as a reminder to re-examine the alternative in the event that it receives improvements.
The text was updated successfully, but these errors were encountered:
In theory, RustCrypto got support for Deoxys-II fairly recently, including the variant that we use (Deoxys-II-256-128).
Unfortunately, as far as I can tell, the performance of RustCrypto's implementation is total garbage despite using AES-NI, due to the lack of vectorization everywhere else. Encrypting a 2 KiB message (our benchmark includes 64 bytes of AAD, RustCrypto's does not) on a Ryzen 5600X, our implementation clocks in at ~2.34 cpb, while RustCrypto manages ~57.5 cpb (nb: boost enabled because all I cared about is a rough ballpark comparison).
As it stands, a ~25x performance degradation is not a good trade-off for "someone else will maintain it", especially in light of our implementation having received an external audit and extensive testing.
This issue is mostly to document why we continue to use our own implementation (the alternative is too slow), and to serve as a reminder to re-examine the alternative in the event that it receives improvements.
The text was updated successfully, but these errors were encountered: